cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: [RT]: Session support
Date Mon, 15 Oct 2001 10:58:59 GMT
> Stefano Mazzocchi wrote:
> 
> Carsten Ziegeler wrote:
> > 
> > > Davanum Srinivas wrote:
> > >
> > > Carsten,
> > >
> > > I use the attached CachingStreamPipelineEx and implement
> > > SitemapModelComponent in my Serializer. I
> > > faced this problem a long time back and no one was willing to get
> > > me access to objectModel in my
> > > Serializer. Hence the Hack....
> > >
> > Dims, thanks for your hack - I was just about to start a similar one;
> > so I have saved some time!
> > 
> > Yes, I remember the discussions...and I still agree that the
> > serializer should not know about the objectModel, but he should
> > be able to rewrite urls.
> > 
> > So, we could pass a URLRewriter object into the serializer:
> > 
> > interface URLRewriter {
> >     boolean isURLRewritingEnabled();
> >     String  rewriteURL(String url);
> > }
> > 
> > Any suggestions (or votes!)?
> 
> Link rewriting is going to be vital for proper functioning of Cocoon
> sites, expecially with the webapp componentization that we are
> discussing on the other threads.
> 
> I'd be against making the enviornment objects available to serializers
> because that would turn them into possible changing points that will
> have to be cached as well, while, as today, serializing behavior is
> dependent *ONLY* on the input data and if the input data doesn't change,
> the output doesn't change as well.
> 
> With this in mind, if link translation can be made dependent on the
> input only and not by some other side parameters or system variables,
> I'm all for adding it to the AbstractSerializer, if not, the solution is
> creating a transparent transformer that is automatically added by the
> sitemap right before the serializer in a transparent way, so that uses
> don't have to specify it in the sitemap (and maybe forget to add it).
The serializer needs to know if a url must be rewritten or not. This
depends on information contained in the current request object. So
there is always the dependencies to other information than the input.

I like the idea of a transparent transformer. But how can Cocoon detect,
if this transformer should be used? This depends on the used serializer!
Asume, the user has a session and this is detected using url
rewriting. The user request a html page, this results in using
the transparent transformer and the html serializer. Now the
user requests the source of an xsp page. This results in not
using the transformer and in using the xml serialiuer. And so on.

So I think there is a dependency between a serializer and the
transparent transformer in
a) When to use the transparent transformer
b) What this transformer has to transform (the list of attributes
  containing links)

So this would end up in coding this logik into the serializer
and we have the same problem, again.

For the current caching implementation, there is no real difference
wheter a transparent transformer right before the serializer or 
the serializer itself changes the data. 
In case of url rewriting the pipeline would be cached right before
the transparent transformer or the serializer, and in the case
of no url rewriting the whole response would be cached.


Carsten 

Open Source Group                        sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de                          mailto: cziegeler@sundn.de 
================================================================

> 
> -- 
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message