Industry Misinterpretations 56: Seaside on Cincom Smalltalk
This is the second episode we recorded in Cincinnati at our internal "Camp Seaside" during the last week of September, 2007. In this talk, I got Alan Knight and Michel Bany together with Michael Lucas-Smith to talk about our upcoming support for Seaside in Cincom Smalltalk. Michel covered the history - how he came to the VW port of Seaside, and how far he's taken it. Michael discussed the automation of that process, and Alan covered what we're doing with Glorp for Seaside.
It was a good discussion, and we covered a lot of ground. If you have feedback, send it to smalltalkpodcasts@cincom.com. Or, you can visit iTunes and leave a review, Podcast Alley and cast a vote, or find us in the Industry Misinterpretations group on Facebook. Make sure to watch for next week's episode - we spoke to Gemstone about their GLASS initiative.
Technorati Tags: seaside, smalltalk, cincom smalltalk
Enclosures:
[http://www.cincomsmalltalk.com/audio/2007/industry_misinterpretations56.mp3 ( Size: 10560442 )]
Comments
Process-specific Locales
[Philippe Marschall] October 8, 2007 12:53:40.914
I don't see why you would want locales (and timezones) process-specific and not session-specific.
Process-specific locale
[Martin Kobetic] October 8, 2007 22:53:21.321
It's the other way around. Given a Seaside provided per-session Locale information, how can we make the existing VW I18N facilities work in session specific manner? Standard VW mechanism for I18N are UserMessages. Instead of hardcoding a string, e.g. 'Blah', you build an instance of UserMessage as follows: #MessageID << #CatalogID >> 'Blah'. When the UserMessage gets converted to String at any point it will get resolved against current Locale and associated message catalogs. This happens transparently, there isn't any explicit call along the lines of: self session translate: 'Blah'. The problem that we needed to solve for Seaside was that previously 'current Locale' meant only current global, image wide, Locale. For Seaside we needed something more granular. Implementing per-process Locale is a fairly natural extension of the above, preserving transparency and providing enough granularity to accomodate any sort of session-specific Locale setup, assuming there aren't multiple sessions involved with any single process. Which is more than sufficient in most usual server configurations. In Seaside, for example, there's a new process created for each incoming request, and each request is resolved in the context of single session. So, there's never more than one session associated with the process. In fact it's usually several processes serving single session (in sequence).