cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Mayrhuber <>
Subject Re: CachingURICoplet and cl:links caching too aggressively - possible fix?
Date Mon, 05 Jul 2004 15:45:16 GMT
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.
>  []
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 
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.

> Carsten

lg, Chris

View raw message