I personelly like the idea of using wicket as pre-processor or templating engine. The reason is that I stay with wicket and that you don't have to "learn" another technique. Though velocity is easy to use. The pre-processor of course has the disadvantage that changes to the files are not picked up immediately, which is nice for development.
I guess the "problem" (may be not the right word) with using wicket for dynamic translation, is that you'll end up with plenty of wicket labels and attribute modifiers, kind of overloading your <component>.java with not-so-important labels. Again a reason, why I like the templating approach - whether vm or wicket or whatever. Caching will definitely become a problem, as we assume a static association between file (content) and class. The RFE was meant to solve another "issue". A more flexible (statistics, control) of the markup cache. I guess what we need here is an user option to provide there own mapping key (which is currenlty based on class name, style, locale etc.). I guess new RFE makes sure, we don't forget about it. Juergen ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
