Re: DataView, OrderByBorder, CheckGroup
Hi, On Thu, Oct 16, 2014 at 3:38 AM, Colin Rogers colin.rog...@objectconsulting.com.au wrote: Martin, Thanks for the explanation... so - does Wicket not store, and therefore not handle, versions of pages with different renderCounts? Only page version (page id) is used for the storing. Render count is used only to check whether the rendered page in the browser is the same with the page with the same page id at the server. But above you listed only non-Ajax components. Doh! That is obvious now you mention it - thanks for the info :) Cheers, Col. -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Monday, 13 October 2014 6:01 PM To: users@wicket.apache.org Subject: Re: DataView, OrderByBorder, CheckGroup Hi, On Mon, Oct 13, 2014 at 2:59 AM, Colin Rogers colin.rog...@objectconsulting.com.au wrote: Wicketeers, I don't know if this is a bug, bad coding on my behalf or incompatible components or what not. It's only a minor thing, but I thought it worth raising (as usually, I end up learning something). I've created a quickstart, here; http://tenthart.com/wickettest2.zip The basic thing is that I have a DataView, with columns organised with an OrderByBorder component. Wrapping those, I have a CheckGroup. It's the CheckGroup that seems to trigger a weird behaviour in that the pageId doesn't increment when the OrderByBorder link is clicked. This has the knock on that StalePageException are raised (and handled) when going back through history or more often, when opening links in new window (click 'open in new window' and then click the link again the original window). The affects are minor - the page refreshing and the click being ignored, so nothing majorly important. When you copy the url from the address bar from one tab/window to another the page id stays the same but another special counter changes - Page#renderCount. When you load the page in the second tab/window the renderCount increments with 1. If you use non-Ajax components/behaviors to interact with the page it may increment even more. Later when you go back to the first tab/window and try to use any component (Ajax or not) Wicket will check whether the the renderCount in the request url (e.g. in '3-1-ILinkListener~some~component' '3' is the pageId and '1' is the renderCount) matches with the renderCount of the page with id 3 in the pages' store. If it doesn't then a special PageStaleException is being thrown and Wicket just renders the page with its latest state and respectively renderCount+1. This is needed to prevent using stale/obsolete version of the page. E.g. if in the second tab/window you remove a panel for some entity and this panel contains a child component a link to edit this entity then trying to click on this link in the first tab/window will end with ComponentNotFoundException if there was no such check. Also, as an aside, the Wicket Debug box seems to have disappeared. I haven't checked what is the reason for this to disappear. But above you listed only non-Ajax components. The Ajax debug window appears only if there is an Ajax behavior in the rendered page. Lately I don't see any usefulness in Ajax Debug Window. All the information is available in the browser's Dev tools. Anyway, has anyone got advice on this? Is it a bug? Cheers, Col. EMAIL DISCLAIMER This email message and its attachments are confidential and may also contain copyright or privileged material. If you are not the intended recipient, you may not forward the email or disclose or use the information contained in it. If you have received this email message in error, please advise the sender immediately by replying to this email and delete the message and any associated attachments. Any views, opinions, conclusions, advice or statements expressed in this email message are those of the individual sender and should not be relied upon as the considered view, opinion, conclusions, advice or statement of this company except where the sender expressly, and with authority, states them to be the considered view, opinion, conclusions, advice or statement of this company. Every care is taken but we recommend that you scan any attachments for viruses. EMAIL DISCLAIMER This email message and its attachments are confidential and may also contain copyright or privileged material. If you are not the intended recipient, you may not forward the email or disclose or use the information contained in it. If you have received this email message in error, please advise the sender immediately by replying to this email and delete the message and any associated attachments. Any views, opinions, conclusions, advice or statements expressed in this email message are those of the individual sender and should not be relied upon as the considered view, opinion, conclusions, advice or statement of this company except
RE: DataView, OrderByBorder, CheckGroup
Martin, Thanks for the explanation... so - does Wicket not store, and therefore not handle, versions of pages with different renderCounts? But above you listed only non-Ajax components. Doh! That is obvious now you mention it - thanks for the info :) Cheers, Col. -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Monday, 13 October 2014 6:01 PM To: users@wicket.apache.org Subject: Re: DataView, OrderByBorder, CheckGroup Hi, On Mon, Oct 13, 2014 at 2:59 AM, Colin Rogers colin.rog...@objectconsulting.com.au wrote: Wicketeers, I don't know if this is a bug, bad coding on my behalf or incompatible components or what not. It's only a minor thing, but I thought it worth raising (as usually, I end up learning something). I've created a quickstart, here; http://tenthart.com/wickettest2.zip The basic thing is that I have a DataView, with columns organised with an OrderByBorder component. Wrapping those, I have a CheckGroup. It's the CheckGroup that seems to trigger a weird behaviour in that the pageId doesn't increment when the OrderByBorder link is clicked. This has the knock on that StalePageException are raised (and handled) when going back through history or more often, when opening links in new window (click 'open in new window' and then click the link again the original window). The affects are minor - the page refreshing and the click being ignored, so nothing majorly important. When you copy the url from the address bar from one tab/window to another the page id stays the same but another special counter changes - Page#renderCount. When you load the page in the second tab/window the renderCount increments with 1. If you use non-Ajax components/behaviors to interact with the page it may increment even more. Later when you go back to the first tab/window and try to use any component (Ajax or not) Wicket will check whether the the renderCount in the request url (e.g. in '3-1-ILinkListener~some~component' '3' is the pageId and '1' is the renderCount) matches with the renderCount of the page with id 3 in the pages' store. If it doesn't then a special PageStaleException is being thrown and Wicket just renders the page with its latest state and respectively renderCount+1. This is needed to prevent using stale/obsolete version of the page. E.g. if in the second tab/window you remove a panel for some entity and this panel contains a child component a link to edit this entity then trying to click on this link in the first tab/window will end with ComponentNotFoundException if there was no such check. Also, as an aside, the Wicket Debug box seems to have disappeared. I haven't checked what is the reason for this to disappear. But above you listed only non-Ajax components. The Ajax debug window appears only if there is an Ajax behavior in the rendered page. Lately I don't see any usefulness in Ajax Debug Window. All the information is available in the browser's Dev tools. Anyway, has anyone got advice on this? Is it a bug? Cheers, Col. EMAIL DISCLAIMER This email message and its attachments are confidential and may also contain copyright or privileged material. If you are not the intended recipient, you may not forward the email or disclose or use the information contained in it. If you have received this email message in error, please advise the sender immediately by replying to this email and delete the message and any associated attachments. Any views, opinions, conclusions, advice or statements expressed in this email message are those of the individual sender and should not be relied upon as the considered view, opinion, conclusions, advice or statement of this company except where the sender expressly, and with authority, states them to be the considered view, opinion, conclusions, advice or statement of this company. Every care is taken but we recommend that you scan any attachments for viruses. EMAIL DISCLAIMER This email message and its attachments are confidential and may also contain copyright or privileged material. If you are not the intended recipient, you may not forward the email or disclose or use the information contained in it. If you have received this email message in error, please advise the sender immediately by replying to this email and delete the message and any associated attachments. Any views, opinions, conclusions, advice or statements expressed in this email message are those of the individual sender and should not be relied upon as the considered view, opinion, conclusions, advice or statement of this company except where the sender expressly, and with authority, states them to be the considered view, opinion, conclusions, advice or statement of this company. Every care is taken but we recommend that you scan any attachments for viruses.
Re: DataView, OrderByBorder, CheckGroup
Hi, On Mon, Oct 13, 2014 at 2:59 AM, Colin Rogers colin.rog...@objectconsulting.com.au wrote: Wicketeers, I don't know if this is a bug, bad coding on my behalf or incompatible components or what not. It's only a minor thing, but I thought it worth raising (as usually, I end up learning something). I've created a quickstart, here; http://tenthart.com/wickettest2.zip The basic thing is that I have a DataView, with columns organised with an OrderByBorder component. Wrapping those, I have a CheckGroup. It's the CheckGroup that seems to trigger a weird behaviour in that the pageId doesn't increment when the OrderByBorder link is clicked. This has the knock on that StalePageException are raised (and handled) when going back through history or more often, when opening links in new window (click 'open in new window' and then click the link again the original window). The affects are minor - the page refreshing and the click being ignored, so nothing majorly important. When you copy the url from the address bar from one tab/window to another the page id stays the same but another special counter changes - Page#renderCount. When you load the page in the second tab/window the renderCount increments with 1. If you use non-Ajax components/behaviors to interact with the page it may increment even more. Later when you go back to the first tab/window and try to use any component (Ajax or not) Wicket will check whether the the renderCount in the request url (e.g. in '3-1-ILinkListener~some~component' '3' is the pageId and '1' is the renderCount) matches with the renderCount of the page with id 3 in the pages' store. If it doesn't then a special PageStaleException is being thrown and Wicket just renders the page with its latest state and respectively renderCount+1. This is needed to prevent using stale/obsolete version of the page. E.g. if in the second tab/window you remove a panel for some entity and this panel contains a child component a link to edit this entity then trying to click on this link in the first tab/window will end with ComponentNotFoundException if there was no such check. Also, as an aside, the Wicket Debug box seems to have disappeared. I haven't checked what is the reason for this to disappear. But above you listed only non-Ajax components. The Ajax debug window appears only if there is an Ajax behavior in the rendered page. Lately I don't see any usefulness in Ajax Debug Window. All the information is available in the browser's Dev tools. Anyway, has anyone got advice on this? Is it a bug? Cheers, Col. EMAIL DISCLAIMER This email message and its attachments are confidential and may also contain copyright or privileged material. If you are not the intended recipient, you may not forward the email or disclose or use the information contained in it. If you have received this email message in error, please advise the sender immediately by replying to this email and delete the message and any associated attachments. Any views, opinions, conclusions, advice or statements expressed in this email message are those of the individual sender and should not be relied upon as the considered view, opinion, conclusions, advice or statement of this company except where the sender expressly, and with authority, states them to be the considered view, opinion, conclusions, advice or statement of this company. Every care is taken but we recommend that you scan any attachments for viruses.
