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
