Category: "Dojo"

Rapid Development Strategies

Web sites have become exponentially more complex and the expectations of site visitors have soared as well.

The only way to build powerful pages is to use sophisticated tools, quickly and effectively.

:!: Choose tools that have decent documentation and a good community. You will need help. Be ready to reciprocate.

B) Use sample code. Everytime you have to learn something new, start with someone else’s posted code. It might not work exactly as you want it to, but you can tweak it, one piece at a time, until it does.

:>> Be very aware of the code architecture. Use an MVC approach, since it is likely you will have at least two views - through a template or HTML and AJAX/JSON.

:crazy: Abandon ideas that are too difficult. This isn’t lazy, it is smart. You’re smart, if you can’t get something working quickly, find another one. Many smart people posted great ideas - use them (and share yours). Abandon tools or libraries that don’t work quickly, too. There is one caveat - if you can see a tool’s potential and are humble enough to admit the problem is a learning curve, it may be worth persisting a little longer. eZ publish is a great example of this - it was well worth learning.

:idea: Be creative.

|-| Use abstract data structures and concepts. Multi-dimensional arrays are incredibly powerful.

:lalala: Be persistent, if it is almost working, keep trying. Try things that don’t make sense, because sometimes, they work - and well.

:oops: Don’t be afraid to be wrong.

:!: Use every available resource, carefully. LAMP is a stack of technology and some parts are better suited for tasks than others. Don’t use bash for page design, don’t use javascript to write large amounts of HTML.

:?: Explore, learn, try. Very little of what I have learned has been useless. Even mistakes and bad ideas are valuable, to avoid.

:yes: Be independent. Don’t ask for help right away. Try to solve your own problems, then ask.

Web client side development tips

As web pages become increasingly complex, more logic is running on the client side, which requires debugging and resolution of browser compatiblity issues. Even with a great tool like dojo, a page may be processed differently and require fixing.

FireFox is my favorite browser for developing web applications. Get the FireBug plugin as well, and YSlow.

Tips:

  • console.debug(variable/expression/string) - allows you to monitor the state of the code as it executes
  • Breakpoints are okay, but it is often faster to let the code run and track it with console.debug
  • alert(variable/expression/string) - can be used as a break point. It is a great way to stop the code and then restart it to isolate problems
  • Comment out code to isolate problems
  • Use the FireBug console to evaluate code and expressions
  • Use the FireBug console to navigate through objects, probing to find properties and methods. Get the commands to work on the console, then add them into the code
  • Use FireBug, under FireFox, to solve problems with IE, once you have identified them
  • Send extra values back in JSON to debug server side logic under AJAX
  • Inspect the POST data to see what was passed down
  • Use a single function to handle all AJAX errors, and then an alert and echo to display text from the server. Include code to disable this for security
  • Create browser specific CSS files from the start, and use server-side logic to deliver them. Use these files to override the other CSS files for browser issues
  • As mentioned before, use server side logic to detect the browser (if possible) and deliver appropriate HTML and javascript. A good example is plugin player code. The objective is to only send the code for the browser in use to the client
  • Set padding and margins to zero
  • Keep things simple
  • Use background colors and the layout area of FireBug to solve layout issues. Keep CSS as lean as possible.
  • Clear the cache/temporary Internet files for CSS updates and JS changes that in separate files

AJAX for speed and polish

With a good toolkit (think dojo), AJAX can let you make a beautiful site.

One strategy I adopted was to use a dual delivery approach on the server side, so server side code can deliver either HTML or JSON. This allows you to reuse the server side logic.

Although I used custom code, with PHP 5.2’s json_encode function and Smarty, an even better implementation would probably be to wrap the delivery logic with a framework like Zend to completely separate the delivery form from the application logic.

There is a tremendous bandwidth savings, and the site interface becomes much smoother, since the only parts of the page that are refreshed reflect the content updates.

In addition, with a toolkit, there are often great widgets and features to create better and more powerful interfaces.

If AJAX will be used, the HTML architecture may need to be adjusted, so it may be worth building up a single page fully, prior to coding the remaining pages. A bit of server side logic can really help as well.

dojo readOnly indicator

A contribution to dojo, a read only indicator for text inputs. It uses an existing image from the tundra theme to place the ubiquitous circle with a line through it in the right hand part of read only text inputs.


.dijitReadOnly
{
        background: #fff url('../dojo/dijit/themes/tundra/images/no.gif') no-repeat right !important;
}

Community contributed code

The associated link points to a nice extension I wrote and contributed for eZ publish 3.8+. It has been downloaded 600+ times.

Unfortunately, I don’t have time to maintain the code or test it with newer versions of eZ publish.

Which means, if people are relying on that functionality, and they upgrade eZ publish (by choice or because the hosting provider upgrades PHP), it may not work.

Since it is open source, and it is a very basic extension, anyone familiar with eZ publish should be able to upgrade it and share it. If they have time.

Now, imagine you built an entire system on community contributed modules. How will you keep the system current? What if the core functionality changes and you have to upgrade the core, risking the modules?

I really enjoy working with open source code and community contributions. They allow me to be much more efficient than I could be without them. Their code allows me to make beautiful sites in a fraction of the time.

I like to select established components and to work within their boundaries to use them. For javascript, I like dojo, for templates, I like Smarty, and for a PHP framework, Zend framework. I don’t modify the code, ever, because I trust the authors. If there is a bug, I may work around it, or upgrade later.

There is no absolute, perfect answer. For some people, the value of the contributed code outweighs the risks. For others, the assembly of a system is not worth it, and they prefer a single, integrated solution. A good example of this is Drupal (community contributed modules) and eZ publish (integrated solution).

One thing that is abundantly clear is that the collaboration of people, across all boundaries, is awesome, and benefits everyone.

… I really wish I had time to write a dojo extension for eZ … :)