Notes on Building a MultiLingual RIA

  • 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.

How to Transfer a Domain Name from one Registrar to Another

  1. Check all email addresses and ensure they are valid and current. If there is a private registration, you will have to change it to public.
  2. Unlock the domain(s).
  3. Request an authorization code. You should receive an email with the domain name and code.
  4. Go to the new registrar and initiate a transfer, using the domain name and corresponding authorization code.
  5. In a few days, you should receive an email with a confirmation link.
  6. After you click the confirmation link, the transfer should be completed in a day or so.
  7. Check the DNS settings to ensure everything still works.

Instant Web Site - with Full Control

Concrete5 (http://www.concrete5.org/) offers a great way to create a site quickly, and be able to customize it later.

This is a valuable service, because many people start with a simple site, and then want to extend it. Concrete5 gives you all the access you need, so that when you are ready to extend the site, in any way, you are ready. This also means you can start with their hosted solution, then move gracefully to your own server.

They have a great collection of themes/skins/designs to choose from: http://www.concrete5.org/index.php?cID=614

This solution allows you to run a very powerful system without the help of an expensive web development firm. They handle the hosting, application upgrades, and security.

You may need help setting up email, but you can contact them or a hosting company. The prices are excellent.

Check it out.

Session Timeout Notes

  • 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.

Rapid RIA Development

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.