Sylvain Wallez skrev:
Daniel Fagerstrom wrote:
...
IIRC, there are a few subtle things involved in the resource handling
code, so be prepared to that you might need to spend some time
learning how it works ;)
Views and resources are handled similarily as things that are purely
internal to a sitemap. They are therefore looked up and "hard-linked" as
part of the processing node tree building phase.
Having inheritable resources means:
1 - they should be stored into a location that's visible from child
sitemaps. Either the sitemap-specific service manager or Avalon context
object should fine (I prefer the latter).
2 - they should not be looked up at build time but at execution time.
However, that's probably not enough, as the URL resolution in inherited
resources will be relative to the context of the sitemap that called the
resource. Solving this, well, is very close to virtual sitemap
components and is not trivial.
Yes, thinking more about it, it will be much easier to back port the
VPCs than make resources callable from subsitemaps. I'm not saying that
it will be simple to backport the VPCs though ;)
Besides the problems that Sylvain describe you also have the problem
that if you want to use the resource as a VPC transformer (I got that
impression from your original post), you also need a mechanism that
switch between the different contexts that the transformer and the
sitemap components before and after are supposed to be executed in, and
this need to be done for every SAX event.
--- o0o ---
Before you jump in into all this work, I would suggest that you
seriously consider choosing another design. I did lots of complicated
stuff in the sitemap before, but my experience is that it doesn't scale
that well and is rather hard to support and understand. Today I much
prefer doing the complicated stuff in Java and just use the sitemap for
the presentation layer.
My impression is that most Cocoon developers consider complicated
sitemaps an anti-pattern.
/Daniel
