You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jon Evans <jo...@misgl.com> on 2004/04/02 13:57:47 UTC
CachingURICoplet and cl:links caching too aggressively - possible fix?
Hi,
I have a few CachingURICoplets which use cl:links to set various
values. The most common is a paging bar to page through data, similar
to the Goooooooogle links at the bottom of the google results page.
Each does something like:
<cl:link class="page" path="attributes/page"
value="{@id}">
<xsl:value-of select="@id" />
</cl:link>
That's an extract from one of my xslts, transforming <block> elements
created by the filter transformer.
The problem is that once they are generated and cached, they only work
once. This is because they get transformed to a link that looks like
portal?cocoon-portal-action=1&cocoon-portal-event=0 and the
cocoon-portal-action number only works for the page it's generated on.
Now could someone please check my understanding of the way this works.
The link as it is stated above works because when the CopletTransformer
runs in the pipeline of the specific coplet, it knows the ID of the
coplet so it can set up the events properly.
How about a change: we (I :-)) create a new transformer which runs in
the coplet pipeline instead of the CopletTransformer. It looks for
cl:link elements which omit the coplet="CopletID" parameter, and adds
the attribute, with the current coplet ID as the value. At that point,
the output xml of that particular coplet is saved in the cache with the
cl:link tags still in place and unconverted.
Then we can run the CopletTransformer once in the final page pipeline,
and it will convert all of the cl:link tags for all coplets in the
page.
Thougths?
Jon
RE: CachingURICoplet and cl:links caching too aggressively - possible fix?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Christian Mayrhuber wrote:
>
> >
> > The final step, converting the events to links should not
> be done in
> > the pipelines of your coplet but in the main pipeline
> rendering your
> > portal. So on each request the events are transformed into
> new links
> > and although the content of the coplet is cached, the links still
> > work. The current portal demo works exactly this way.
> 1) This means if the events are generated in the coplet
> pipelines the stuff stops working?
It only stops working if your use the caching coplet adapter.
If the content for the coplet is created each time the coplet
is displayed, it works.
> I'm asking this because I've written a custom HTMLLink ->
> CopletJXPathEvent transformer mainly for use with the
> ProxyTransformer and ApplicationCoplet which does excactly
>
> JXPathEvent event = new CopletJXPathEvent(cid, jxPath, link);
> String uri = linkService.getLinkURI(event);
>
> and is called in the pipeline, because it requires specific
> settings for some sites that are proxied.
>
This would only work without caching or if you would move the
transformer to the main pipeline.
> 2) I guess it has to do with the fact that I'm using the
> bookmark feature for the first tab, but not for the other
> ones, because these do not need to have human readable url's.
> The LinkService nevertheless generates urls's like
> /portal/bookmark?cocoon-portal-event=0
> for the non-bookmarkable tabs.
> Can bookmarks and "standard" events be used together with the
> tab-layout?
> As far I've read through the source the BookmarkAction does
> not kill the
> cocoon-portal-* request parameters and they should reach the portal.
>
Yes, I think this should work - but I have not tested it :)
Carsten
Re: CachingURICoplet and cl:links caching too aggressively - possible fix?
Posted by Christian Mayrhuber <ch...@gmx.net>.
On Monday 05 July 2004 16:44, Carsten Ziegeler wrote:
> As far as I remember, everything should work :) There are two things
> you should consider when writing your coplets:
>
> The cocoon portal provides all required functionality for forms (POST
> and GET) and flow including the caching. For this you should use the
> html event link transformer.
> Examples are the calculator and the application coplet in the cocoon
> portal demo.
>
> [http://cocoon.apache.org/2.1/developing/portal/forms.html]
Thanks.
The coplets are working fine if I enter a tab and stay in it. ;-)
>
> The final step, converting the events to links should not be done
> in the pipelines of your coplet but in the main pipeline rendering
> your portal. So on each request the events are transformed into
> new links and although the content of the coplet is cached,
> the links still work. The current portal demo works exactly this way.
1) This means if the events are generated in the coplet pipelines the stuff
stops working?
I'm asking this because I've written a custom HTMLLink -> CopletJXPathEvent
transformer mainly for use with the ProxyTransformer and ApplicationCoplet
which does excactly
JXPathEvent event = new CopletJXPathEvent(cid, jxPath, link);
String uri = linkService.getLinkURI(event);
and is called in the pipeline, because it requires specific settings for
some sites that are proxied.
2) I guess it has to do with the fact that I'm using the bookmark feature
for the first tab, but not for the other ones, because these do not need to
have human readable url's.
The LinkService nevertheless generates urls's like
/portal/bookmark?cocoon-portal-event=0
for the non-bookmarkable tabs.
Can bookmarks and "standard" events be used together with the tab-layout?
As far I've read through the source the BookmarkAction does not kill the
cocoon-portal-* request parameters and they should reach the portal.
>
> The portal currently does not really "disable" the back button,
> the user can still click on it. But in this case, the page is
> reloaded and the user gets a fresh view of the portal.
OK, that refresh seems to do something odd in my installation.
On every back button push I get a view of the tab with the number
current tab - 1, except it's tab 0.
> Please note also that the html event link transformer has a serious
> bug in 2.1.5 which is fixed in the current head of CVS.
I'm already using this version, thanks!
The jar's are cocoon-2.1.5, only HTMLEventLinkTransformer from
cvs is in the classpath.
>
> HTH
> Carsten
--
lg, Chris
RE: CachingURICoplet and cl:links caching too aggressively - possible fix?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
As far as I remember, everything should work :) There are two things
you should consider when writing your coplets:
The cocoon portal provides all required functionality for forms (POST
and GET) and flow including the caching. For this you should use the
html event link transformer.
Examples are the calculator and the application coplet in the cocoon
portal demo.
[http://cocoon.apache.org/2.1/developing/portal/forms.html]
The final step, converting the events to links should not be done
in the pipelines of your coplet but in the main pipeline rendering
your portal. So on each request the events are transformed into
new links and although the content of the coplet is cached,
the links still work. The current portal demo works exactly this way.
The portal currently does not really "disable" the back button,
the user can still click on it. But in this case, the page is
reloaded and the user gets a fresh view of the portal.
Please note also that the html event link transformer has a serious
bug in 2.1.5 which is fixed in the current head of CVS.
HTH
Carsten
> -----Original Message-----
> From: Christian Mayrhuber [mailto:cmayr@iicm.tu-graz.ac.at]
> Sent: Monday, July 05, 2004 4:20 PM
> To: dev@cocoon.apache.org
> Subject: Re: CachingURICoplet and cl:links caching too
> aggressively - possible fix?
>
> On Friday 02 April 2004 18:18, Jon Evans wrote:
> > Hi Carsten,
> >
> > On 2 Apr 2004, at 15:07, Carsten Ziegeler wrote:
> > > The action-counter in the portal was thought to be the
> solution to
> > > get this fixed in a nice way. But actually this solution is too
> > > error prone and causes too many problems. I just updated the CVS
> > > with a better solution.
> > > When the user now clicks the back button a new request is send to
> > > the server, and the user sees exactly the same state as
> the page before.
> > > So,
> > > the user never gets into a broken state which is imho very
> > > important for web applications.
> >
> > Just tried it out with my site.
> >
> > Even without the action counter, it seems that a cached
> cl:link will
> > still only work once. e.g. a page is generated with my
> > CachingURICoplet on it, the coplet has a link for page 2
> which works.
> > If I click another tab then clickto go back to the first page, the
> > page links in my coplet don't work any more. I'm assuming that the
> > portal generates all the cocoon-portal-event=n numbers
> starting at 1
> > each time, and the number that my coplet got is no longer valid.
> Anything new on this?
> I've gotten the exactly same behaviour of broken page links
> after a tab switch when using the CachingURICoplet.
> I'm using cocoon-2.1.5 without the action-counter but with
> the no-client-caching EventAspect and with the CachingURICoplet.
> The only way around broken site links is to rewrite them to
> use the bookmark feature, but that stops working as soon a
> form with a post request is used in a coplet.
>
> Currently the events are generated like:
> // Create a new jxpath event
> JXPathEvent event = new CopletJXPathEvent(cid, jxPath, link);
> String uri = linkService.getLinkURI(event);
>
> Would it help to generate two events, one jxpath event and
> one with the layout information?
>
> >
> > Yes, just verified it. The links get numbered off from 1
> as they are
> > processed, the second time the page loads my coplet comes from the
> > cache, so its links don't get processed. Some other coplet
> gets the
> > event numbers that were already cached by my coplet, so the
> links in
> > my coplet end up firing the same event as the unrelated
> links in the
> > other coplet.
> >
> > So back to my earlier plan, I think it would be better if
> there was a
> > transformer in the pipeline of each coplet which just made
> sure that
> > coplet="copletid" was added to each cl:link tag, then run the whole
> > page through the portal-coplet transformer before it is
> served to the
> > browser.
> >
> > Jon
>
>
> Btw. firefox-0.8 and IE6 still do not disable the back button.
> Mozilla Live Headers outputs:
>
> HTTP/1.x 200 OK
> X-Cocoon-Version: 2.1.5
> Cache-Control: no-cache, no-store, no-store
> Pragma: no-cache
> Expires: Thu, 01 Jan 2000 00:00:00 GMT
> Content-Type: text/html
> Transfer-Encoding: chunked
> Date: Mon, 05 Jul 2004 13:10:17 GMT
> Server: Apache-Coyote/1.1
>
> I guess the only option to be safe is to use client side JavaScript.
>
> Please, CC me directly because I'm only subscribed to
> dev-digest, or expect a delay of my response.
>
> --
> lg, Chris
>
>
Re: CachingURICoplet and cl:links caching too aggressively - possible fix?
Posted by Christian Mayrhuber <cm...@iicm.tu-graz.ac.at>.
On Friday 02 April 2004 18:18, Jon Evans wrote:
> Hi Carsten,
>
> On 2 Apr 2004, at 15:07, Carsten Ziegeler wrote:
> > The action-counter in the portal was thought to be the solution to get
> > this
> > fixed in a nice way. But actually this solution is too error prone and
> > causes too many problems. I just updated the CVS with a better
> > solution.
> > When the user now clicks the back button a new request is send to the
> > server, and the user sees exactly the same state as the page before.
> > So,
> > the user never gets into a broken state which is imho very important
> > for
> > web applications.
>
> Just tried it out with my site.
>
> Even without the action counter, it seems that a cached cl:link will
> still only work once. e.g. a page is generated with my
> CachingURICoplet on it, the coplet has a link for page 2 which works.
> If I click another tab then clickto go back to the first page, the page
> links in my coplet don't work any more. I'm assuming that the portal
> generates all the cocoon-portal-event=n numbers starting at 1 each
> time, and the number that my coplet got is no longer valid.
Anything new on this?
I've gotten the exactly same behaviour of broken page links after a
tab switch when using the CachingURICoplet.
I'm using cocoon-2.1.5 without the action-counter but with the
no-client-caching EventAspect and with the CachingURICoplet.
The only way around broken site links is to rewrite them to use the bookmark
feature, but that stops working as soon a form with a post request is used in
a coplet.
Currently the events are generated like:
// Create a new jxpath event
JXPathEvent event = new CopletJXPathEvent(cid, jxPath, link);
String uri = linkService.getLinkURI(event);
Would it help to generate two events, one jxpath event and one with the layout
information?
>
> Yes, just verified it. The links get numbered off from 1 as they are
> processed, the second time the page loads my coplet comes from the
> cache, so its links don't get processed. Some other coplet gets the
> event numbers that were already cached by my coplet, so the links in my
> coplet end up firing the same event as the unrelated links in the other
> coplet.
>
> So back to my earlier plan, I think it would be better if there was a
> transformer in the pipeline of each coplet which just made sure that
> coplet="copletid" was added to each cl:link tag, then run the whole
> page through the portal-coplet transformer before it is served to the
> browser.
>
> Jon
Btw. firefox-0.8 and IE6 still do not disable the back button.
Mozilla Live Headers outputs:
HTTP/1.x 200 OK
X-Cocoon-Version: 2.1.5
Cache-Control: no-cache, no-store, no-store
Pragma: no-cache
Expires: Thu, 01 Jan 2000 00:00:00 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Date: Mon, 05 Jul 2004 13:10:17 GMT
Server: Apache-Coyote/1.1
I guess the only option to be safe is to use
client side JavaScript.
Please, CC me directly because I'm only subscribed to dev-digest, or expect a
delay of my response.
--
lg, Chris
Re: CachingURICoplet and cl:links caching too aggressively - possible fix?
Posted by Jon Evans <jo...@misgl.com>.
Hi Carsten,
On 2 Apr 2004, at 15:07, Carsten Ziegeler wrote:
> The action-counter in the portal was thought to be the solution to get
> this
> fixed in a nice way. But actually this solution is too error prone and
> causes too many problems. I just updated the CVS with a better
> solution.
> When the user now clicks the back button a new request is send to the
> server, and the user sees exactly the same state as the page before.
> So,
> the user never gets into a broken state which is imho very important
> for
> web applications.
Just tried it out with my site.
Even without the action counter, it seems that a cached cl:link will
still only work once. e.g. a page is generated with my
CachingURICoplet on it, the coplet has a link for page 2 which works.
If I click another tab then clickto go back to the first page, the page
links in my coplet don't work any more. I'm assuming that the portal
generates all the cocoon-portal-event=n numbers starting at 1 each
time, and the number that my coplet got is no longer valid.
Yes, just verified it. The links get numbered off from 1 as they are
processed, the second time the page loads my coplet comes from the
cache, so its links don't get processed. Some other coplet gets the
event numbers that were already cached by my coplet, so the links in my
coplet end up firing the same event as the unrelated links in the other
coplet.
So back to my earlier plan, I think it would be better if there was a
transformer in the pipeline of each coplet which just made sure that
coplet="copletid" was added to each cl:link tag, then run the whole
page through the portal-coplet transformer before it is served to the
browser.
Jon
RE: CachingURICoplet and cl:links caching too aggressively - possible fix?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sorry for the delay, I overlooked this...
Done.
Carsten
> -----Original Message-----
> From: Jon Evans [mailto:jon.evans@misgl.com]
> Sent: Monday, April 05, 2004 11:44 AM
> To: dev@cocoon.apache.org
> Subject: Re: CachingURICoplet and cl:links caching too
> aggressively - possible fix?
>
> Hi,
> On 4 Apr 2004, at 18:00, Vadim Gritsenko wrote:
>
> > Try this instead. Works for me.
> >
> > http://www.mozilla.org/projects/netlib/http/http-caching-faq.html
>
> Confirmed - adding Cache-Control: no-store properly disables
> the back button, in Mozilla at least.
>
> Carsten, please can you add that to NoClientCachingEventAspect?
>
> Cheers,
>
> Jon
>
Re: CachingURICoplet and cl:links caching too aggressively - possible fix?
Posted by Jon Evans <jo...@misgl.com>.
Hi,
On 4 Apr 2004, at 18:00, Vadim Gritsenko wrote:
> Try this instead. Works for me.
>
> http://www.mozilla.org/projects/netlib/http/http-caching-faq.html
Confirmed - adding Cache-Control: no-store properly disables the back
button, in Mozilla at least.
Carsten, please can you add that to NoClientCachingEventAspect?
Cheers,
Jon
Re: CachingURICoplet and cl:links caching too aggressively - possible
fix?
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jon Evans wrote:
> HTTP/1.x 200 OK
> Date: Fri, 02 Apr 2004 15:43:04 GMT
> Server: Jetty/4.2.14 (Mac OS X/10.3.3 ppc java/1.4.2_03)
> X-Cocoon-Version: 2.1.5-dev
> Transfer-Encoding: chunked
> Expires: Thu, 01 Jan 2000 00:00:00 GMT <== HERE
> Content-Type: text/html
> Cache-Control: no-cache <== HERE
> Pragma: no-cache <== HERE
>
> However in Mozilla, Firefox, Safari and IE 5.2 (all Mac OS X) the back
> button still works - the browser displays the previous page and then
> is out of sync with the server state.
Try this instead. Works for me.
http://www.mozilla.org/projects/netlib/http/http-caching-faq.html
Vadim
Re: CachingURICoplet and cl:links caching too aggressively - possible fix?
Posted by Jon Evans <jo...@misgl.com>.
Hi Carsten,
On 2 Apr 2004, at 15:07, Carsten Ziegeler wrote:
> This is the question to answer :) For portals (or any other application
> where
> the user can change the state), the back button is "evil". The user
> minimizes
> a coplet and then maximizes the coplet again. The state of the coplet
> is
> managed on the server. Now the user clicks "back", he sees the coplet
> minimized
> and assumes that it is minimized now, but of course the server doesn't
> know anything about it. And this is true for every state change.
> (Assume
> an order form that the user sends twice because of using the back
> button
> etc.)
>
> That's why I always try to "disable" the back button so the user can
> never reach a broken state.
I understand now - yes, it makes sense to stop the back button from
working.
> The action-counter in the portal was thought to be the solution to get
> this
> fixed in a nice way. But actually this solution is too error prone and
> causes too many problems. I just updated the CVS with a better
> solution.
> When the user now clicks the back button a new request is send to the
> server, and the user sees exactly the same state as the page before.
> So,
> the user never gets into a broken state which is imho very important
> for
> web applications.
I've verified (with the Mozilla "Live HTTP Headers" module) that the
three headers you added are being sent to the browser:
HTTP/1.x 200 OK
Date: Fri, 02 Apr 2004 15:43:04 GMT
Server: Jetty/4.2.14 (Mac OS X/10.3.3 ppc java/1.4.2_03)
X-Cocoon-Version: 2.1.5-dev
Transfer-Encoding: chunked
Expires: Thu, 01 Jan 2000 00:00:00 GMT <== HERE
Content-Type: text/html
Cache-Control: no-cache <== HERE
Pragma: no-cache <== HERE
However in Mozilla, Firefox, Safari and IE 5.2 (all Mac OS X) the back
button still works - the browser displays the previous page and then is
out of sync with the server state.
Does it work for you?
Cheers,
Jon
RE: CachingURICoplet and cl:links caching too aggressively - possible fix?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Jon Evans wrote:
>
> Hi Carsten,
>
> On 2 Apr 2004, at 13:21, Carsten Ziegeler wrote:
>
> > you're suggested solution would work. But this would
> require that you
> > always use your new transformer in every place and be careful when
> > generating links.
> >
> > In general, if you're using the CachingURICoplet you shouldn't use
> > the action-counter at all.
> >
> > I think more and more while the action counter was a good
> idea, it's
> > better to disable the action-counter and replace it by a component
> > that forces the browser to reload the page when the back button is
> > used.
>
> Well, either way the site will appear to be "broken" as far
> as the user is concerned. If they click "back" they expect
> to see the previous page.
>
This is the question to answer :) For portals (or any other application
where
the user can change the state), the back button is "evil". The user
minimizes
a coplet and then maximizes the coplet again. The state of the coplet is
managed on the server. Now the user clicks "back", he sees the coplet
minimized
and assumes that it is minimized now, but of course the server doesn't
know anything about it. And this is true for every state change. (Assume
an order form that the user sends twice because of using the back button
etc.)
That's why I always try to "disable" the back button so the user can
never reach a broken state.
The action-counter in the portal was thought to be the solution to get this
fixed in a nice way. But actually this solution is too error prone and
causes too many problems. I just updated the CVS with a better solution.
When the user now clicks the back button a new request is send to the
server, and the user sees exactly the same state as the page before. So,
the user never gets into a broken state which is imho very important for
web applications.
> I am now moving more towards using bookmark events within the site.
> For instance because of the cl:link caching issue I've
> changed my paging links to a href=bookmark?page=n and just
> set up bookmarks.xml to pass the value on to the right coplet.
>
> If every link on the site used the bookmarks feature, the
> back button would work fine. Ignoring continuations, not
> sure about them.
>
> Rambling a bit:
>
> How about some sort of transformer that worked more like bookmarks.
> For instance the links generated for each tab in a layout
> could be something like layout?top=n, where top is the id of
> the layout. Except it would work automatically.
>
> (bear in mind with the following that I don't really know how
> the event thing works:)
>
> It seems that we start off with the coplet knowing the
> parameters it needs to set, and the values for them. Then
> all that information gets remembered server-side, and
> translated into something else (that is only valid for that
> page). Then when the user clicks a link the process is
> reversed, we find out what events we remembered earlier and fire them.
>
> So instead of:
>
> [coplet]
> set attributes/page to 1
> |
> v
> [event]
> remember that event-1 = set attibute/page of coplet to 1
> |
> v
> [page]
> link href=event-1
> |
> v
> click -> look up events -> fire events
>
Yes, this is the way it works right now.
>
>
> why can't we make it work like this:
>
> [coplet]
> set attributes/page to 1
> |
> v
> [page]
> link href=event?coplet.attributes.page=1
> |
> v
> click -> create events -> fire events
>
> I know one reason - the whole attributes map for the site is
> open to abuse, other parameters could be set by appending the
> appropriate parameter. But if that could be checked for on
> submit, the problem goes away and the back button works again.
>
Yes, this is one reason. The other one is that the events could
contain any Java objects/information that perhaps can't be
encoded into a string that easy. That's why this encoding takes
place.
Now, the portal is highly configurable and it is possible to do
it the way you describe by exchanging some components/changing
the configuration. But don't ask me which one to change :)
HTH
Carsten
Re: CachingURICoplet and cl:links caching too aggressively - possible fix?
Posted by Jon Evans <jo...@misgl.com>.
Hi Carsten,
On 2 Apr 2004, at 13:21, Carsten Ziegeler wrote:
> you're suggested solution would work. But this would require that
> you always use your new transformer in every place and be careful
> when generating links.
>
> In general, if you're using the CachingURICoplet you shouldn't
> use the action-counter at all.
>
> I think more and more while the action counter was a good idea,
> it's better to disable the action-counter and replace it by a
> component that forces the browser to reload the page when
> the back button is used.
Well, either way the site will appear to be "broken" as far as the user
is concerned. If they click "back" they expect to see the previous
page.
I am now moving more towards using bookmark events within the site.
For instance because of the cl:link caching issue I've changed my
paging links to a href=bookmark?page=n and just set up bookmarks.xml to
pass the value on to the right coplet.
If every link on the site used the bookmarks feature, the back button
would work fine. Ignoring continuations, not sure about them.
Rambling a bit:
How about some sort of transformer that worked more like bookmarks.
For instance the links generated for each tab in a layout could be
something like layout?top=n, where top is the id of the layout. Except
it would work automatically.
(bear in mind with the following that I don't really know how the event
thing works:)
It seems that we start off with the coplet knowing the parameters it
needs to set, and the values for them. Then all that information gets
remembered server-side, and translated into something else (that is
only valid for that page). Then when the user clicks a link the
process is reversed, we find out what events we remembered earlier and
fire them.
So instead of:
[coplet]
set attributes/page to 1
|
v
[event]
remember that event-1 = set attibute/page of coplet to 1
|
v
[page]
link href=event-1
|
v
click -> look up events -> fire events
why can't we make it work like this:
[coplet]
set attributes/page to 1
|
v
[page]
link href=event?coplet.attributes.page=1
|
v
click -> create events -> fire events
I know one reason - the whole attributes map for the site is open to
abuse, other parameters could be set by appending the appropriate
parameter. But if that could be checked for on submit, the problem
goes away and the back button works again.
Jon
RE: CachingURICoplet and cl:links caching too aggressively - possible fix?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Hi Jon,
you're suggested solution would work. But this would require that
you always use your new transformer in every place and be careful
when generating links.
In general, if you're using the CachingURICoplet you shouldn't
use the action-counter at all.
I think more and more while the action counter was a good idea,
it's better to disable the action-counter and replace it by a
component that forces the browser to reload the page when
the back button is used.
WDYT?
Carsten
> -----Original Message-----
> From: Jon Evans [mailto:jon.evans@misgl.com]
> Sent: Friday, April 02, 2004 1:58 PM
> To: Apache Cocoon
> Subject: CachingURICoplet and cl:links caching too
> aggressively - possible fix?
>
> Hi,
>
> I have a few CachingURICoplets which use cl:links to set
> various values. The most common is a paging bar to page
> through data, similar to the Goooooooogle links at the bottom
> of the google results page.
> Each does something like:
>
> <cl:link class="page" path="attributes/page"
> value="{@id}">
> <xsl:value-of select="@id" />
> </cl:link>
>
> That's an extract from one of my xslts, transforming <block>
> elements created by the filter transformer.
>
> The problem is that once they are generated and cached, they
> only work once. This is because they get transformed to a
> link that looks like
> portal?cocoon-portal-action=1&cocoon-portal-event=0 and the
> cocoon-portal-action number only works for the page it's generated on.
>
> Now could someone please check my understanding of the way
> this works.
> The link as it is stated above works because when the
> CopletTransformer runs in the pipeline of the specific
> coplet, it knows the ID of the coplet so it can set up the
> events properly.
>
> How about a change: we (I :-)) create a new transformer which
> runs in the coplet pipeline instead of the CopletTransformer.
> It looks for cl:link elements which omit the
> coplet="CopletID" parameter, and adds the attribute, with the
> current coplet ID as the value. At that point, the output
> xml of that particular coplet is saved in the cache with the
> cl:link tags still in place and unconverted.
>
> Then we can run the CopletTransformer once in the final page
> pipeline, and it will convert all of the cl:link tags for all
> coplets in the page.
>
> Thougths?
>
> Jon
>