You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@sundn.de> on 2001/10/08 10:41:21 UTC
[RT]: Session support
Hi Team,
I think it's time for a new rt...so here we go:
Cocoon 2 supports session handling. Mainly this is a feature
supported by the servlet engine and Cocoon simply uses it.
However, writing real world applications requires a little
bit more effort than necessary when it comes to url rewriting.
If your servlet engine uses url rewriting and not cookies,
every url has to be rewritten. Unfortunately this has to
be done manually!
I would like to have it automatically (at least for html)!
What I thought of is enhancing the html serializer, so that
he rewrites urls (links etc) if necessary. Unfortunately
this is not possible, as the serializer does not get the
objectModel!
So a working solution could be a simple transformer before
the serializer which does exactly this.
What can we do?
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [RT]: Session support
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Michael Hartle wrote:
>
> Carsten Ziegeler wrote:
>
> >Hi Team,
> >
> >I think it's time for a new rt...so here we go:
> >
> >Cocoon 2 supports session handling. Mainly this is a feature
> >supported by the servlet engine and Cocoon simply uses it.
> >
> >However, writing real world applications requires a little
> >bit more effort than necessary when it comes to url rewriting.
> >If your servlet engine uses url rewriting and not cookies,
> >every url has to be rewritten. Unfortunately this has to
> >be done manually!
> >I would like to have it automatically (at least for html)!
> >What I thought of is enhancing the html serializer, so that
> >he rewrites urls (links etc) if necessary. Unfortunately
> >this is not possible, as the serializer does not get the
> >objectModel!
> >
> Regarding session handling via url rewriting, why not consider the
> session id to be part of the URI as a directory ? I was in the need of
> something similar to such a session, so I used regexp matchers in the
> sitemap to handle something like
> "http://mysampleweb.net/session/<session-id>/login.html" including other
> pages and sub-directories than only login, passing on the matched
> session id as a parameter. By only using relative links from this point
> on, the browser kept the session in the URI when a link is used, and
> this technique can be used with what we have now without specific
> modification.
>
Ah, the good old WebObjects style! Simple, looking a little bit ugly,
but it works perfectly.
Carsten
> I guess some may see it as a pain if you set up all pipelines for the
> needed pages manually, but this isn't so if you can categorize all pages
> in need and use a pipeline with regexp matchers for each category. But
> this technique could be perfectly handled by the alternative Tree
> Traversal proposal for the sitemap, as far as I followed the discussion,
> by basically handling anything below "/session/<session-id>/",
> extracting the session-id and always passing it as a parameter no matter
> which sub-directories or pages are being requested.
>
> But I think you are generally speaking of an important issue concerning
> the general ability to rewrite URLs in a XML-conforming way. I am still
> preparing to write a XLinkRewriteTransformer which takes a seperate
> configuration file with regexp rewriting rules that will be applied to
> all XLink links; a solution like this might prove to be useful in a
> number of cases, eg. using Cocoon in conjunction with a content
> management system where all the different XML documents stored have
> relative URLs that are valid regarding the document repository, but not
> necessarily anymore when being modified and published through Cocoon.
>
> Best regards,
>
> Michael Hartle
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [RT]: Session support
Posted by Michael Hartle <mh...@hartle-klug.com>.
Carsten Ziegeler wrote:
>Hi Team,
>
>I think it's time for a new rt...so here we go:
>
>Cocoon 2 supports session handling. Mainly this is a feature
>supported by the servlet engine and Cocoon simply uses it.
>
>However, writing real world applications requires a little
>bit more effort than necessary when it comes to url rewriting.
>If your servlet engine uses url rewriting and not cookies,
>every url has to be rewritten. Unfortunately this has to
>be done manually!
>I would like to have it automatically (at least for html)!
>What I thought of is enhancing the html serializer, so that
>he rewrites urls (links etc) if necessary. Unfortunately
>this is not possible, as the serializer does not get the
>objectModel!
>
Regarding session handling via url rewriting, why not consider the
session id to be part of the URI as a directory ? I was in the need of
something similar to such a session, so I used regexp matchers in the
sitemap to handle something like
"http://mysampleweb.net/session/<session-id>/login.html" including other
pages and sub-directories than only login, passing on the matched
session id as a parameter. By only using relative links from this point
on, the browser kept the session in the URI when a link is used, and
this technique can be used with what we have now without specific
modification.
I guess some may see it as a pain if you set up all pipelines for the
needed pages manually, but this isn't so if you can categorize all pages
in need and use a pipeline with regexp matchers for each category. But
this technique could be perfectly handled by the alternative Tree
Traversal proposal for the sitemap, as far as I followed the discussion,
by basically handling anything below "/session/<session-id>/",
extracting the session-id and always passing it as a parameter no matter
which sub-directories or pages are being requested.
But I think you are generally speaking of an important issue concerning
the general ability to rewrite URLs in a XML-conforming way. I am still
preparing to write a XLinkRewriteTransformer which takes a seperate
configuration file with regexp rewriting rules that will be applied to
all XLink links; a solution like this might prove to be useful in a
number of cases, eg. using Cocoon in conjunction with a content
management system where all the different XML documents stored have
relative URLs that are valid regarding the document repository, but not
necessarily anymore when being modified and published through Cocoon.
Best regards,
Michael Hartle
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Session support
Posted by Gianugo Rabellino <gi...@rabellino.it>.
Ciao Carsten,
> If your servlet engine uses url rewriting and not cookies,
> every url has to be rewritten. Unfortunately this has to
> be done manually!
> I would like to have it automatically (at least for html)!
> What I thought of is enhancing the html serializer, so that
> he rewrites urls (links etc) if necessary. Unfortunately
> this is not possible, as the serializer does not get the
> objectModel!
As you might remember I've banged my head against the very same wall
some time ago, when I asked how to solve the relative URI problems
related to serializers that embed resources directly in the output
stream (I was writing at that time the RTF serializer, but the same goes
for all the FOP output formats).
Stefano finally explained to me that the problem with serializers is
related to the cache engine, yet I still think that placing another
transformer in front of a Serializer might be error prone (you must
remember to use it anywhere) and might end up in just a complex way to
fool Cocoon using infact a "smart" serializer instead. This doesn't make
sense to me: it's pretty trivial to write a transformer that adds a
bunch of XML infos containing an objectModel dump, but I fail to see the
point in doing so, I'd rather find another solution or see the
Serializer APIs changed.
What I was thinking about (it might solve your specific problem too) was
a generic "Link Normalizer" Transformer that acts on a number of
tag/parameters (say "href", "src" and XLink stuff) and, based on some
configuration, does some work such as translate relative links to
absolute and append strings and parameters to them. This is a bit more
generic, yet it still seems to me a not so clean workaround.
In any case, however, this is going to be quite a mess.
Ciao,
--
Gianugo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: Session support
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> Hi Team,
>
> I think it's time for a new rt...so here we go:
>
> Cocoon 2 supports session handling. Mainly this is a feature
> supported by the servlet engine and Cocoon simply uses it.
>
> However, writing real world applications requires a little
> bit more effort than necessary when it comes to url rewriting.
> If your servlet engine uses url rewriting and not cookies,
> every url has to be rewritten. Unfortunately this has to
> be done manually!
> I would like to have it automatically (at least for html)!
> What I thought of is enhancing the html serializer, so that
> he rewrites urls (links etc) if necessary. Unfortunately
> this is not possible, as the serializer does not get the
> objectModel!
> So a working solution could be a simple transformer before
> the serializer which does exactly this.
>
> What can we do?
Regular redirects and such already use URL rewriting. To
accomplish what you need, you will have to write a transformer
to process all "href" attributes and rewrite the links.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [RT]: Session support
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Jörg Prante wrote:
>
> Hi Carsten,
>
> On Montag, 8. Oktober 2001 11:43, Carsten Ziegeler wrote:
>
> > In some way it is media dependent, as the media determines the
> > format (html, wml etc) and this format specifies what has to be
> > encoded.
>
> Yes, but HTML does not know about URL rewriting. You have to
> fiddle around by
> yourself what tags and attributes has to be examined to get your result.
> Session tracking is protocol dependant. The server knows how to provide
> sessions for the served documents, and how to enrich stateless
> protocols with
> stateful information. So Cocoon must "emulate" a session protocol
> using html
> features like link following and forms.
It is correct that HTML does not know about URL rewriting, but HTML
as a language defines the tags/attributes which must be rewritten.
>
> > The other reason for using the serializer is transparency. You
> > don't have to care about url rewriting. Simply build your pipeline
> > as usual and Cocoon takes care of when to url rewrite and when not.
>
> Can Cocoon take care of all cases automatically? Hm. I think it's more
> complex. A typical scenario is a web application with internal
> and external
> resources which are application specific. Cocoon should be able to select
> between internal and external URLs. There may be more types of URLs. Some
> links lead to external resources, they shoud not be rewritten at
> all, while
> internal resources might be distributed over the local host, but
> also other
> hosts and/or domains (e.g. load balancing). Cocoon should be
> configurable to
> domains/hosts of the URLs to be rewritten. Just a little bit like
> cookies can
> be adressed.
>
The usual url rewriting mechanism (provided by the servlet engine,
or more precisely the response object) takes care of this.
Carsten
> Jörg
>
> ---------------------------------------------------------------------
> 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
Re: AW: [RT]: Session support
Posted by Jörg Prante <jo...@gmx.de>.
Hi Carsten,
On Montag, 8. Oktober 2001 11:43, Carsten Ziegeler wrote:
> In some way it is media dependent, as the media determines the
> format (html, wml etc) and this format specifies what has to be
> encoded.
Yes, but HTML does not know about URL rewriting. You have to fiddle around by
yourself what tags and attributes has to be examined to get your result.
Session tracking is protocol dependant. The server knows how to provide
sessions for the served documents, and how to enrich stateless protocols with
stateful information. So Cocoon must "emulate" a session protocol using html
features like link following and forms.
> The other reason for using the serializer is transparency. You
> don't have to care about url rewriting. Simply build your pipeline
> as usual and Cocoon takes care of when to url rewrite and when not.
Can Cocoon take care of all cases automatically? Hm. I think it's more
complex. A typical scenario is a web application with internal and external
resources which are application specific. Cocoon should be able to select
between internal and external URLs. There may be more types of URLs. Some
links lead to external resources, they shoud not be rewritten at all, while
internal resources might be distributed over the local host, but also other
hosts and/or domains (e.g. load balancing). Cocoon should be configurable to
domains/hosts of the URLs to be rewritten. Just a little bit like cookies can
be adressed.
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [RT]: Session support
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Torsten Curdt wrote:
>
> > Hi Team,
> >
> > I think it's time for a new rt...so here we go:
> >
> > Cocoon 2 supports session handling. Mainly this is a feature
> > supported by the servlet engine and Cocoon simply uses it.
> >
> > However, writing real world applications requires a little
> > bit more effort than necessary when it comes to url rewriting.
> > If your servlet engine uses url rewriting and not cookies,
> > every url has to be rewritten. Unfortunately this has to
> > be done manually!
> > I would like to have it automatically (at least for html)!
> > What I thought of is enhancing the html serializer, so that
> > he rewrites urls (links etc) if necessary. Unfortunately
> > this is not possible, as the serializer does not get the
> > objectModel!
>
> I don't think this is a media dependent need so I don't think
> this should happen in a serializer.
>
In some way it is media dependent, as the media determines the
format (html, wml etc) and this format specifies what has to be
encoded.
The other reason for using the serializer is transparency. You
don't have to care about url rewriting. Simply build your pipeline
as usual and Cocoon takes care of when to url rewrite and when not.
> > So a working solution could be a simple transformer before
> > the serializer which does exactly this.
>
> We have done something similar:
>
> <dlink:link uri="somehting">
> <dlink:parameter name="parameter" value="thevalue"/>
> Link
> </dlink:link>
>
> The dlink transformer adds the constructed URL to the dlink:link
> tag. Since this happens in a transformer we can also encode the URL.
Yes, we did the same, too. And I bet, many others did it as well
with their own transformer.
The bad think of transformers is: you have to use it (which means
you have to include it in your pipeline).
Carsten
> --
> Torsten
>
> ---------------------------------------------------------------------
> 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
RE: [RT]: Session support
Posted by Torsten Curdt <tc...@dff.st>.
> Hi Team,
>
> I think it's time for a new rt...so here we go:
>
> Cocoon 2 supports session handling. Mainly this is a feature
> supported by the servlet engine and Cocoon simply uses it.
>
> However, writing real world applications requires a little
> bit more effort than necessary when it comes to url rewriting.
> If your servlet engine uses url rewriting and not cookies,
> every url has to be rewritten. Unfortunately this has to
> be done manually!
> I would like to have it automatically (at least for html)!
> What I thought of is enhancing the html serializer, so that
> he rewrites urls (links etc) if necessary. Unfortunately
> this is not possible, as the serializer does not get the
> objectModel!
I don't think this is a media dependent need so I don't think
this should happen in a serializer.
> So a working solution could be a simple transformer before
> the serializer which does exactly this.
We have done something similar:
<dlink:link uri="somehting">
<dlink:parameter name="parameter" value="thevalue"/>
Link
</dlink:link>
The dlink transformer adds the constructed URL to the dlink:link
tag. Since this happens in a transformer we can also encode the URL.
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [RT]: Session support
Posted by Peter Royal <pr...@managingpartners.com>.
At 02:07 PM 10/8/2001 +0200, you wrote:
>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.
This is a need we will be having over here soon. Right now we're using
cookie-based session tracking, but will need to switch to URL-based before
we ship so users can have multiple browser windows of our application up at
one time.
>So, we could pass a URLRewriter object into the serializer:
>
>interface URLRewriter {
> boolean isURLRewritingEnabled();
> String rewriteURL(String url);
>}
>
>Any suggestions (or votes!)?
I think that approach is a good middle ground. I understand the arguments
against why the Serializer should not have access to the objectModel.
Although using a transformer immediately before the serializer is a valid
solution to the problem, I too would appreciate something a bit more
transparent, so the user that is constructing the sitemap pipelines does
not have to worry about how the servlet container has been set up to handle
sessions (SoC!) :)
-pete
--
peter royal -> proyal@managingpartners.com
managing partners, inc. -> http://www.managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [RT]: Session support
Posted by Joerg Henne <j....@levigo.de>.
Hi,
Carsten Ziegeler wrote:
>
> 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!)?
while we're at that, I'd like to point out another problem within this
context: it should be the serializer's job to perform HTTP redirects. The
reason for this is that, although the response status is set to 302 and the
Location header is set, the response usually contains at least some content
which contains a textual description of what happened, e.g. an HTML document
saying that the "Document has moved here". Without this content, clients which
are unable to handle redirects are lost. While this is not a problem with HTML
as there are virtually no clients out there which can't handle redirects, I
had to learn the hard way, that this can be a huge problem with WAP and WML.
There seems to be a number of WAP gateways out there which become utterly
confused if they see a 302 in conjunction with an HTML response (e.g. Vodafone
D2's). For these gateways one should provide a proper WML stack or at least
nothing at all.
Unfortunately, I don't have a solution for this problem available at the
moment. I think it will require some major plumbing within the sitemap
processor.
Joerg Henne
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [RT]: Session support
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hi Stefano,
> Stefano Mazzocchi wrote:
>
> Carsten Ziegeler wrote:
>
> > 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.
>
> hmmmm, I disagree: is the transparent transformer that must evaluate
> xlinks, not the serializer. Thus, the serializer doesn't need (nor
> should!) any 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!
>
> It should not.
>
> > 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.
>
> Sorry, but I don't get it: if you instruct the sitemap engine to append
> a transparent link-evaluating transformer to every pipeline right before
> the serializer, you get what you want. Really, I don't see the problem.
>
Hm, perhaps here is our difference. What do you mean by "instruct the
sitemap engine to append..". If this is a manual approach, where the
sitemap editor explicitly chooses where the transformer should be used,
then you're right.
But again, if this should happen automatically, I don't know how this
should work. Let me try to explain it more by using a stupid example.
Assume the following two pipelines:
<map:match pattern="page">
<map:generate src="myxml.xml"/>
<map:transform src="xml2html.xsl"/>
<map:serialize/>
</map:match>
<map:match pattern="source">
<map:generate src="myxml.xml"/>
<map:serialize type="xml"/>
</map:match>
Assume that - for any reason - the "myxml.xml" contains links. Now if
these links are transformed in both cases with the transparent transformer
the "source" pipeline doesn't display the correct source.
Perhaps I'm wrong, and the source should also be transformed by
the transparent transformer, then again you're right and I loose.
But I feel, that the transparent transformer should not always be used.
Carsten
> > 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.
>
> I still believe that serializers are somewhat special components and
> should not have a side entry for data.... also because I believe that
> serializers should be removed from pipeline definitions... but this is
> another story.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@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
Re: AW: [RT]: Session support
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> 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.
hmmmm, I disagree: is the transparent transformer that must evaluate
xlinks, not the serializer. Thus, the serializer doesn't need (nor
should!) any 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!
It should not.
> 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.
Sorry, but I don't get it: if you instruct the sitemap engine to append
a transparent link-evaluating transformer to every pipeline right before
the serializer, you get what you want. Really, I don't see the problem.
> 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.
I still believe that serializers are somewhat special components and
should not have a side entry for data.... also because I believe that
serializers should be removed from pipeline definitions... but this is
another story.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [RT]: Session support
Posted by Carsten Ziegeler <cz...@sundn.de>.
> 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.
> <st...@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
Re: AW: [RT]: Session support
Posted by Stefano Mazzocchi <st...@apache.org>.
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).
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [RT]: Session support
Posted by Carsten Ziegeler <cz...@sundn.de>.
> 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!)?
Carsten
> Thanks,
> dims
>
> --- Carsten Ziegeler <cz...@sundn.de> wrote:
> > Hi Team,
> >
> > I think it's time for a new rt...so here we go:
> >
> > Cocoon 2 supports session handling. Mainly this is a feature
> > supported by the servlet engine and Cocoon simply uses it.
> >
> > However, writing real world applications requires a little
> > bit more effort than necessary when it comes to url rewriting.
> > If your servlet engine uses url rewriting and not cookies,
> > every url has to be rewritten. Unfortunately this has to
> > be done manually!
> > I would like to have it automatically (at least for html)!
> > What I thought of is enhancing the html serializer, so that
> > he rewrites urls (links etc) if necessary. Unfortunately
> > this is not possible, as the serializer does not get the
> > objectModel!
> > So a working solution could be a simple transformer before
> > the serializer which does exactly this.
> >
> > What can we do?
> >
> > Carsten
> >
> > Open Source Group sunShine - b:Integrated
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto: cziegeler@sundn.de
> > ================================================================
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
>
> =====
> Davanum Srinivas, JNI-FAQ Manager
> http://www.jGuru.com/faq/JNI
>
> __________________________________________________
> Do You Yahoo!?
> NEW from Yahoo! GeoCities - quick and easy web site hosting, just
> $8.95/month.
> http://geocities.yahoo.com/ps/info1
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: Session support
Posted by Davanum Srinivas <di...@yahoo.com>.
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....
Thanks,
dims
--- Carsten Ziegeler <cz...@sundn.de> wrote:
> Hi Team,
>
> I think it's time for a new rt...so here we go:
>
> Cocoon 2 supports session handling. Mainly this is a feature
> supported by the servlet engine and Cocoon simply uses it.
>
> However, writing real world applications requires a little
> bit more effort than necessary when it comes to url rewriting.
> If your servlet engine uses url rewriting and not cookies,
> every url has to be rewritten. Unfortunately this has to
> be done manually!
> I would like to have it automatically (at least for html)!
> What I thought of is enhancing the html serializer, so that
> he rewrites urls (links etc) if necessary. Unfortunately
> this is not possible, as the serializer does not get the
> objectModel!
> So a working solution could be a simple transformer before
> the serializer which does exactly this.
>
> What can we do?
>
> Carsten
>
> Open Source Group sunShine - b:Integrated
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto: cziegeler@sundn.de
> ================================================================
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1