cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject environment abstraction in Cocoon 2.2 (was: Cannot get JSPReader/JSPGenerator to work)
Date Sun, 08 Oct 2006 22:10:31 GMT
On 07.10.2006 14:43, Laurent Perez wrote:

> I'm using JSPs an Cocoon 2.2, but I still don't understand if I did
> the "right" integration : basically, my usecase requires custom JSP
> tags to be able to retrieve XML from sitemap patterns. Under 2.1, I
> wrote an integration method starting up a CocoonBean instance and use
> resolveURI() on it, but it was quite ugly, so since I was already
> using Spring, I switched to 2.2 and what I did was to add a setter for
> a SourceResolver in my base custom tag class and then "dependency
> inject" it via my applicationContext.xml in spring/ folder (my base
> custom tag class uses a @Configurable to let the injections work).

This is indeed a really complex integration and goes beyond the standard 
case. You are using JSPs as templating language inside Cocoon which it 
was never targetted for, but only as XML producer decoupled from the 
rest of Cocoon.

> The wiring works, all my custom tags can use the injected resolver,
> but I HAD to enable the Cocoon JSPReader (map:match pattern="**.jsp",
> map:read src(...) type="jsp") to deliver my jsps, otherwise the called
> resolver would throw an exception saying it requires an Environment
> setup in order to work.
> 
> So, it looks like I'm still using a 2.2 environment abstraction, but
> your post confuses me : would the block:/ protocol ease my integration?

Wondering about your problem I had a look into the code - and the 
environment abstraction indeed still exists. I thought it already has 
been removed. I send this mail to dev list too, maybe somebody can 
comment on this (Daniel, Carsten ?)

For your integration (custom tags accessing Cocoon) the block protocol 
probably can't help. But instead of a CocoonBean you would be able to 
use the RequestProcessor, which should be much more lightweight.

Jörg

Mime
View raw message