cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Block resources in 2.2 (Forms in particular case)
Date Sun, 28 Jan 2007 19:09:15 GMT
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


Mime
View raw message