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.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] >> >> > > > -- > 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
