web notes - a blog

• Use the transport mechanism to send debug information. For example, if you’re sending back an array of data, add a new element (or several), and put in the SQL query so you can see exactly what’s being executed.
• Store the returned data in global variables on the client side and use Firebug to examine them. console.debug and alert are helpful, too.
• Use var_dump and echo if you get frustrated. They’ll probably throw an error on the client side, but you’ll get to see what you want to.
• Use var_export($variable,true) if you want to do a var_dump to a string or to a file. file_put_contents(’/tmp/file’,$data,FILE_APPEND); is a great way to monitor script execution. Open a new SSH window and use tail -f /tmp/file to see it.
• Cut and paste output into Notepad so you can easily verify it. Often you need several chunks of text and data to truly understand what is happening and why.
• Develop complex pieces in a standalone environment. This is good for assembling arrays of data out of complex SQL queries. Simplifying the task so you can focus on the difficult parts will speed development.
• Watch out for extra commas in object assignments. IE will crash.
• If you have Visual Studio, use it. It can save you a tremendous amount of time when debugging under IE.
• Test for the presence of variables, objects, and attributes before using them. It isn’t really right, but you can use if (variable_exists) to see if the variable has been set up. A better solution is to initialize everything, or to use if (typeof variable != ‘undefined’).
• To remove something from a page, use style="display:none". It works, it’s simple, and it’s very low risk. If anyone is playing with your code, they’ll find it, but it shouldn’t be an issue unless it had security issues, or restricted content.
• Add a debug setting to your code that allows you to receive more information when errors occur. You can disable it for the production release.

• RIAs must validate on both the client and server-side. Thus, the server must have access to validation data. In that regard, it is easier to have the server handle the language-sensitive validation and then send it to the client, rather than have all language-sensitive elements (prompts, messages, validation) at the client.
• Application common validation should be allowed. For example, allowing a dash in names - which may not be considered part of an alphabet should be consistent for all supported languages.
• Localization is a separate issue. It can be addressed in many different ways. The amount of time spent on localization should be carefully considered. For a limited audience RIA, localization may be addressed with screen prompts and documentation which allows users unfamiliar with the formats to work with them. This approach is suitable if the localized elements are limited or the user is unlikely to use them often. For pages that will be used frequently, localization should be considered. Localization should be consistent throughout the application, meaning if one page is localized, or one type of data is, all should be.
• Language strings can be stored in the database or in files of name/value pairs. They should be constructed in such a way that word order can be adjusted for language, this may mean more strings or multi-word strings.
• Language resources should be dispersed such that pages only retrieve the data necessary to support the active page.
• Some parts of the application may be based on the native language of the server. This should be supported with documentation.
• If it is likely an application will be multi-lingual, it should be built in from the beginning, it will greatly increase the cost of development to change a single language site to multilingual if it wasn’t built with language independence.
• Frameworks and toolkits like Zend Framework (http://framework.zend.com) and dojo (http://dojotoolkit.org) have execellent resources. It is much better to use these as starting points than to try to reinvent the wheel.
• Report files and any emails should also be multilingual. Ideally, these should draw language data from the same source as the application.
• Log files need not be multilingual.
• Templates should be language independent.
• Images should be language independent, or language sensitive versions should be developed.
• Flags are an excellent way to allow selection of language.

• Server should use a deterministic method to timeout sessions. cron jobs are good. These should be lightening fast. See other posts in this blog. These timeouts address the situation where the user closes the browser and walks away without logging out.
• Logging out should force session cleanup. If temporary files are not security risks they can be removed by a different cron job.
• Temporary file cleanup can be performed less frequently, unless this would compromise sensitive data. cron jobs are good.
• AJAX controls may fail to execute properly if authentication is required for delivery. Pinging the server to check for session timeouts can limit user frustration when a page doesn’t function due to a session timeout. It may be difficult or prohibitive to attach error trapping to all the AJAX controls in an application. Another options is to cache the control content, but that may be impossible if it is truly dynamic.
• Ping requests may update the session file timestamp. A ping count can be used on the server side to differentiate between ping requests and user-initiated requests. After a certain number of ping requests, the server can time out the session. AJAX and page (HTML) user-initiated requests should clear the ping count.
• Users should be alerted gracefully of timeouts.

Each step ends with place in version control, submit for review, evaluate review responses and apply them as appropriate..

1. Define the page architecture, common page elements first. These must be stable before beginning.
2. Build page level XHTML/CSS for all pages, target browser FireFox, with only enough back end code to deliver the pages. Use static server-side content to populate dynamic controls/queries for illustration. Create data in the database to support it. Validate the XHTML/CSS as well as possible (some libraries have proprietary attributes).
3. If common components are identified in the previous step, they should be constructed reusable/shared components. For example, a file upload or search results dialog box will probably be used in more than one place. Both client and server-side code should address this to avoid duplicate code.
4. Tune colors.
5. Define and implement client-side functionality, allowing content to be delivered through AJAX, navigation, any dynamic operations.
6. Implement client-side validation.
7. Extend pages to run under any other browsers you will be supporting. Clearly indicate limitations, such as will function but may not display well. Provide notification for users of unsupported browsers.
8. Integrate and implement server-side validation. It should be identical to client-side validation, with addition considerations for security.
9. Implement page level functionality.
10. Test, test, test.

dijit’s (dojo - http://dojotoolkit.org) tundra theme is excellent.

Notes on customizing it:

• Copy dojo.css, dijit.css, tundra.css, and the supporting images out of the dojo tree and into the application’s CSS directory. Place the images in a directory under CSS, that way, the paths don’t have to be updated in the CSS files for those images. This risks later version conflicts with dojo, but also prevents inadvertant destruction of customization on upgrades. This also ensures you don’t affect other applications as you modify the files.
• Update paths in the files (tundra.css imports dijit.css). Renaming tundra.css is a good idea, since it won’t be tundra after you change it.
• Use icons from the Crystal Project (see link above). Be creative, the icons are beautiful and can be used in many ways to enhance the dijit theme.
• Strive to avoid creating new images, unless you can create them quickly. Tiny images can take a surprising amount of time. Since the majority of tundra is grey, with blue highlights, simply removing the blue images and adjusting the remainder can provide a neutral color scheme.
• Augment the tundra colors with those from you application. If you use the same hue, you can adjust the brightness and saturation to add variety to the color scheme.
• Change as little as possible, because tundra already looks great. Try to preserve the dojo CSS file structures, so that if you need to merge in changes after an upgrade, it is not too difficult.
• Use at least four other CSS files, base.css which contains application common basic layout, color.css, which contains application common color settings, ie.css for IE, and ff.css for FF specific settings. Additional page-specific CSS files, as well as some embedded style tags may be helpful as well. Configure caching to reduce the impact of these files, consider compression or bundling them together if necessary. Keep CSS as lean as possible, place design images in HTML, where they don’t incur overhead unless they are used.
• Spend time looking at the Crystal icons. Even if the icon is named ‘urgent_mailmessage.png’, if it looks good where you want to use it - use it there.
• Install the Crystal icons in DocumentRoot, then link to them with a symlink from the images directory, which should be at the same level as the CSS directory. That way, the icons can be shared by all applications and sites on the server.