On Fri, 2007-11-09 at 15:36 +0100, Grzegorz Kossakowski wrote:
> Thorsten Scherler pisze:
> >
> > which was working fine since I was testing the dispatcher-block, but now
> > since I am in my webapp now the relative path is resolved to the current
> > app and not to the dispatcher block any more.
> >
> > Meaning the resources cannot be found anymore.
>
> That's something weird I think. Crucial question is how do you call
> dispatcher-block? By using
> cocoon: protocol?
No, not with the cocoon protocol:
<map:match pattern="**.html">
<map:generate src="servlet:dispatcher:/{1}.html"/>
<map:serialize type="xhtml"/>
</map:match>
>
> I also trying to understand your architecture. Does dispatcher-block work the
> way that it lets to
> override some resources in myWebapp and if they are not defined it fall-backs
> to some standard ones?
Exactly. The dispatcher has its origin in forrest where you need to be
able to override default configuration easily. We use the locationmap
for this (if no project.dispatcher.home property is set we are using the
dispatcher block):
<!-- Base location of the dispatcher-->
<match pattern="dispatcher.home">
<select>
<location src="{global:project.dispatcher.home}"/>
<location src="{block-filepath:dispatcher/}"/>
</select>
</match>
...
>
> > I could not find the block-context: which Grzegorz has recommended.
> >
> > Anybody has an idea, since I am running out of them?
>
> I've seen that you created an issue resolving your problems with getting
> absolute path
> (COCOON-2145). However I will insist on asking question about your use-case
> because I fear that you
> are reinventing the wheel somehow or at least you are basing your
> architecture on non-standard
> contract.
http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.internal.dispatcher/
I would not saying reinventing just making it rounder. ;) Well the
classic model in cocoon is to have an aggregation of different parts of
a page (navigation, header, footer, ...) in the sitemap and then use one
or more transformer to do the presentational part.
The disadvantage in the classic model is that you cannot easily extend
the aggregation without touching the sitemap. The dispatcher allows you
define contracts (transformation snippets) and dataUri (data models
which should be transformed by contracts) within a format independent
template (called structurer).
> I have in mind block-context which is *NOT* recommended solution (only quick
> work-around)
> because it's internal and may change in the future.
Hmm, till now the block-context is returning exactly what I need.
Further I think one import feature of cocoon was always context:// and
cocoon:// protocol. The first to use resources that have not been
exposed via the sitemap and the other use the whole sitemap construct
(incl. all map:mounts).
Thanks for your feedback.
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]
