Thorsten Scherler schrieb: > 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
Thanks for the info, I'll take a closer look at this. [...] >> 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, or maybe even based on the resource type. If a pub has 10 resource types, and only the "edit" menu for the current resource type has to be generated, there's certainly room for optimization. > 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. When should we change this? RC1 / RC2 / 1.4.1 ? -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
