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. 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.
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.
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
<map:part
src="cocoon:/navigation-element/breadcrumb/{2}/{3}/{5}/{6}/{7}"/>
<map:part src="cocoon:/navigation-element/tabs/{2}/{3}/{5}/{6}/{7}"/>
<map:part src="cocoon:/navigation-element/menu/{2}/{3}/{5}/{6}/{7}"/>
<map:part src="cocoon:/navigation-element/search/{2}/{3}/{5}/{6}/{7}"/>
<map:part
src="cocoon://modules/languageselector/text-none/flagsize-13"/>
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.
Further it would be possible to have url specific extension of extra
content and/or extra functionality. Imagine I do not want the breadcrumb
or the lanuageselector on some pages but on other I do. Now I always get
this parts, paying the price that Dominique has described.
wdyt?
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]
