Josias Thöny schrieb: [...]
> 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... Unfortunately it hasn't changed. I did some optimization for the publish usecase (missing links are only generated when the view is displayed), but there is much room for improvement. Maybe it would be an option to filter the XSPs before evaluating them, i.e. do the menu aggregation and filtering before the ServerPagesGenerator is executed. But this would require to compile the classes for every request, which is certainly expensive as well. -- Andreas > > 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 >> -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
