RE: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
> Also there is a complete rewrite of URL handling planned for 1.5 which > will allow much better control over URL generation and bookmarkability > in Wicket. Well, in that case, I won't press this any more. The current stuff is great, but there is indeed a lot of room for improvement. Will be looking forward to that. :-) In the meantime, I'll just use my own patched version. Thanks for checking this out. -dml- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
I'm not very eager about this. The interface listeners URLs are quite long, why making them even longer while bringing no additional benefit? Also are you sure thath your patch won't break under any circumstances relative urls? It took us a while to get relative URLs working reliably, I wouldn't want to see that break just for the sake of adding mount point to listener interface urls. Also there is a complete rewrite of URL handling planned for 1.5 which will allow much better control over URL generation and bookmarkability in Wicket. -Matej On Wed, Jul 2, 2008 at 4:21 PM, Peter Ertl <[EMAIL PROTECTED]> wrote: > However this will not be true if you change the render strategy *imho* > > > getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.ONE_PASS_RENDER) > > +1 for applying the patch as it's not only a matter of correctness but also > of taste > > > Am 02.07.2008 um 16:06 schrieb Johan Compagner: > >> what does it matter how the urls that are inside the html look like? >> Its all about how the urls look like in the browsers url bar right? >> >> On Wed, Jul 2, 2008 at 6:59 AM, David Leangen <[EMAIL PROTECTED]> wrote: >> once again, i dont see what this offers over the hybrid strategy. >>> >>> Maybe you can correct me if I'm wrong here... >>> >>> The hybrid stategy is only applied when the target is an >>> IBookmarkablePageRequestTarget. So, for normal bookmarkable pages, there >>> is no problem, like you say. >>> >>> The issue only arises when a page is mounted, but is used in a stateful >>> way (for example it has a form or something). In that case, the target >>> becomes an IListenerInterfaceRequestTarget. When this is the case, the >>> hybrid strategy is not used. This is the case that the patch is intended >>> for. >>> >>> >>> -dml- >>> >>> >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
However this will not be true if you change the render strategy *imho* getRequestCycleSettings ().setRenderStrategy(IRequestCycleSettings.ONE_PASS_RENDER) +1 for applying the patch as it's not only a matter of correctness but also of taste Am 02.07.2008 um 16:06 schrieb Johan Compagner: what does it matter how the urls that are inside the html look like? Its all about how the urls look like in the browsers url bar right? On Wed, Jul 2, 2008 at 6:59 AM, David Leangen <[EMAIL PROTECTED]> wrote: once again, i dont see what this offers over the hybrid strategy. Maybe you can correct me if I'm wrong here... The hybrid stategy is only applied when the target is an IBookmarkablePageRequestTarget. So, for normal bookmarkable pages, there is no problem, like you say. The issue only arises when a page is mounted, but is used in a stateful way (for example it has a form or something). In that case, the target becomes an IListenerInterfaceRequestTarget. When this is the case, the hybrid strategy is not used. This is the case that the patch is intended for. -dml- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
what does it matter how the urls that are inside the html look like? Its all about how the urls look like in the browsers url bar right? On Wed, Jul 2, 2008 at 6:59 AM, David Leangen <[EMAIL PROTECTED]> wrote: > > once again, i dont see what this offers over the hybrid strategy. > > Maybe you can correct me if I'm wrong here... > > The hybrid stategy is only applied when the target is an > IBookmarkablePageRequestTarget. So, for normal bookmarkable pages, there > is no problem, like you say. > > The issue only arises when a page is mounted, but is used in a stateful > way (for example it has a form or something). In that case, the target > becomes an IListenerInterfaceRequestTarget. When this is the case, the > hybrid strategy is not used. This is the case that the patch is intended > for. > > > -dml- > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
Indeed. I would very welcome this capability. Regards, Erik. David Leangen wrote: once again, i dont see what this offers over the hybrid strategy. Maybe you can correct me if I'm wrong here... The hybrid stategy is only applied when the target is an IBookmarkablePageRequestTarget. So, for normal bookmarkable pages, there is no problem, like you say. The issue only arises when a page is mounted, but is used in a stateful way (for example it has a form or something). In that case, the target becomes an IListenerInterfaceRequestTarget. When this is the case, the hybrid strategy is not used. This is the case that the patch is intended for. -dml- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
> once again, i dont see what this offers over the hybrid strategy. Maybe you can correct me if I'm wrong here... The hybrid stategy is only applied when the target is an IBookmarkablePageRequestTarget. So, for normal bookmarkable pages, there is no problem, like you say. The issue only arises when a page is mounted, but is used in a stateful way (for example it has a form or something). In that case, the target becomes an IListenerInterfaceRequestTarget. When this is the case, the hybrid strategy is not used. This is the case that the patch is intended for. -dml- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
not unless you are planning on keeping any existing query params in the url for the duration of the entire session, a lot of bookmarkable pages need context. once again, i dont see what this offers over the hybrid strategy. -igor On Tue, Jul 1, 2008 at 7:05 PM, Ned Collyer <[EMAIL PROTECTED]> wrote: > > A possible added bonus to this that it *might* be possible to catch a session > expired, and re-login to the bookmarkable page. > -- > View this message in context: > http://www.nabble.com/-PROPOSAL--Use-path-in-URL-when-target-is-instance-of-BookmarkablePageRequestTarget-tp18188845p18228914.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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
A possible added bonus to this that it *might* be possible to catch a session expired, and re-login to the bookmarkable page. -- View this message in context: http://www.nabble.com/-PROPOSAL--Use-path-in-URL-when-target-is-instance-of-BookmarkablePageRequestTarget-tp18188845p18228914.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: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
> >> I think stateless pages already do something like that. Also look at > >> hybrid url encoding that also preserves the bookmarkable url and makes > >> the url even prettier. > > > > That's possible. I haven't yet made my way into 1.4 waters yet. > > > none of this is 1.4 In any case, even if this exists for stateless pages, seems to me that this better expresses the intent. :-) Haven't checked out hybrid encoding yet, but in the case of IListenerInterfaceRequestTarget, IIRC the bookmarkable encoder is completely bypassed, so if the hybrid encoder is used the same as the other bookmarkable encoders, this won't change anything. -dml- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
none of this is 1.4 -igor On Mon, Jun 30, 2008 at 11:50 PM, David Leangen <[EMAIL PROTECTED]> wrote: > > On Tue, 2008-07-01 at 08:48 +0200, Johan Compagner wrote: >> I think stateless pages already do something like that. Also look at >> hybrid url encoding that also preserves the bookmarkable url and makes >> the url even prettier. > > That's possible. I haven't yet made my way into 1.4 waters yet. > > -dml- > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
On Tue, 2008-07-01 at 08:48 +0200, Johan Compagner wrote: > I think stateless pages already do something like that. Also look at > hybrid url encoding that also preserves the bookmarkable url and makes > the url even prettier. That's possible. I haven't yet made my way into 1.4 waters yet. -dml- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
I think stateless pages already do something like that. Also look at hybrid url encoding that also preserves the bookmarkable url and makes the url even prettier. On 6/30/08, David Leangen <[EMAIL PROTECTED]> wrote: > > Currently, when a target is an instance of > IListenerInterfaceRequestTarget, the URL gets "mounted" (so to speak) on > the root of where the wicket application is located. > > So, if the servlet context path for the wicket application is set > to /home/, then all targets (whether bookmarkable or not), are written > as something like /home/?wicket:interface=:0. > > This works, but I think it somewhat defeats the purpose of having > mounted pages. > > Rather, I think it would be better that when the target is an instance > of BookmarkablePageRequestTarget, since we can get the target path > easily, we should therefore write the URL to that target path, and not > the application's root path. > > So, if I have a form on a page mounted at /home/myform, the above link > gets rendered as /home/myform/?wicket:interface=:0 instead. > > > Now, I perfectly understand that this type page has state, so is no > longer bookmarkable. However, at least we can preserve the "pretty URL" > aspect of the page, which IMO is the original intent. > > [On that topic, I notice that people often confuse the two > related-but-different topics of "pretty urls" and "bookmarkable pages". > I wonder if there isn't a better way of formalising the two concepts so > people get less confused... no ideas, just thinking out loud.] > > > Anyway, I tried this out by modifying WebRequestCodingStrategy. The fix > is quite simple and it appears to work without any problems. > > > If you think this is a reasonable proposal, I will create an issue and > submit my patch. > > > Thank you! > David > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
Just make sure you create a patch over the last version in trunk. Then send the diff file. :-) Good luck! -- Bruno Borges blog.brunoborges.com.br +55 21 76727099 "The glory of great men should always be measured by the means they have used to acquire it." - Francois de La Rochefoucauld On Mon, Jun 30, 2008 at 9:35 PM, David Leangen <[EMAIL PROTECTED]> wrote: > > > A good patch attached to an issue is always the best way to convince > others :-) > > Is there a formatting spec somewhere that I can use? > > Every time I try to create a patch, a lot of stuff in the file gets > reformatted, so it's hard to see the relevant parts of the patch. > > -dml- > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
> A good patch attached to an issue is always the best way to convince others > :-) Is there a formatting spec somewhere that I can use? Every time I try to create a patch, a lot of stuff in the file gets reformatted, so it's hard to see the relevant parts of the patch. -dml- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
not sure this will work for security since the mount is kept in the url until another bookmarkable url is visited. which means that you can get to any page from that particular mount as long as you use statefull links... -igor On Mon, Jun 30, 2008 at 7:28 AM, Peter Ertl <[EMAIL PROTECTED]> wrote: > +1 -- sounds reasonable, doesn't break anything (hopefully :-), easier > path-based security on apache front end proxy, > > Good work, David :-) > > > > Am 30.06.2008 um 07:33 schrieb David Leangen: > >> >>> Wouldn't this be useless except from the fact of been "pretty" ? >> >> Yes, it would indeed be "useless" in that functionally, it contributes >> nothing. It also takes nothing away. So by definition I guess that's a >> refactoring. >> >> The purpose of this refactoring, just like any other for that matter, is >> to better communicate intent. >> >> >> Cheers, >> David >> >> >> >>> On Mon, Jun 30, 2008 at 2:12 AM, David Leangen <[EMAIL PROTECTED]> >>> wrote: >>> Currently, when a target is an instance of IListenerInterfaceRequestTarget, the URL gets "mounted" (so to speak) on the root of where the wicket application is located. So, if the servlet context path for the wicket application is set to /home/, then all targets (whether bookmarkable or not), are written as something like /home/?wicket:interface=:0. This works, but I think it somewhat defeats the purpose of having mounted pages. Rather, I think it would be better that when the target is an instance of BookmarkablePageRequestTarget, since we can get the target path easily, we should therefore write the URL to that target path, and not the application's root path. So, if I have a form on a page mounted at /home/myform, the above link gets rendered as /home/myform/?wicket:interface=:0 instead. Now, I perfectly understand that this type page has state, so is no longer bookmarkable. However, at least we can preserve the "pretty URL" aspect of the page, which IMO is the original intent. [On that topic, I notice that people often confuse the two related-but-different topics of "pretty urls" and "bookmarkable pages". I wonder if there isn't a better way of formalising the two concepts so people get less confused... no ideas, just thinking out loud.] Anyway, I tried this out by modifying WebRequestCodingStrategy. The fix is quite simple and it appears to work without any problems. If you think this is a reasonable proposal, I will create an issue and submit my patch. Thank you! David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
> If you think this is a reasonable proposal, I will create an issue and > submit my patch. A good patch attached to an issue is always the best way to convince others :-) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
+1 -- sounds reasonable, doesn't break anything (hopefully :-), easier path-based security on apache front end proxy, Good work, David :-) Am 30.06.2008 um 07:33 schrieb David Leangen: Wouldn't this be useless except from the fact of been "pretty" ? Yes, it would indeed be "useless" in that functionally, it contributes nothing. It also takes nothing away. So by definition I guess that's a refactoring. The purpose of this refactoring, just like any other for that matter, is to better communicate intent. Cheers, David On Mon, Jun 30, 2008 at 2:12 AM, David Leangen <[EMAIL PROTECTED]> wrote: Currently, when a target is an instance of IListenerInterfaceRequestTarget, the URL gets "mounted" (so to speak) on the root of where the wicket application is located. So, if the servlet context path for the wicket application is set to /home/, then all targets (whether bookmarkable or not), are written as something like /home/?wicket:interface=:0. This works, but I think it somewhat defeats the purpose of having mounted pages. Rather, I think it would be better that when the target is an instance of BookmarkablePageRequestTarget, since we can get the target path easily, we should therefore write the URL to that target path, and not the application's root path. So, if I have a form on a page mounted at /home/myform, the above link gets rendered as /home/myform/?wicket:interface=:0 instead. Now, I perfectly understand that this type page has state, so is no longer bookmarkable. However, at least we can preserve the "pretty URL" aspect of the page, which IMO is the original intent. [On that topic, I notice that people often confuse the two related-but-different topics of "pretty urls" and "bookmarkable pages". I wonder if there isn't a better way of formalising the two concepts so people get less confused... no ideas, just thinking out loud.] Anyway, I tried this out by modifying WebRequestCodingStrategy. The fix is quite simple and it appears to work without any problems. If you think this is a reasonable proposal, I will create an issue and submit my patch. Thank you! David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
> Wouldn't this be useless except from the fact of been "pretty" ? Yes, it would indeed be "useless" in that functionally, it contributes nothing. It also takes nothing away. So by definition I guess that's a refactoring. The purpose of this refactoring, just like any other for that matter, is to better communicate intent. Cheers, David > On Mon, Jun 30, 2008 at 2:12 AM, David Leangen <[EMAIL PROTECTED]> wrote: > > > > > Currently, when a target is an instance of > > IListenerInterfaceRequestTarget, the URL gets "mounted" (so to speak) on > > the root of where the wicket application is located. > > > > So, if the servlet context path for the wicket application is set > > to /home/, then all targets (whether bookmarkable or not), are written > > as something like /home/?wicket:interface=:0. > > > > This works, but I think it somewhat defeats the purpose of having > > mounted pages. > > > > Rather, I think it would be better that when the target is an instance > > of BookmarkablePageRequestTarget, since we can get the target path > > easily, we should therefore write the URL to that target path, and not > > the application's root path. > > > > So, if I have a form on a page mounted at /home/myform, the above link > > gets rendered as /home/myform/?wicket:interface=:0 instead. > > > > > > Now, I perfectly understand that this type page has state, so is no > > longer bookmarkable. However, at least we can preserve the "pretty URL" > > aspect of the page, which IMO is the original intent. > > > > [On that topic, I notice that people often confuse the two > > related-but-different topics of "pretty urls" and "bookmarkable pages". > > I wonder if there isn't a better way of formalising the two concepts so > > people get less confused... no ideas, just thinking out loud.] > > > > > > Anyway, I tried this out by modifying WebRequestCodingStrategy. The fix > > is quite simple and it appears to work without any problems. > > > > > > If you think this is a reasonable proposal, I will create an issue and > > submit my patch. > > > > > > Thank you! > > David > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
Wouldn't this be useless except from the fact of been "pretty" ? Bruno Borges blog.brunoborges.com.br +55 21 76727099 "The glory of great men should always be measured by the means they have used to acquire it." - Francois de La Rochefoucauld On Mon, Jun 30, 2008 at 2:12 AM, David Leangen <[EMAIL PROTECTED]> wrote: > > Currently, when a target is an instance of > IListenerInterfaceRequestTarget, the URL gets "mounted" (so to speak) on > the root of where the wicket application is located. > > So, if the servlet context path for the wicket application is set > to /home/, then all targets (whether bookmarkable or not), are written > as something like /home/?wicket:interface=:0. > > This works, but I think it somewhat defeats the purpose of having > mounted pages. > > Rather, I think it would be better that when the target is an instance > of BookmarkablePageRequestTarget, since we can get the target path > easily, we should therefore write the URL to that target path, and not > the application's root path. > > So, if I have a form on a page mounted at /home/myform, the above link > gets rendered as /home/myform/?wicket:interface=:0 instead. > > > Now, I perfectly understand that this type page has state, so is no > longer bookmarkable. However, at least we can preserve the "pretty URL" > aspect of the page, which IMO is the original intent. > > [On that topic, I notice that people often confuse the two > related-but-different topics of "pretty urls" and "bookmarkable pages". > I wonder if there isn't a better way of formalising the two concepts so > people get less confused... no ideas, just thinking out loud.] > > > Anyway, I tried this out by modifying WebRequestCodingStrategy. The fix > is quite simple and it appears to work without any problems. > > > If you think this is a reasonable proposal, I will create an issue and > submit my patch. > > > Thank you! > David > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
[PROPOSAL] Use path in URL when target is instance of BookmarkablePageRequestTarget
Currently, when a target is an instance of IListenerInterfaceRequestTarget, the URL gets "mounted" (so to speak) on the root of where the wicket application is located. So, if the servlet context path for the wicket application is set to /home/, then all targets (whether bookmarkable or not), are written as something like /home/?wicket:interface=:0. This works, but I think it somewhat defeats the purpose of having mounted pages. Rather, I think it would be better that when the target is an instance of BookmarkablePageRequestTarget, since we can get the target path easily, we should therefore write the URL to that target path, and not the application's root path. So, if I have a form on a page mounted at /home/myform, the above link gets rendered as /home/myform/?wicket:interface=:0 instead. Now, I perfectly understand that this type page has state, so is no longer bookmarkable. However, at least we can preserve the "pretty URL" aspect of the page, which IMO is the original intent. [On that topic, I notice that people often confuse the two related-but-different topics of "pretty urls" and "bookmarkable pages". I wonder if there isn't a better way of formalising the two concepts so people get less confused... no ideas, just thinking out loud.] Anyway, I tried this out by modifying WebRequestCodingStrategy. The fix is quite simple and it appears to work without any problems. If you think this is a reasonable proposal, I will create an issue and submit my patch. Thank you! David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
