Puakma: Under the hood

I'm Brendon Upson, jack-of-all-trades, master of one or two. I'm talking about life running a small ISV tackling business issues and leaping technology hurdles in a single bound.

webWise Network Consultants is based in Sydney, Australia and develops the groundbreaking Puakma server technology.


Eating dogfood with i18n

Filed under: by Brendon Upson on 22:22

So Tornado is getting pretty mature, but all the work to date has pretty much revolved around a single company server where everyone is in the same timezone and speaks the same language. Until now :-(

As we peg away at ProjectReactor, things crop up. Important things. Let's say we have a project with 2 project managers, one in Sydney Australia and one in New York USA. The Sydney PM enters a milestone to be due mid-day friday, when the New York PM looks at the same record he also sees due mid-day friday. Disaster! Different time zones.

Then there's the date input formats. Sydney PM uses "dd/MM/yy" and New York PM uses "MM/dd/yy". Ouch. How do we make one application design easily cater for the different formats (and also "yy/mm/dd" and many other variations)?

When you have the sourcecode, anything is possible :-) 

Step one: Extend the session object. Add two new attributes to the session; time zone and locale. Upon login we get the timezone from the browser and the locale (language) from their account record. The server code then uses these new properties (if they have been set) when dealing with dates. If they are never set by the application then we default to the server's locale.

Step two: Custom date input formats. This was the tough one. The Tornado app uses <P@Date @P> fields with a format attribute, eg <P@Date name="x" format="dd/MM/yy" @P> The format attribute is stored in a page design element and is certainly not easy to change on a per user basis! Custom session objects to the rescue. Tornado allows any kind of object to be stored on a user's session. So now we just store a session object called "dd/MM/yy" on the session and give it value we want for that user eg "yy.MM.dd". Now when the server is parsing and rendering dates it does a check on the session to see if there is a session object of the same name as the format attribute's value, if there is use this value instead of the format attribute value. If there is no session object by that name, then just use the value this allows it to work either way.


My head hurts. I'm off to bed. 


Your comment

Protected from spambots!

HTML is allowed
Formatting: Basic formatting can be included like so:
[b]bold[/b] and [i]italic[/i]