Robert Goene wrote:
[...]
Usecases are rather orthogonal to CMS pages, by now they're not designed
to be used as normal pages. The search page should behave like a typical
CMS page, so it will be quite difficult to implement it as a usecase.
Using a resource type, you don't have to care about aggregating the
navigation components, because what you deliver is just a document
(content), not a complete page.
I do not understand the whole concept of a 'search page'. Isn't the
search facility a standard feature that should be part of the standard
navigation components?
We can provide a default search component, but it has to be overridable.
The usecase approach seems valid to me, because
the search result is created by the search-generator, which is processed
by several transformers. A straight-forward sitemap usecase is the most
appropriate as far as i am concerned.
How do you want to implement a generic page assembly mechanism in a usecase?
I do not like the approach of using an aggregate and a seperate
pipeline for the search generator.
Exactly, it wouldn't make sense to duplicate this functionality.
With the use of the cincludes, there is one xslt sheet that takes
care of the composition of the xml and one xslt sheet that takes care
of the xhtml rendering. IMO, the one thing cocoon suffers from is the
fragmented composition of the xml trees, something that must be
avoided whenever possible.
Why do you think so? IMO modularization of XML composition is rather
a good thing, if properly cached.
Composition is a good thing, i was questioning the place of the
composition. The cinclude approach seems both more flexible and more
clear to me, because the composition can be done in a single xslt file.
IMO that's a question of taste :)
The sitemap is the place where the page flow happens.
Hiding page assembly in XSLTs makes it hard to understand.
The main reason for me to use cincludes is not the above, but the
restricted use of the aggregator. The diversity of the cocoon generators
can unfortunately not be used when using the aggregator approach.
?? Why not?
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
