On Thu, 2007-05-10 at 10:57 +0200, Andreas Hartmann wrote: > Thorsten Scherler schrieb: > > On Wed, 2007-05-09 at 23:01 +0200, Jörn Nettingsmeier wrote: > >> Andreas Hartmann wrote: > >>> Joern Nettingsmeier schrieb: > > ... > >>> Our menu is a special case - it has a basic structure (which XML is > >>> fine for), but there's some logic to control the details. We have to > >>> find a way to separate these aspects, maybe by introducing a generic > >>> mechanism to show/hide/enable/disable menu items. > >> hmm. especially for trivial things such as menu enabling/disabling, xsl > >> is suited fine. and i'm quite sure the menu2xhtml can be simplified *a > >> lot*. most of the confusion in there comes from our URL handling problems. > >> > > > > 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. > > The problem with JX is that you can't access arbitrary Java objects > without passing them from a flowscript. We'd have to define which > set of objects we pass, and that wouldn't be extensible without > overriding the flowscript.
Actually they have changed that. I found the mail on cocoon-dev where they told me so, it was about the JXGenerator and caching. thread: http://marc.info/?t=115834950000002&r=1&w=2 answer: http://marc.info/?l=xml-cocoon-dev&m=115866670503538&w=2 > > > > 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. > > Yes, this is exactly the problem. I agree totally with you. A trivial example is doing string operations in xsl is total nightmare. > > > > Further if we switch from xsp to jx we can reuse the pipelines for now > > since we would just switch the way how we call it. > > > > To the xsl generating xsl I once had done a similar thing in the > > dispatcher but then wrote a custom transformer since this reduces > > complexity of the code and put it into one java component. > > > > If we break down the menu generation process like: > > 1) Core looks up all menu extensions from the module and aggregate them > > in one file (done once since from there we can use the cached match). > > [1a] optional: filter the menus that are not needed for the publication > > 2) Url specific filter which connects the menu file and gets all menus > > that are needed. Returning a subset of menus and pass it to the next > > step. > > Sounds reasonable. > Maybe we could even refine this so that we don't have to aggregate the > full menu and filter it, but have different cached menus, depending on > the modules needed for a request. You mean, the pub defines x modules and we just aggregate this x menus? Yes, agree that is even better since it is more efficient. > > > 3) Populate the file from step 2 with java objects that are in the > > request. > > > > Where 1 is a match of its own (for caching reasons) and 2 and 3 in one > > match. > > > > The menu should be independent from the main aggregation. Actually the > > whole main aggregation > > [...] > > > should be done in a more flexible way via a template that will get the > > parts it needs. > > This way it would be as well possible to extend it more > > easy without touching the sitemap. > > Big +1. Will have a look and try to come up with something simple. 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]
