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. > 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. > 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. > 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. -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
