cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Evans <jon.ev...@misgl.com>
Subject Re: CachingURICoplet and cl:links caching too aggressively - possible fix?
Date Fri, 02 Apr 2004 13:11:56 GMT
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


Mime
View raw message