Re: HybridURLCodingStrategies vs others
AND IF NOT how does it work for them...cant it work in a similar way for HUCS where we dont have those numbers in the url... Thanks in advance -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15171137.html Sent from the Wicket - User mailing list archive at Nabble.comhttp://nabble.com/ . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Resizable and reorderable grid components. http://www.inmethod.com -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15173060.html Sent from the Wicket - User mailing list archive at Nabble.comhttp://nabble.com/ . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Resizable and reorderable grid components. http://www.inmethod.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15214950.html Sent from the Wicket - User mailing list archive at Nabble.comhttp://nabble.com/ . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15263709.html Sent from the Wicket - User mailing list archive at Nabble.comhttp://nabble.com/ . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15264096.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HybridURLCodingStrategies vs others
i am not sure what you are trying to say but it looks like you are exactly describing how wicket already works from day 1. The pageid in normal links are ofcourse used to lookup the page and call the listener and if you don't set a different response page that page is used also for rendering. johan On Feb 4, 2008 9:21 AM, mfs [EMAIL PROTECTED] wrote: Your point certainly makes sense for ajax based behavior (where one would loose the state) BUT lets say a a page just has normal links/button (which would have pageIds encoded in them) why cant in that case (i.e. on invocation of listeners on button/link click)...the response be redirected to the page associated with pageId which is part of links/buttons url.. Martijn Dashorst wrote: If you use ajax components to update page state, this will not modify the URL in the BUCS strategy. Refresh or go back to that URL and you loose your state because the URL invokes a bookmarkable page request. Martijn On 1/31/08, mfs [EMAIL PROTECTED] wrote: Thanks for the follow up Matej, it does clarify certain things..but commenting on your last point, as you said earlier..the links/buttons (bind to any event) have the pageId in them irrespective of whether the page is loaded through BUCS or HUCS, so even in case of BUCS we still would have the pageId on an event-invocation, so why cant the page (in session be retrieved based on the pageId with those links) and be forward to.. Matej Knopp-2 wrote: On Jan 30, 2008 1:36 AM, mfs [EMAIL PROTECTED] wrote: When u say it attempts to reuse existing page instance (when pageid in session matches the class specified by mount point). - you mean the pageid in the URL (and not session) matches the class specified by the mount path ? No. The pageId in url is of course used to retrieve page instance from session which is then tested to match the mount point. - So other strategies are there to provide relatively clean-er url ? (i.e. without pageId and version info) what other reasons would be there to use the non-HUCS, i wonder what happens to existing the page instances ? Nothing new page instance is created, that doesn't affect the old page instances at all. - Creating a new page-instance for every call, doesnt that break the back button support ? arent we compromising the wicket functionality of maintaining page-history by creating a new page instance every time and not using the existing ones ? What do you mean by every call? New page instance is created on every request with regular bookmarkable URL. That doesn't affect back button at all becaue all page instance relative urls (listener interface, e.g. clicking a link on page) are not bookmarkable and contain the page instance id. Only when you refresh the page (while still having the bookmarkable url in url bar) new page instance is created. - Last but not the least when i read that all other strategies other than HUCS doesnt preserve the mount path after a listener is invoked on that page sounded like a bug to me, i mean why cant the mount path be preserved using the same strategy ?, with that a person is bound to use HUCS although he prefers to keep to BookMarkableUCS since its more clean in terms of displayed url. That's the point. The regular URL conding strategies don't insert page instance in URL. So after clicking a link there is no way to redirect to bookmarkable URL while still displaying the same page. That's the whole reason for hybridurlcodingstrategy. -Matej Matej Knopp-2 wrote: Hi, the other strategies always create new page instance. The difference with hybridurlcodingstrategy is that it attempts to reuse existing page instance (when pageid in session matches the class specified by mount point). -Matej On Jan 29, 2008 11:36 PM, mfs [EMAIL PROTECTED] wrote: Guys, I believe its just the HybridURLCodingStrategy and its subclasses (IndexHUCS) which encodes the mount point, page parameters and page instance information into the URL whereas others strategies DO have the mount-point page-param in them (encoded in a different way) BUT the page-instance info (i.e. page-id/version) is not contained in the URL. I wonder why is this page-info not required by other strategies, wouldnt it be need to locate the older pages AND IF NOT how does it work for them...cant it work in a similar way for HUCS where we dont have those numbers in the url... Thanks in advance -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15171137.html Sent from the Wicket - User mailing list archive at Nabble.comhttp://nabble.com
Re: HybridURLCodingStrategies vs others
, mfs [EMAIL PROTECTED] wrote: Guys, I believe its just the HybridURLCodingStrategy and its subclasses (IndexHUCS) which encodes the mount point, page parameters and page instance information into the URL whereas others strategies DO have the mount-point page-param in them (encoded in a different way) BUT the page-instance info (i.e. page-id/version) is not contained in the URL. I wonder why is this page-info not required by other strategies, wouldnt it be need to locate the older pages AND IF NOT how does it work for them...cant it work in a similar way for HUCS where we dont have those numbers in the url... Thanks in advance -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15171137.html Sent from the Wicket - User mailing list archive at Nabble.com http://nabble.com/http://nabble.com/ . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Resizable and reorderable grid components. http://www.inmethod.com -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15173060.html Sent from the Wicket - User mailing list archive at Nabble.com http://nabble.com/http://nabble.com/ . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Resizable and reorderable grid components. http://www.inmethod.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15214950.html Sent from the Wicket - User mailing list archive at Nabble.com http://nabble.com/http://nabble.com/ . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15263709.html Sent from the Wicket - User mailing list archive at Nabble.com http://nabble.com/http://nabble.com/ . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15264096.html Sent from the Wicket - User mailing list archive at Nabble.comhttp://nabble.com/ . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HybridURLCodingStrategies vs others
Thanks for the follow up Matej, it does clarify certain things..but commenting on your last point, as you said earlier..the links/buttons (bind to any event) have the pageId in them irrespective of whether the page is loaded through BUCS or HUCS, so even in case of BUCS we still would have the pageId on an event-invocation, so why cant the page (in session be retrieved based on the pageId with those links) and be forward to.. Matej Knopp-2 wrote: On Jan 30, 2008 1:36 AM, mfs [EMAIL PROTECTED] wrote: When u say it attempts to reuse existing page instance (when pageid in session matches the class specified by mount point). - you mean the pageid in the URL (and not session) matches the class specified by the mount path ? No. The pageId in url is of course used to retrieve page instance from session which is then tested to match the mount point. - So other strategies are there to provide relatively clean-er url ? (i.e. without pageId and version info) what other reasons would be there to use the non-HUCS, i wonder what happens to existing the page instances ? Nothing new page instance is created, that doesn't affect the old page instances at all. - Creating a new page-instance for every call, doesnt that break the back button support ? arent we compromising the wicket functionality of maintaining page-history by creating a new page instance every time and not using the existing ones ? What do you mean by every call? New page instance is created on every request with regular bookmarkable URL. That doesn't affect back button at all becaue all page instance relative urls (listener interface, e.g. clicking a link on page) are not bookmarkable and contain the page instance id. Only when you refresh the page (while still having the bookmarkable url in url bar) new page instance is created. - Last but not the least when i read that all other strategies other than HUCS doesnt preserve the mount path after a listener is invoked on that page sounded like a bug to me, i mean why cant the mount path be preserved using the same strategy ?, with that a person is bound to use HUCS although he prefers to keep to BookMarkableUCS since its more clean in terms of displayed url. That's the point. The regular URL conding strategies don't insert page instance in URL. So after clicking a link there is no way to redirect to bookmarkable URL while still displaying the same page. That's the whole reason for hybridurlcodingstrategy. -Matej Matej Knopp-2 wrote: Hi, the other strategies always create new page instance. The difference with hybridurlcodingstrategy is that it attempts to reuse existing page instance (when pageid in session matches the class specified by mount point). -Matej On Jan 29, 2008 11:36 PM, mfs [EMAIL PROTECTED] wrote: Guys, I believe its just the HybridURLCodingStrategy and its subclasses (IndexHUCS) which encodes the mount point, page parameters and page instance information into the URL whereas others strategies DO have the mount-point page-param in them (encoded in a different way) BUT the page-instance info (i.e. page-id/version) is not contained in the URL. I wonder why is this page-info not required by other strategies, wouldnt it be need to locate the older pages AND IF NOT how does it work for them...cant it work in a similar way for HUCS where we dont have those numbers in the url... Thanks in advance -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15171137.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Resizable and reorderable grid components. http://www.inmethod.com -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15173060.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Resizable and reorderable grid components. http://www.inmethod.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15214950.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HybridURLCodingStrategies vs others
Guys, I believe its just the HybridURLCodingStrategy and its subclasses (IndexHUCS) which encodes the mount point, page parameters and page instance information into the URL whereas others strategies DO have the mount-point page-param in them (encoded in a different way) BUT the page-instance info (i.e. page-id/version) is not contained in the URL. I wonder why is this page-info not required by other strategies, wouldnt it be need to locate the older pages AND IF NOT how does it work for them...cant it work in a similar way for HUCS where we dont have those numbers in the url... Thanks in advance -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15171137.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HybridURLCodingStrategies vs others
Hi, the other strategies always create new page instance. The difference with hybridurlcodingstrategy is that it attempts to reuse existing page instance (when pageid in session matches the class specified by mount point). -Matej On Jan 29, 2008 11:36 PM, mfs [EMAIL PROTECTED] wrote: Guys, I believe its just the HybridURLCodingStrategy and its subclasses (IndexHUCS) which encodes the mount point, page parameters and page instance information into the URL whereas others strategies DO have the mount-point page-param in them (encoded in a different way) BUT the page-instance info (i.e. page-id/version) is not contained in the URL. I wonder why is this page-info not required by other strategies, wouldnt it be need to locate the older pages AND IF NOT how does it work for them...cant it work in a similar way for HUCS where we dont have those numbers in the url... Thanks in advance -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15171137.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Resizable and reorderable grid components. http://www.inmethod.com
Re: HybridURLCodingStrategies vs others
On Jan 30, 2008 1:36 AM, mfs [EMAIL PROTECTED] wrote: When u say it attempts to reuse existing page instance (when pageid in session matches the class specified by mount point). - you mean the pageid in the URL (and not session) matches the class specified by the mount path ? No. The pageId in url is of course used to retrieve page instance from session which is then tested to match the mount point. - So other strategies are there to provide relatively clean-er url ? (i.e. without pageId and version info) what other reasons would be there to use the non-HUCS, i wonder what happens to existing the page instances ? Nothing new page instance is created, that doesn't affect the old page instances at all. - Creating a new page-instance for every call, doesnt that break the back button support ? arent we compromising the wicket functionality of maintaining page-history by creating a new page instance every time and not using the existing ones ? What do you mean by every call? New page instance is created on every request with regular bookmarkable URL. That doesn't affect back button at all becaue all page instance relative urls (listener interface, e.g. clicking a link on page) are not bookmarkable and contain the page instance id. Only when you refresh the page (while still having the bookmarkable url in url bar) new page instance is created. - Last but not the least when i read that all other strategies other than HUCS doesnt preserve the mount path after a listener is invoked on that page sounded like a bug to me, i mean why cant the mount path be preserved using the same strategy ?, with that a person is bound to use HUCS although he prefers to keep to BookMarkableUCS since its more clean in terms of displayed url. That's the point. The regular URL conding strategies don't insert page instance in URL. So after clicking a link there is no way to redirect to bookmarkable URL while still displaying the same page. That's the whole reason for hybridurlcodingstrategy. -Matej Matej Knopp-2 wrote: Hi, the other strategies always create new page instance. The difference with hybridurlcodingstrategy is that it attempts to reuse existing page instance (when pageid in session matches the class specified by mount point). -Matej On Jan 29, 2008 11:36 PM, mfs [EMAIL PROTECTED] wrote: Guys, I believe its just the HybridURLCodingStrategy and its subclasses (IndexHUCS) which encodes the mount point, page parameters and page instance information into the URL whereas others strategies DO have the mount-point page-param in them (encoded in a different way) BUT the page-instance info (i.e. page-id/version) is not contained in the URL. I wonder why is this page-info not required by other strategies, wouldnt it be need to locate the older pages AND IF NOT how does it work for them...cant it work in a similar way for HUCS where we dont have those numbers in the url... Thanks in advance -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15171137.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Resizable and reorderable grid components. http://www.inmethod.com -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15173060.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Resizable and reorderable grid components. http://www.inmethod.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HybridURLCodingStrategies vs others
When u say it attempts to reuse existing page instance (when pageid in session matches the class specified by mount point). - you mean the pageid in the URL (and not session) matches the class specified by the mount path ? - So other strategies are there to provide relatively clean-er url ? (i.e. without pageId and version info) what other reasons would be there to use the non-HUCS, i wonder what happens to existing the page instances ? - Creating a new page-instance for every call, doesnt that break the back button support ? arent we compromising the wicket functionality of maintaining page-history by creating a new page instance every time and not using the existing ones ? - Last but not the least when i read that all other strategies other than HUCS doesnt preserve the mount path after a listener is invoked on that page sounded like a bug to me, i mean why cant the mount path be preserved using the same strategy ?, with that a person is bound to use HUCS although he prefers to keep to BookMarkableUCS since its more clean in terms of displayed url. Matej Knopp-2 wrote: Hi, the other strategies always create new page instance. The difference with hybridurlcodingstrategy is that it attempts to reuse existing page instance (when pageid in session matches the class specified by mount point). -Matej On Jan 29, 2008 11:36 PM, mfs [EMAIL PROTECTED] wrote: Guys, I believe its just the HybridURLCodingStrategy and its subclasses (IndexHUCS) which encodes the mount point, page parameters and page instance information into the URL whereas others strategies DO have the mount-point page-param in them (encoded in a different way) BUT the page-instance info (i.e. page-id/version) is not contained in the URL. I wonder why is this page-info not required by other strategies, wouldnt it be need to locate the older pages AND IF NOT how does it work for them...cant it work in a similar way for HUCS where we dont have those numbers in the url... Thanks in advance -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15171137.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Resizable and reorderable grid components. http://www.inmethod.com -- View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15173060.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
