On Thu, 2007-05-10 at 11:38 +0200, Andreas Hartmann wrote: > 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.
The menu generation is slowed down considerably by all the precondition checks of the usecases in the menu. Some time ago I noticed that in the "authoring" view, the usecases which appear only in the "site" view are checked, too. This is probably not necessary. One example is the delete usecase whose precondition check is quite expensive because it checks the whole subtree (IIRC). This check is also executed in the "authoring" view, although the delete usecase is not available in the "authoring" menu. Or has this been changed recently? I'm not quite up to date... josias > > > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
