Gabriel Sidler <[EMAIL PROTECTED]> writes: > Daniel Rall wrote: > ... > >> It's kinda of too bad your MessageTool is so tied to Struts (just as >> mine in Turbine is tied to Fulcrum -- both our tools delegate the >> request Accept-Language header parsing off to other code), as this new >> package would be a great place for it. It would be worth-while to >> have some sort of I18N/L10N interface in this new package which >> misc. localization tools can implement. > > > I would be interested in exploring more into the direction that your > MultiViewTools is going.
To be absolutely clear, the localization tool that I'm referring to is almost exactly like the one you have written, and is in the Turbine respository: http://cvs.apache.org/viewcvs/jakarta-turbine-3/src/tool/org/apache/turbine/tool/LocalizationTool.java?rev=1&content-type=text/vnd.viewcvs-markup The new MultiViewsTool is more focussed on content negotiation, rather than message formatting for localization. > My challenge is the follwing type of web app: > > - multiple languages > - multiple skins > - dynamic content Within the same instance of an application, I don't often use multiple skins. However, each deployment of SourceCast is generally skinned to the customer's specs. Right there with you. :-) > How do I achieve to have all style, layout and content free of > redundancy. And keep it easy to maintain. And achieve resonable > performance. And all with Velocity. I haven't seen a solution to > that. I've found that Velocity performance is quite good (with caching on). At this point, it's the underlying libraries which are the bottleneck. I haven't looked how this maps into the interals of Velocity yet, but I got one really good suggestion from JavaOne which we can apply to localization of high traffic applications. It was strongly recommend that one avoid Java's character to byte conversion routines using caching. Before I heard that, Ed Korthof, Jon Stevens, and myself had run some tests for the MM MySQL JDBC driver and discovered that when Java's encoding conversion routines were not explicitly avoid, throughput was degraded by a factor of 10 (!!!). I was wondering if snapping a byte[] cache onto Velocity would be possible, so that the expensive encoding routines could be avoided after the first hit. The expense of this is added complexity and memory usage (as output must be cached for each encoding), but on an enterprise site the performance gains might very well out weigh these issues. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
