I ask for your patience as I really want to understand what's actually
happening with the addressing. I feel like until I understand *why*
some of these things are happening, I'm stuck making mods (largely
through trial, error, and crossed fingers) to existing stuff instead
of original contributions. Here are a few more details to my
questions....
On 6/6/05, Ross Gardler <[EMAIL PROTECTED]> wrote:
> Tim Williams wrote:
> > I'd like to clarify my understanding of the use of cocoon protocols in
> > forrest. The cocoon documentation says:
> > # context:// - get a resource using the servlet context
> > # cocoon:/ - get a pipeline from the current sitemap
> > # cocoon:// - get a pipeline using the root sitemap
> > # resource:// - get a resource from the context classloader
> >
> > 1) Are cocoon:/ and cocoon:// interchangable within the conceptual
> > sitemap space of forrest (e.g., \main\webapp\*.xmap)? Anecdotally,
> > nothing seems to break when I modify existing ones.
>
> My understanding is...
>
> cocoon:/ will *only* match something in the current sitemap (i.e. not
> those in mounted sitemaps or sitemaps from which the current one was
> mounted). I'm not sure if it will match in mounted sitemaps below this
> one, I suspect it will not, but could be wrong.
I may very well be getting confused on the terms root and current.
The forrest docs say that " Forrest's sitemap comprises the
$FORREST_HOME/context/*.xmap files." This leads me to believe that
the terms root and current are conceptual rather than physical which
would mean they are one and the same for the forrest cocoon app and
mounting is just a mechanism to bring the physical maps together? If
those terms are applied physically it might be more understandable why
they are used differently in forrest but then i would like to make
some suggestions to the documentation as i would consider it to be
misleading in it's current form.
> cocoon:// will mount from *any* sitemap in the app
again, sitemap as a physical file? meaning \main\webapp\*.xmap +
{project.sitemap}?
> In other words, you can make it break if you change the wrong one.
Right, but I'm still not clear on what would qualify as the "wrong one".
Here are a few examples that seem odd to me.
linkmap.xmap - For the match "**linkmap-*", the generator is pointing
to cocoon://abs-linkmap which in my understanding would go back to the
root sitemap (ie., sitemap.xmap) and match the abs-linkmap there which
essentially points right back to the match that was above it in the
first place. In this case, why not use cocoon:/abs-linkmap.
tabs.xmap - the last transformer has a src of
"cocoon:/{1}linkmap-{2}.html" which apparently goes resolves in
sitemap.xmap and ultimately linkmap.xmap seems link it should be
cocoon:// if anything should.
> > 2) The same doesn't appear to hold true of forrest-core.xconf as
> > things do break if the correct one isn't used. Since all of them here
> > are to the root sitemap (e.g., cocoon://) is forrest-core.xconf
> > outside the forrest conceptual sitemap?
>
> Pass
Fair enough, anyone else? Ironically enough, it was your reference to
cocoon://locationmap.xml in xconf that got me reading:
http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html#Protocols
and wondering how these schemes work.
> > 3) Are project specific sitemap.xmaps are separate root sitemaps or
> > extensions of the forrest application sitemap?
>
>
> The are mounted from the application sitemap by the following:
...
Yes, I saw that but am still not clear on whether that makes them
interchangable with cocoon:/ and cocoon://. All others within
main\webapp are mounted as well so are they equals?
I appreciate your patience as I learn this stuff...
Thanks,
--tim
