Grzegorz Kossakowski skrev:
Daniel Fagerstrom napisał(a):
So my questions are:
1. Should block resources be served directly by block owning them? I
mean, should request for some javascript files be dispatched (by
blocks-fw dispatcher) directly to forms block and some matcher in there
would catch up the request?
In most cases this should be the best solution.
So the question arises: how block like coocon-forms-impl should expose
its resources? Is there any magical source that lets me to access
resources of other block?
Yes, there is the blockcontext source. See
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=116326232408386&w=2 for
background and
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-webapp/src/main/webapp/blocks/sitemap.xmap
and
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/META-INF/cocoon/spring/cocoon-forms-sample-blockServlet.xml
for usage examples.
But the blockcontext source is mainly intended for Cocoon internal use.
Using it in applications for getting resources is somewhat analogous to
accessing private methods in other classes in Java.
What about servlet source? Does it only make possible to access content
generated by other servlet?
Yes.
If so, should I add sitemap to the cocon-forms-impl just for serving
resources? (personally I do not feel it like overkill)
I don't understand the above sentence, does it feel like overkill or not?
Anyway, I would recommend adding a sitemap for serving resources. By
doing that the power of the servlet service framework with polymorphism
and configurability etc becomes available. Also it saves the user from
having to write a couple of extra sitemap rules for serving cforms
resources.
If it feels like overkill to use a sitemap servlet for serving
resources, we could later write a special puropse resource serving
servlet for doing that.
It would probably also be a good idea to split out the resources and the
servlet service from cocoon-forms-impl to an own block.
/Daniel
