You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2007/01/25 17:53:30 UTC
Block resources in 2.2 (Forms in particular case)
Hello,
I've tried Forms blocks using /core/cocoon-webapp block(?) lately and
I've found that resources loading does not work. I would like to fix it
but in the manner of using blocks-fw as it seems to be mature enough. It
is, right? 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?
2. Or maybe always block that uses forms block should catch the request
for resources and redirect them (by using some source from block-fw?) to
the forms block?
3. What about paths? Are they supposed to be absolute? If not, which
block (and phase of processing request) is responsible for link
rewriting and what technique is advised?
Thanks for any pointers, advices. I would like to say, that I'm going to
document all these sort of things when I was confident enough myself.
--
Grzegorz Kossakowski
Re: Block resources in 2.2 (Forms in particular case)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Leszek Gawron napisał(a):
> Grzegorz Kossakowski wrote:
>> Are you sure? I get exception while accessing
>> http://localhost:8888/_cocoon/resources/dojo/dojo.js:
> I have just fixed it - the resources where unpacked to a wrong
> directory (org/apache/cocoon/dojo/resources/dojo-0.4.1-ajax instead of
> o/a/c/dojo/resources)
>
> Samples work now properly.
It works for me too, now. Thanks!
--
Grzegorz Kossakowski
Re: Block resources in 2.2 (Forms in particular case)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Grzegorz Kossakowski wrote:
> Daniel Fagerstrom napisał(a):
>> Are you using it the "standard" way:
>> http://localhost:8888/blocks/cocoon-forms-sample/ or are you using it
>> through the blocks-fw? In the former case resource loading seems to
>> work for me.
>
> Are you sure? I get exception while accessing
> http://localhost:8888/_cocoon/resources/dojo/dojo.js:
I have just fixed it - the resources where unpacked to a wrong directory
(org/apache/cocoon/dojo/resources/dojo-0.4.1-ajax instead of
o/a/c/dojo/resources)
Samples work now properly.
--
Leszek Gawron CTO at MobileBox Ltd.
Re: Block resources in 2.2 (Forms in particular case)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Daniel Fagerstrom napisał(a):
> Are you using it the "standard" way:
> http://localhost:8888/blocks/cocoon-forms-sample/ or are you using it
> through the blocks-fw? In the former case resource loading seems to
> work for me.
Are you sure? I get exception while accessing
http://localhost:8888/_cocoon/resources/dojo/dojo.js:
org.apache.excalibur.source.SourceNotFoundException:
resource://org/apache/cocoon/dojo/resources/dojo.js
>> but in the manner of using blocks-fw as it seems to be mature enough. It
>> is, right?
> It should be stable enough, although I'm working on changing the
> naming as discussed in
> http://marc.theaimsgroup.com/?t=116731854200001&r=1&w=2. But that will
> only change some names for the user, so it will be easy to adapt any
> work that you start to the new naming.
Great. I'm going to have some free time next week, so I'll try to make
it working.
Thanks for your response.
--
Grzegorz Kossakowski
Re: Block resources in 2.2 (Forms in particular case)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Daniel Fagerstrom napisał(a):
> Grzegorz Kossakowski skrev:
>
> 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.
Ok, got it. So let's forget about this component, now.
>
>> 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?
I meant: Someone could see this as overkill but I, personally, would not
agree with him. I think using sitemap for this purpose is good choice
because:
1. Everyone who hack with Cocoon knows sitemaps, it's syntax, behavior etc.
2. Sitemaps give great deal of flexibility (think about compatibility
issues after some heavy refactoring, maintaining old solutions)
3. If we introduce another servlet, we have to introduce some amount of
configuration to it. It means /another/ syntax to learn, working-around
the limitations of config by ugly hacks and so on.
>
> 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.
+1
>
> 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.
-100 (see reasoning above)
>
> 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.
>
It I came with working prototype of Forms heavily exploiting new
features of servlet-service-fw, we could think about it later on.
--
Grzegorz Kossakowski
Re: Block resources in 2.2 (Forms in particular case)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: Block resources in 2.2 (Forms in particular case)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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?
What about servlet source? Does it only make possible to access content
generated by other servlet?
If so, should I add sitemap to the cocon-forms-impl just for serving
resources? (personally I do not feel it like overkill)
--
Grzegorz Kossakowski
Re: Block resources in 2.2 (Forms in particular case)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Hello,
>
> I've tried Forms blocks using /core/cocoon-webapp block(?) lately and
> I've found that resources loading does not work.
Are you using it the "standard" way:
http://localhost:8888/blocks/cocoon-forms-sample/ or are you using it
through the blocks-fw? In the former case resource loading seems to work
for me.
> I would like to fix it
> but in the manner of using blocks-fw as it seems to be mature enough. It
> is, right?
It should be stable enough, although I'm working on changing the naming
as discussed in http://marc.theaimsgroup.com/?t=116731854200001&r=1&w=2.
But that will only change some names for the user, so it will be easy to
adapt any work that you start to the new naming.
> 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.
> 2. Or maybe always block that uses forms block should catch the request
> for resources and redirect them (by using some source from block-fw?) to
> the forms block?
This requires more work and means less separation of concern as the
using block must know and repeat the resource handling of the used block.
But in cases where you want the used block to be "internal only", (i.e.
not mounted on any path and just usable through the block protocol or
named dispacther), alternative 2. is the best option.
> 3. What about paths? Are they supposed to be absolute?
It makes the the using block slightly less reusable, as it assumes that
the used block is mounted at specific position. But for a normal
application that not is supposed to be reused in other, unknown,
applications, it is OK to use absolute paths for resources (relative to
the context though).
> If not, which
> block (and phase of processing request) is responsible for link
> rewriting and what technique is advised?
You can use the block-path module together with the
LinkRewriterTransformer in the linkrewriter block. A setup like:
<map:transformer
name="linkrewriter"
src="org.apache.cocoon.transformation.LinkRewriterTransformer">
<link-attrs>href src</link-attrs>
<schemes>block</schemes>
</map:transformer>
have worked before, but I haven't tested for a while.
It would simplify use to have a special purpose transformer or maybe
even a servlet filter, that took care about the rewriting.
> Thanks for any pointers, advices. I would like to say, that I'm going to
> document all these sort of things when I was confident enough myself.
Great.
What I wrote above is my preliminary thoughts. More use is needed before
we can have any more authoritative best practice.
It would be interesting to hear about the thoughts from other people who
are using the blocks-fw.
/Daniel
Re: Block resources in 2.2 (Forms in particular case)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski wrote:
> Daniel Fagerstrom napisał(a):
>
>> Grzegorz Kossakowski skrev:
>>
>> It is achievable. Take a look at the server-service-sample
>> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-sample/.
>>
>>
>> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-sample/src/main/resources/META-INF/cocoon/spring/cocoon-servlet-service-sample-servletService1.xml
>> is a configuration of a service servlet that connects to another
>> servlet service. And
>> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-sample/src/main/resources/COB-INF/test1/sitemap.xmap
>> is a sitemap using the connections.
>>
> I start to get the whole picture. So with servlet-service-fw/block-fw
> (I've read the discussion but still not sure where are boundaries)
The servlet-service-fw will replace block-fw as soon as it is stable
enough. Besides new names, the servlet-service-fw will have much more
convenient Spring configurations. I will also improve a number of other
things.
> there
> is no concept of accessing files /directly/, right? Even if we talk
> about resources like XSLs that are extended by other block, they should
> be accessed by servlet: source and target block should it expose somehow
> (by sitemap or special-purpose servlet mentioned earlier).
Yes.
> Given that,
> there is *no difference* between internal resources like XSL stylesheets
> and CSS server to the browser. Correct me if I'm wrong at some point.
>
You seem to get it right.
> Looking at source code of sevrlet source makes me wonder: where is whole
> caching stuff?
There is no caching stuff implemented yet. Block internal caching is
handled automatically by the sitemap servlet (there is a known bug
however http://marc.theaimsgroup.com/?t=116957497600005&r=1&w=2).
For the servlet source there is no caching however. One question is how
to communicate cache state between the called and the calling servlet
while using the servlet source. Preferably generic http mechanisms
should be used so that caching can work for non SitemapServlet servlet
services.
> Does TODO remark relate to this?
>
Which TODO?
> Next thing is availability of the resources to the outside world. Will
> internal-only pipelines work as before (as expected I would say)?
I would expect that they only work within a SitemapServlet, not between
them. So a internal-only pipeline should not be available through the
servlet protocol. I haven't tested though.
> If I
> understand whole stuff correctly, resources that are accessible via
> servlet: protocol are also accessible directly from the browser because
> servlet exposing them is mounted at some URL.
>
Yes. But you don't have to mount a servlet service on an URL if you
don't want to. An unmounted servlet service is still available through
the servlet protocol for other servlet services that connects to it.
It would probably be convenient to have some way to let some resources
be available for other servlet services, but not through the external
mount path. I haven't thought about how to implement it.
/Daniel
Re: Block resources in 2.2 (Forms in particular case)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Alexander Klimetschek wrote:
> Grzegorz Kossakowski schrieb:
>> Next thing is availability of the resources to the outside world. Will
>> internal-only pipelines work as before (as expected I would say)? If I
>> understand whole stuff correctly, resources that are accessible via
>> servlet: protocol are also accessible directly from the browser because
>> servlet exposing them is mounted at some URL.
>
> Yes, you are absolutely right. That leads to my personal blocks-fw
> wishlist:
>
> 1) make it possible to mark matcher/pipelines as only accessible from
> other blocks (via block:/servlet: protocol)
+1
> 2) have a PostableBlockSource where you can write into a
> block:/servlet: URL to pass request parameters
+1
> 3) have a possiblity to use sitemap-resources (<resource>) from other
> blocks: either by integrating a mechanism into the blocks-fw (probably
> very difficult) or by adding a sitemap-include statement (like
> map:mount) which can refer to a sitemap located in a different block
-1
> Number 3) should actually be handled by the polymorphism, but this
> only works with matchers from which you want to read - with a
> PostableBlockSource it should be possible to do things like sitemap
> child matching, generating stuff etc. and then calling sitemap super
> with an XML stream for some final, shared layouting pipeline. But this
> might turn into a performance bottleneck, since it would need
> serialization of the XML stream for the PostableBlockSource....
I prefer this solution. For the performance bottleneck we better do
something about it if it becomes a problem.
/Daniel
Re: Block resources in 2.2 (Forms in particular case)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski wrote:
> Alexander Klimetschek napisał(a):
>
>> Grzegorz Kossakowski schrieb:
>>
...
>> Number 3) should actually be handled by the polymorphism, but this
>> only works with matchers from which you want to read - with a
>> PostableBlockSource it should be possible to do things like sitemap
>> child matching, generating stuff etc. and then calling sitemap super
>> with an XML stream for some final, shared layouting pipeline. But this
>> might turn into a performance bottleneck, since it would need
>> serialization of the XML stream for the PostableBlockSource....
>>
> Yes, it's also my concern (see caching validity mentioned in this
> thread). I don't understand how caching, redirecting of sax streams,
> etc. could be achieved without heavy serializing. Daniel, could you
> explain as I'm sure you've some ideas.
>
I haven't fought that much about caching.
For SAX-streams however I think we should make it possible to add SAX
awareness to the request and response objects for the servlet source.
Carsten started to to some experiments with (among other things) SAX
aware response objects
(http://svn.apache.org/repos/asf/cocoon/whiteboard/processor/src/main/java/org/apache/cocoon/processing/).
With SAX aware request and response objects, it would be possible to use
a servlet source in the same way as a transformer e.g.
/Daniel
Re: Block resources in 2.2 (Forms in particular case)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Alexander Klimetschek napisał(a):
> Grzegorz Kossakowski schrieb:
>> Next thing is availability of the resources to the outside world. Will
>> internal-only pipelines work as before (as expected I would say)? If I
>> understand whole stuff correctly, resources that are accessible via
>> servlet: protocol are also accessible directly from the browser because
>> servlet exposing them is mounted at some URL.
>
> 2) have a PostableBlockSource where you can write into a
> block:/servlet: URL to pass request parameters
+100
>
> 3) have a possiblity to use sitemap-resources (<resource>) from other
> blocks: either by integrating a mechanism into the blocks-fw (probably
> very difficult) or by adding a sitemap-include statement (like
> map:mount) which can refer to a sitemap located in a different block
-1
Sorry but I would like to see *clean* sitemaps in 2.2. This includes:
1. get rid of <map:mount>, we have blocks, servlet-services-fw and
(hopefully) postable sources for this.
2. get rid of <map:resources>, it has been always a devil (quite handy I
have to admit). As you've written below, this quite be replaced by more
clean and elegant solution.
I'm aware of backward compatibility, so at least let's deprecate them
and encourage people to use new features.
> Number 3) should actually be handled by the polymorphism, but this
> only works with matchers from which you want to read - with a
> PostableBlockSource it should be possible to do things like sitemap
> child matching, generating stuff etc. and then calling sitemap super
> with an XML stream for some final, shared layouting pipeline. But this
> might turn into a performance bottleneck, since it would need
> serialization of the XML stream for the PostableBlockSource....
>
Yes, it's also my concern (see caching validity mentioned in this
thread). I don't understand how caching, redirecting of sax streams,
etc. could be achieved without heavy serializing. Daniel, could you
explain as I'm sure you've some ideas.
--
Grzegorz Kossakowski
Re: Block resources in 2.2 (Forms in particular case)
Posted by Alexander Klimetschek <al...@mindquarry.com>.
Grzegorz Kossakowski schrieb:
> Next thing is availability of the resources to the outside world. Will
> internal-only pipelines work as before (as expected I would say)? If I
> understand whole stuff correctly, resources that are accessible via
> servlet: protocol are also accessible directly from the browser because
> servlet exposing them is mounted at some URL.
Yes, you are absolutely right. That leads to my personal blocks-fw wishlist:
1) make it possible to mark matcher/pipelines as only accessible from
other blocks (via block:/servlet: protocol)
2) have a PostableBlockSource where you can write into a block:/servlet:
URL to pass request parameters
3) have a possiblity to use sitemap-resources (<resource>) from other
blocks: either by integrating a mechanism into the blocks-fw (probably
very difficult) or by adding a sitemap-include statement (like
map:mount) which can refer to a sitemap located in a different block
Number 3) should actually be handled by the polymorphism, but this only
works with matchers from which you want to read - with a
PostableBlockSource it should be possible to do things like sitemap
child matching, generating stuff etc. and then calling sitemap super
with an XML stream for some final, shared layouting pipeline. But this
might turn into a performance bottleneck, since it would need
serialization of the XML stream for the PostableBlockSource....
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
Re: Block resources in 2.2 (Forms in particular case)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Daniel Fagerstrom napisał(a):
> Grzegorz Kossakowski skrev:
>
> It is achievable. Take a look at the server-service-sample
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-sample/.
>
>
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-sample/src/main/resources/META-INF/cocoon/spring/cocoon-servlet-service-sample-servletService1.xml
> is a configuration of a service servlet that connects to another
> servlet service. And
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-sample/src/main/resources/COB-INF/test1/sitemap.xmap
> is a sitemap using the connections.
I start to get the whole picture. So with servlet-service-fw/block-fw
(I've read the discussion but still not sure where are boundaries) there
is no concept of accessing files /directly/, right? Even if we talk
about resources like XSLs that are extended by other block, they should
be accessed by servlet: source and target block should it expose somehow
(by sitemap or special-purpose servlet mentioned earlier). Given that,
there is *no difference* between internal resources like XSL stylesheets
and CSS server to the browser. Correct me if I'm wrong at some point.
Looking at source code of sevrlet source makes me wonder: where is whole
caching stuff? Does TODO remark relate to this?
Next thing is availability of the resources to the outside world. Will
internal-only pipelines work as before (as expected I would say)? If I
understand whole stuff correctly, resources that are accessible via
servlet: protocol are also accessible directly from the browser because
servlet exposing them is mounted at some URL.
Also, I've missed the connections property point of configuration. Now I
now why my testing failed badly...
>> Sorry for asking so much questions but I would really like to understand
>> how all these things should be done along with the usage of new, shiny
>> features of 2.2 :-)
> No need to be sorry, I'm happy that people are interested in the
> stuff. And as long as I don't write any documentation its my own fault ;)
>
Exactly :-P
--
Grzegorz Kossakowski
Re: Block resources in 2.2 (Forms in particular case)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Grzegorz Kossakowski napisał(a):
>> Hello,
>>
>> I've tried Forms blocks using /core/cocoon-webapp block(?) lately and
>> I've found that resources loading does not work. I would like to fix it
>> but in the manner of using blocks-fw as it seems to be mature enough. It
>> is, right? 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?
>> 2. Or maybe always block that uses forms block should catch the request
>> for resources and redirect them (by using some source from block-fw?) to
>> the forms block?
>> 3. What about paths? Are they supposed to be absolute? If not, which
>> block (and phase of processing request) is responsible for link
>> rewriting and what technique is advised?
>>
>
> Next question is about exposing resources of one block the others for
> internal usage. For example, in
> cocoon-forms-sample/resources/forms-samples-styling.xsl we have 2
> inclusions:
> <xsl:include
> href="resource://org/apache/cocoon/forms/resources/forms-page-styling.xsl"/>
> <xsl:include
> href="resource://org/apache/cocoon/forms/resources/forms-advanced-field-styling.xsl"/>
>
> As far as understand the whole block architecture it should be changed
> to something like:
> <xsl:include
> href="block:cocoon-forms-impl:resources/forms-page-styling.xsl"/>
> <xsl:include
> href="block:cocoon-forms-impl:resources/forms-advanced-field-styling.xsl"/>
>
> At least that suggest Daniel's presentation (slide 22). Is this concept
> still valid?
Yes.
> If so, is it achievable and how?
It is achievable. Take a look at the server-service-sample
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-sample/.
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-sample/src/main/resources/META-INF/cocoon/spring/cocoon-servlet-service-sample-servletService1.xml
is a configuration of a service servlet that connects to another servlet
service. And
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-sample/src/main/resources/COB-INF/test1/sitemap.xmap
is a sitemap using the connections.
> If not, is it hard to make it?
> Sorry for asking so much questions but I would really like to understand
> how all these things should be done along with the usage of new, shiny
> features of 2.2 :-)
No need to be sorry, I'm happy that people are interested in the stuff.
And as long as I don't write any documentation its my own fault ;)
/Daniel
Re: Block resources in 2.2 (Forms in particular case)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Grzegorz Kossakowski napisał(a):
> Hello,
>
> I've tried Forms blocks using /core/cocoon-webapp block(?) lately and
> I've found that resources loading does not work. I would like to fix it
> but in the manner of using blocks-fw as it seems to be mature enough. It
> is, right? 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?
> 2. Or maybe always block that uses forms block should catch the request
> for resources and redirect them (by using some source from block-fw?) to
> the forms block?
> 3. What about paths? Are they supposed to be absolute? If not, which
> block (and phase of processing request) is responsible for link
> rewriting and what technique is advised?
>
Next question is about exposing resources of one block the others for
internal usage. For example, in
cocoon-forms-sample/resources/forms-samples-styling.xsl we have 2
inclusions:
<xsl:include
href="resource://org/apache/cocoon/forms/resources/forms-page-styling.xsl"/>
<xsl:include
href="resource://org/apache/cocoon/forms/resources/forms-advanced-field-styling.xsl"/>
As far as understand the whole block architecture it should be changed
to something like:
<xsl:include
href="block:cocoon-forms-impl:resources/forms-page-styling.xsl"/>
<xsl:include
href="block:cocoon-forms-impl:resources/forms-advanced-field-styling.xsl"/>
At least that suggest Daniel's presentation (slide 22). Is this concept
still valid? If so, is it achievable and how? If not, is it hard to make it?
Sorry for asking so much questions but I would really like to understand
how all these things should be done along with the usage of new, shiny
features of 2.2 :-)
--
Grzegorz Kossakowski