Andreas Hartmann wrote:
Robert Goene wrote:
Hi,
Can you give me some help with the publets? I am trying to call a
publet with a cinclude statement, but it is not really working out.
I want to include all navigation components with cincludes instead of
the aggregate function, for instance:
<cinclude:includexml>
<cinclude:src>cocoon://publets/sitetree/default/live/search/dummy.xml</cinclude:src>
That should read
cocoon://publets/sitetree/default/live/search/dummy.html.xml
(mind the .html)
I keep on receiving a 404 error. Does the dummy.html page have to exist,
even if the {url} parameter is not used? When i use an existing page,
like index.html it still gives me an error.
</cinclude:includexml>
I am not sure what i am doing wrong. Can you point me in the right
direction?
More general: are there any reasons why i should not use the cinclude
transformer to include all navigation components for the search usecase?
Even more general - I'm not quite sure if a usecase is the right approch.
I'd rather start with a resource type. Actually there is a search resource
type in 1.4. (File -> new search page).
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? 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.
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.
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.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
