On Thu, 2007-05-10 at 11:28 +0200, Joern Nettingsmeier wrote: > Thorsten Scherler wrote: > > Right now in the menu we can decide when and which item to show. I agree > > that the xsp approach needs rethinking but why not use jx instead. This > > would make it possible to keep presentation logic in an easy way. From > > my experience xsl it is not very suitable to implement presentation > > logic which are based on java objects. > > i must confess i don't like jx very much... its control structures are > totally crippled and every non-trivial operation requires offloading to > java code, even if it is just view-related and thus be in the template > code....
Actually for me that "every non-trivial operation requires offloading to java code" is a benefit since it keeps the heavy logic out of the templates. I guess we all have seen once in our life a jsp that contained an actual java class within, well let alone jsp and look in some of our xsp that are nearly doing it. The benefit "outsourcing" this operation to java objects is the re-usability and the reduction of complexity. I lately developed some components for a customer in java flow and must admit it is heaps cleaner then js. Sure you can use java objects in js, but who really wants to program in js if you can do it directly in java. Having my flow in java I followed a bean approach to pass the objects to the view and could test all the non trivial operations with junit. If we allow too much in the view we have not the benefit of testing with junit. ... > > Further it would be possible to have url specific extension of extra > > content and/or extra functionality. Imagine I do not want the breadcrumb > > or the lanuageselector on some pages but on other I do. Now I always get > > this parts, paying the price that Dominique has described. > > let's be careful not to stash too much into the URL space.... the > flexibility would be a bonus, but awkward URLs can be a problem. plus if > we export too many internal features to the outside via URLs, we might > open ourselves to exploits and DoSes. > for instance, the SVG flag rendering is a potential DoS already, because > it's so expensive in terms of cpu cycles. we need to avoid a situation > where a malicious site visitor can trigger all kinds of cpu hogs by > tinkering with the request URL. Actually the url space e.g. in the dispatcher is untouched, it is only used to trigger the corresponding template. http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.internal.dispatcher/how/howto-dispatcher-structurer.html and http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.internal.dispatcher/int/index.html see "structurer templating" wdyt? salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
