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
