+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]

Reply via email to