RE: CachingURICoplet and cl:links caching too aggressively - possible fix?
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?
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?
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:[EMAIL PROTECTED] Sent: Monday, July 05, 2004 4:20 PM To: [EMAIL PROTECTED] 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?
Sorry for the delay, I overlooked this... Done. Carsten -Original Message- From: Jon Evans [mailto:[EMAIL PROTECTED] Sent: Monday, April 05, 2004 11:44 AM To: [EMAIL PROTECTED] 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?
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?
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?
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:[EMAIL PROTECTED] 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 Ggle links at the bottom of the google results page. Each does something like: cl:link class=page path=attributes/page value=[EMAIL PROTECTED] 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=1cocoon-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?
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?
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?
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?
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
