In HiveMind 1.0, you set the locale once, when you build the Registry and you're stuck with it. That's pretty limiting, especially for a web application. In a web application, such as a Tapestry application, each request (which is to say, each thread) may be using a different locale.
Using a fixed locale limits the usefulness of HiveMind. It means that the business layer can't generate localized error and status messages and pass them back up to the presentation layer. Instead, you fall into the same old trap of exceptions and return codes so that the presentation layer can generate those messages (in the proper locale). That's counter to whole philosophy of HiveMind: colocate everything, so that they can collaborate richly and limit the amount of ugly plumbing and klude code you have to write.
Well, I just checked in changes to HiveMind 1.1 that allow the locale to be changed at any time. The Registry's locale is simply the default locale. The key aspect of this is the Messages object injected into your services ... this was how services gained access to localized messages. The new implementation is smart enough to combine the request message key with the thread's current locale when obtaining a message.
For a web application, this means that, as soon as the client's locale is determined, the ThreadLocale service should be notified. Any messages generated by any services will then be in the proper locale. Tapestry 3.1 has a particular place for doing this ... in fact, the engine's getLocale() and setLocale() methods will be changed to simply invoke getLocale() and setLocale() on the ThreadLocale service.
No comments:
Post a Comment
Please note that this is not a support forum for Tapestry. Requests for help will be deleted. Please subscribe to the Tapestry user mailing list if you are in need of support, or contact me directly for professional (for pay) support.
Spammers: Don't bother. I delete your comments and it's a waste of time for both of us. 垃圾邮件发送者:不要打扰。我删除您的评论和它的时间对我们双方的浪费