You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by mfs <fa...@gmail.com> on 2008/01/29 23:36:51 UTC
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: HybridURLCodingStrategies vs others
Posted by Johan Compagner <jc...@gmail.com>.
because that link is by default not stateless
If you use stateless links then that should happen (a combination of
bookmarkable and instance)
And not all pages can be bookmarkable, they have to have a default or
pageparam constructor.
Hybrid is a very special one. That is not just a Bookmarkble url coding
strategy.
Its really a Redirect URL strategy
johan
On Feb 4, 2008 9:56 AM, mfs <fa...@gmail.com> wrote:
>
> Actually my last post was in context of BookmarkableURLCodingStrategy
> which
> doesnt preserve the url once any action on that page is called, my
> argument
> is why not, i mean if the pageid is there with those actions (i.e.
> links/button) why cant the same page be shown and offcourse on top of why
> cant the same bookmarkable url be preserved..
>
>
> Johan Compagner wrote:
> >
> > 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 <fa...@gmail.com> 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 <fa...@gmail.com> 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 <fa...@gmail.com> 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 <fa...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> > 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: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Resizable and reorderable grid components.
> >> >> > http://www.inmethod.com
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> 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: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> 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<http://nabble.com/>
> .
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: HybridURLCodingStrategies vs others
Posted by mfs <fa...@gmail.com>.
Actually my last post was in context of BookmarkableURLCodingStrategy which
doesnt preserve the url once any action on that page is called, my argument
is why not, i mean if the pageid is there with those actions (i.e.
links/button) why cant the same page be shown and offcourse on top of why
cant the same bookmarkable url be preserved..
Johan Compagner wrote:
>
> 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 <fa...@gmail.com> 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 <fa...@gmail.com> 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 <fa...@gmail.com> 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 <fa...@gmail.com> 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/>
>> .
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > 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/>
>> .
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Resizable and reorderable grid components.
>> >> > http://www.inmethod.com
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >> >
>> >>
>> >> --
>> >> 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/>
>> .
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > 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/>
>> .
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: HybridURLCodingStrategies vs others
Posted by Johan Compagner <jc...@gmail.com>.
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 <fa...@gmail.com> 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 <fa...@gmail.com> 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 <fa...@gmail.com> 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 <fa...@gmail.com> 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/>
> .
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> > --
> >> >> > 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/>
> .
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Resizable and reorderable grid components.
> >> > http://www.inmethod.com
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> 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/>
> .
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
> > --
> > 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/>
> .
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: HybridURLCodingStrategies vs others
Posted by mfs <fa...@gmail.com>.
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 <fa...@gmail.com> 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 <fa...@gmail.com> 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 <fa...@gmail.com> 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: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > 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: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Resizable and reorderable grid components.
>> > http://www.inmethod.com
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: HybridURLCodingStrategies vs others
Posted by Martijn Dashorst <ma...@gmail.com>.
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 <fa...@gmail.com> 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 <fa...@gmail.com> 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 <fa...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
> >
> > --
> > Resizable and reorderable grid components.
> > http://www.inmethod.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
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
Re: HybridURLCodingStrategies vs others
Posted by mfs <fa...@gmail.com>.
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 <fa...@gmail.com> 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 <fa...@gmail.com> 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: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> Resizable and reorderable grid components.
> http://www.inmethod.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: HybridURLCodingStrategies vs others
Posted by Matej Knopp <ma...@gmail.com>.
On Jan 30, 2008 1:36 AM, mfs <fa...@gmail.com> 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 <fa...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
> > --
> > 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Resizable and reorderable grid components.
http://www.inmethod.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: HybridURLCodingStrategies vs others
Posted by mfs <fa...@gmail.com>.
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 <fa...@gmail.com> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: HybridURLCodingStrategies vs others
Posted by Matej Knopp <ma...@gmail.com>.
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 <fa...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Resizable and reorderable grid components.
http://www.inmethod.com
Re: HybridURLCodingStrategies vs others
Posted by jpswain <jp...@gmail.com>.
mfs,
I'm not sure how it works, but the Wicket-based
http://papernapkin.org/pastebin/home Pastebin seems to handle URL Coding
perfectly clean, the way you describe. The source code is available
http://developer.berlios.de/projects/wicketpastebin/ here.
It would be sweet if a more experienced programmer than me could explain why
and how this works, and possibly document how exactly to replicate the way
these smart guys did it.
Jamie
--
View this message in context: http://www.nabble.com/HybridURLCodingStrategies-vs-others-tp15171137p15446236.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org