[wicket 1.5] url handling refactor preview

[igor.vaynberg]

as ive mentioned before, the focus of 1.5 will be the overhaul of how
we handle the urls and process requests. this part of wicket has grown
organically and has turned into a bunch of overcomplicated spaghetti
code.

matej and i (mostly matej) have been working on an clean room
implementation that we think will be simpler, cleaner, and allow users
to mangle their urls as much as they want.

the preview is available here:
https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng

with a tiny test webapp here

https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng-webapp

this is just a small prototype to allow us to feel out the api before
we begin the nightmarish task of merging this back into wicket proper.

the main package of interest is org.apache.wicket.request which
contains the two key players: RequestMapper and RequestHandler. these
two entities work together to resolve and process urls, facilitated by
the new and much simplified yet functional
org.apache.wicket.requset.cycle.RequestCycle.

the RequestHandler is analogous to IRequestTarget - its job is to
generate a response to user's request.

the RequestMapper is what maps urls to requesthandlers and back. this
is the backbone of url handling. the interface is quiet simple, yet
allows total flexibility. the mappers can be composed and chained,
producing any kind of url scheme desirable. as well as allowing users
to build the url hierarchy in any way they want rather then just
working with absolute mounts like in 1.4.

for example, the ever desirable /<locale>/<all else> url encoding
scheme is now easily achievable by creating a mapper to take care of
the /locale/ portion and chaining all other mappers behind that.

and for the other ever desirable usecase of mounting things like so:
/${user}/profile/${section}/detail there is now the
org.apache.wicket.request.mapper.MountedMapper

further, because mappers are chainable one can foresee a mapper who
doesnt manipulate the url, but instead enforces a security constraint
on a subset of url space.

of interest are also: org/apache/wicket/request/url-format.txt and
org/apache/wicket/page/page-management.txt

feedback is welcome. above all we would like to hear all your weird
and interesting url mapping scheme ideas so we can proof the api
against them.

-igor

[igor.vaynberg]

quick example of a locale prepending mapper mentioned in my previous email

http://gist.github.com/200227

-igor

On Fri, Oct 2, 2009 at 3:47 PM, Igor Vaynberg <igor.vaynberg@...> wrote:

> as ive mentioned before, the focus of 1.5 will be the overhaul of how
> we handle the urls and process requests. this part of wicket has grown
> organically and has turned into a bunch of overcomplicated spaghetti
> code.
>
> matej and i (mostly matej) have been working on an clean room
> implementation that we think will be simpler, cleaner, and allow users
> to mangle their urls as much as they want.
>
> the preview is available here:
> https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng
>
> with a tiny test webapp here
>
> https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng-webapp
>
> this is just a small prototype to allow us to feel out the api before
> we begin the nightmarish task of merging this back into wicket proper.
>
> the main package of interest is org.apache.wicket.request which
> contains the two key players: RequestMapper and RequestHandler. these
> two entities work together to resolve and process urls, facilitated by
> the new and much simplified yet functional
> org.apache.wicket.requset.cycle.RequestCycle.
>
> the RequestHandler is analogous to IRequestTarget - its job is to
> generate a response to user's request.
>
> the RequestMapper is what maps urls to requesthandlers and back. this
> is the backbone of url handling. the interface is quiet simple, yet
> allows total flexibility. the mappers can be composed and chained,
> producing any kind of url scheme desirable. as well as allowing users
> to build the url hierarchy in any way they want rather then just
> working with absolute mounts like in 1.4.
>
> for example, the ever desirable /<locale>/<all else> url encoding
> scheme is now easily achievable by creating a mapper to take care of
> the /locale/ portion and chaining all other mappers behind that.
>
> and for the other ever desirable usecase of mounting things like so:
> /${user}/profile/${section}/detail there is now the
> org.apache.wicket.request.mapper.MountedMapper
>
> further, because mappers are chainable one can foresee a mapper who
> doesnt manipulate the url, but instead enforces a security constraint
> on a subset of url space.
>
> of interest are also: org/apache/wicket/request/url-format.txt and
> org/apache/wicket/page/page-management.txt
>
> feedback is welcome. above all we would like to hear all your weird
> and interesting url mapping scheme ideas so we can proof the api
> against them.
>
> -igor
>

[James Carman-3]

I'm not jazzed about the fact that both methods are named map() when
they're supposed to be inverses of one another.

On Fri, Oct 2, 2009 at 6:47 PM, Igor Vaynberg <igor.vaynberg@...> wrote:

> as ive mentioned before, the focus of 1.5 will be the overhaul of how
> we handle the urls and process requests. this part of wicket has grown
> organically and has turned into a bunch of overcomplicated spaghetti
> code.
>
> matej and i (mostly matej) have been working on an clean room
> implementation that we think will be simpler, cleaner, and allow users
> to mangle their urls as much as they want.
>
> the preview is available here:
> https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng
>
> with a tiny test webapp here
>
> https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng-webapp
>
> this is just a small prototype to allow us to feel out the api before
> we begin the nightmarish task of merging this back into wicket proper.
>
> the main package of interest is org.apache.wicket.request which
> contains the two key players: RequestMapper and RequestHandler. these
> two entities work together to resolve and process urls, facilitated by
> the new and much simplified yet functional
> org.apache.wicket.requset.cycle.RequestCycle.
>
> the RequestHandler is analogous to IRequestTarget - its job is to
> generate a response to user's request.
>
> the RequestMapper is what maps urls to requesthandlers and back. this
> is the backbone of url handling. the interface is quiet simple, yet
> allows total flexibility. the mappers can be composed and chained,
> producing any kind of url scheme desirable. as well as allowing users
> to build the url hierarchy in any way they want rather then just
> working with absolute mounts like in 1.4.
>
> for example, the ever desirable /<locale>/<all else> url encoding
> scheme is now easily achievable by creating a mapper to take care of
> the /locale/ portion and chaining all other mappers behind that.
>
> and for the other ever desirable usecase of mounting things like so:
> /${user}/profile/${section}/detail there is now the
> org.apache.wicket.request.mapper.MountedMapper
>
> further, because mappers are chainable one can foresee a mapper who
> doesnt manipulate the url, but instead enforces a security constraint
> on a subset of url space.
>
> of interest are also: org/apache/wicket/request/url-format.txt and
> org/apache/wicket/page/page-management.txt
>
> feedback is welcome. above all we would like to hear all your weird
> and interesting url mapping scheme ideas so we can proof the api
> against them.
>
> -igor
>

[Matej Knopp]

The methods are
public RequestHandler map(Request request);
public Url map(RequestHandler requestHandler);

is it not obvious from the parameter and return type what is mapped to what?

-Matej

On Sat, Oct 3, 2009 at 3:31 AM, James Carman
<jcarman@...> wrote:

> I'm not jazzed about the fact that both methods are named map() when
> they're supposed to be inverses of one another.
>
> On Fri, Oct 2, 2009 at 6:47 PM, Igor Vaynberg <igor.vaynberg@...> wrote:
>> as ive mentioned before, the focus of 1.5 will be the overhaul of how
>> we handle the urls and process requests. this part of wicket has grown
>> organically and has turned into a bunch of overcomplicated spaghetti
>> code.
>>
>> matej and i (mostly matej) have been working on an clean room
>> implementation that we think will be simpler, cleaner, and allow users
>> to mangle their urls as much as they want.
>>
>> the preview is available here:
>> https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng
>>
>> with a tiny test webapp here
>>
>> https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng-webapp
>>
>> this is just a small prototype to allow us to feel out the api before
>> we begin the nightmarish task of merging this back into wicket proper.
>>
>> the main package of interest is org.apache.wicket.request which
>> contains the two key players: RequestMapper and RequestHandler. these
>> two entities work together to resolve and process urls, facilitated by
>> the new and much simplified yet functional
>> org.apache.wicket.requset.cycle.RequestCycle.
>>
>> the RequestHandler is analogous to IRequestTarget - its job is to
>> generate a response to user's request.
>>
>> the RequestMapper is what maps urls to requesthandlers and back. this
>> is the backbone of url handling. the interface is quiet simple, yet
>> allows total flexibility. the mappers can be composed and chained,
>> producing any kind of url scheme desirable. as well as allowing users
>> to build the url hierarchy in any way they want rather then just
>> working with absolute mounts like in 1.4.
>>
>> for example, the ever desirable /<locale>/<all else> url encoding
>> scheme is now easily achievable by creating a mapper to take care of
>> the /locale/ portion and chaining all other mappers behind that.
>>
>> and for the other ever desirable usecase of mounting things like so:
>> /${user}/profile/${section}/detail there is now the
>> org.apache.wicket.request.mapper.MountedMapper
>>
>> further, because mappers are chainable one can foresee a mapper who
>> doesnt manipulate the url, but instead enforces a security constraint
>> on a subset of url space.
>>
>> of interest are also: org/apache/wicket/request/url-format.txt and
>> org/apache/wicket/page/page-management.txt
>>
>> feedback is welcome. above all we would like to hear all your weird
>> and interesting url mapping scheme ideas so we can proof the api
>> against them.
>>
>> -igor
>>
>

[jthomerson]

public RequestHandler map(Request request);

Is that one not more of a "resolve" action?

--
Jeremy Thomerson
http://www.wickettraining.com



On Fri, Oct 2, 2009 at 8:37 PM, Matej Knopp <matej.knopp@...> wrote:

> The methods are
> public RequestHandler map(Request request);
> public Url map(RequestHandler requestHandler);
>
> is it not obvious from the parameter and return type what is mapped to
> what?
>
> -Matej
>
> On Sat, Oct 3, 2009 at 3:31 AM, James Carman
> <jcarman@...> wrote:
> > I'm not jazzed about the fact that both methods are named map() when
> > they're supposed to be inverses of one another.
> >
> > On Fri, Oct 2, 2009 at 6:47 PM, Igor Vaynberg <igor.vaynberg@...>
> wrote:
> >> as ive mentioned before, the focus of 1.5 will be the overhaul of how
> >> we handle the urls and process requests. this part of wicket has grown
> >> organically and has turned into a bunch of overcomplicated spaghetti
> >> code.
> >>
> >> matej and i (mostly matej) have been working on an clean room
> >> implementation that we think will be simpler, cleaner, and allow users
> >> to mangle their urls as much as they want.
> >>
> >> the preview is available here:
> >>
> https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng
> >>
> >> with a tiny test webapp here
> >>
> >>
> https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng-webapp
> >>
> >> this is just a small prototype to allow us to feel out the api before
> >> we begin the nightmarish task of merging this back into wicket proper.
> >>
> >> the main package of interest is org.apache.wicket.request which
> >> contains the two key players: RequestMapper and RequestHandler. these
> >> two entities work together to resolve and process urls, facilitated by
> >> the new and much simplified yet functional
> >> org.apache.wicket.requset.cycle.RequestCycle.
> >>
> >> the RequestHandler is analogous to IRequestTarget - its job is to
> >> generate a response to user's request.
> >>
> >> the RequestMapper is what maps urls to requesthandlers and back. this
> >> is the backbone of url handling. the interface is quiet simple, yet
> >> allows total flexibility. the mappers can be composed and chained,
> >> producing any kind of url scheme desirable. as well as allowing users
> >> to build the url hierarchy in any way they want rather then just
> >> working with absolute mounts like in 1.4.
> >>
> >> for example, the ever desirable /<locale>/<all else> url encoding
> >> scheme is now easily achievable by creating a mapper to take care of
> >> the /locale/ portion and chaining all other mappers behind that.
> >>
> >> and for the other ever desirable usecase of mounting things like so:
> >> /${user}/profile/${section}/detail there is now the
> >> org.apache.wicket.request.mapper.MountedMapper
> >>
> >> further, because mappers are chainable one can foresee a mapper who
> >> doesnt manipulate the url, but instead enforces a security constraint
> >> on a subset of url space.
> >>
> >> of interest are also: org/apache/wicket/request/url-format.txt and
> >> org/apache/wicket/page/page-management.txt
> >>
> >> feedback is welcome. above all we would like to hear all your weird
> >> and interesting url mapping scheme ideas so we can proof the api
> >> against them.
> >>
> >> -igor
> >>
> >
>

[igor.vaynberg]

it warms my heart to see that matej and i have slaved over a new
design and an initial implementation to eliminate a huge pain point
and the only feedback we get is about method names.

i would much rather hear feedback about the design, the usecases the
design supports, and more importantly the ones it does not.

peace,

-igor

On Fri, Oct 2, 2009 at 8:05 PM, Jeremy Thomerson
<jeremy@...> wrote:

> public RequestHandler map(Request request);
>
> Is that one not more of a "resolve" action?
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
> On Fri, Oct 2, 2009 at 8:37 PM, Matej Knopp <matej.knopp@...> wrote:
>
>> The methods are
>> public RequestHandler map(Request request);
>> public Url map(RequestHandler requestHandler);
>>
>> is it not obvious from the parameter and return type what is mapped to
>> what?
>>
>> -Matej
>>
>> On Sat, Oct 3, 2009 at 3:31 AM, James Carman
>> <jcarman@...> wrote:
>> > I'm not jazzed about the fact that both methods are named map() when
>> > they're supposed to be inverses of one another.
>> >
>> > On Fri, Oct 2, 2009 at 6:47 PM, Igor Vaynberg <igor.vaynberg@...>
>> wrote:
>> >> as ive mentioned before, the focus of 1.5 will be the overhaul of how
>> >> we handle the urls and process requests. this part of wicket has grown
>> >> organically and has turned into a bunch of overcomplicated spaghetti
>> >> code.
>> >>
>> >> matej and i (mostly matej) have been working on an clean room
>> >> implementation that we think will be simpler, cleaner, and allow users
>> >> to mangle their urls as much as they want.
>> >>
>> >> the preview is available here:
>> >>
>> https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng
>> >>
>> >> with a tiny test webapp here
>> >>
>> >>
>> https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng-webapp
>> >>
>> >> this is just a small prototype to allow us to feel out the api before
>> >> we begin the nightmarish task of merging this back into wicket proper.
>> >>
>> >> the main package of interest is org.apache.wicket.request which
>> >> contains the two key players: RequestMapper and RequestHandler. these
>> >> two entities work together to resolve and process urls, facilitated by
>> >> the new and much simplified yet functional
>> >> org.apache.wicket.requset.cycle.RequestCycle.
>> >>
>> >> the RequestHandler is analogous to IRequestTarget - its job is to
>> >> generate a response to user's request.
>> >>
>> >> the RequestMapper is what maps urls to requesthandlers and back. this
>> >> is the backbone of url handling. the interface is quiet simple, yet
>> >> allows total flexibility. the mappers can be composed and chained,
>> >> producing any kind of url scheme desirable. as well as allowing users
>> >> to build the url hierarchy in any way they want rather then just
>> >> working with absolute mounts like in 1.4.
>> >>
>> >> for example, the ever desirable /<locale>/<all else> url encoding
>> >> scheme is now easily achievable by creating a mapper to take care of
>> >> the /locale/ portion and chaining all other mappers behind that.
>> >>
>> >> and for the other ever desirable usecase of mounting things like so:
>> >> /${user}/profile/${section}/detail there is now the
>> >> org.apache.wicket.request.mapper.MountedMapper
>> >>
>> >> further, because mappers are chainable one can foresee a mapper who
>> >> doesnt manipulate the url, but instead enforces a security constraint
>> >> on a subset of url space.
>> >>
>> >> of interest are also: org/apache/wicket/request/url-format.txt and
>> >> org/apache/wicket/page/page-management.txt
>> >>
>> >> feedback is welcome. above all we would like to hear all your weird
>> >> and interesting url mapping scheme ideas so we can proof the api
>> >> against them.
>> >>
>> >> -igor
>> >>
>> >
>>
>

[jthomerson]

My sincere apologies for not sounding appreciative enough.  I think all of
us appreciate the work that the two of you have put in to not only this, but
day-after-day of supporting this framework.  I know I certainly do.

On a lighter note, if that's all people have to critique about, it might be
a sign that it looks good.  (or, that we haven't had sufficient time to look
at the rest of it).

--
Jeremy Thomerson
http://www.wickettraining.com



On Fri, Oct 2, 2009 at 11:50 PM, Igor Vaynberg <igor.vaynberg@...>wrote:

> it warms my heart to see that matej and i have slaved over a new
> design and an initial implementation to eliminate a huge pain point
> and the only feedback we get is about method names.
>
> i would much rather hear feedback about the design, the usecases the
> design supports, and more importantly the ones it does not.
>
> peace,
>
> -igor
>
> On Fri, Oct 2, 2009 at 8:05 PM, Jeremy Thomerson
> <jeremy@...> wrote:
> > public RequestHandler map(Request request);
> >
> > Is that one not more of a "resolve" action?
> >
> > --
> > Jeremy Thomerson
> > http://www.wickettraining.com
> >
> >
> >
> > On Fri, Oct 2, 2009 at 8:37 PM, Matej Knopp <matej.knopp@...>
> wrote:
> >
> >> The methods are
> >> public RequestHandler map(Request request);
> >> public Url map(RequestHandler requestHandler);
> >>
> >> is it not obvious from the parameter and return type what is mapped to
> >> what?
> >>
> >> -Matej
> >>
> >> On Sat, Oct 3, 2009 at 3:31 AM, James Carman
> >> <jcarman@...> wrote:
> >> > I'm not jazzed about the fact that both methods are named map() when
> >> > they're supposed to be inverses of one another.
> >> >
> >> > On Fri, Oct 2, 2009 at 6:47 PM, Igor Vaynberg <
> igor.vaynberg@...>
> >> wrote:
> >> >> as ive mentioned before, the focus of 1.5 will be the overhaul of how
> >> >> we handle the urls and process requests. this part of wicket has
> grown
> >> >> organically and has turned into a bunch of overcomplicated spaghetti
> >> >> code.
> >> >>
> >> >> matej and i (mostly matej) have been working on an clean room
> >> >> implementation that we think will be simpler, cleaner, and allow
> users
> >> >> to mangle their urls as much as they want.
> >> >>
> >> >> the preview is available here:
> >> >>
> >>
> https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng
> >> >>
> >> >> with a tiny test webapp here
> >> >>
> >> >>
> >>
> https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng-webapp
> >> >>
> >> >> this is just a small prototype to allow us to feel out the api before
> >> >> we begin the nightmarish task of merging this back into wicket
> proper.
> >> >>
> >> >> the main package of interest is org.apache.wicket.request which
> >> >> contains the two key players: RequestMapper and RequestHandler. these
> >> >> two entities work together to resolve and process urls, facilitated
> by
> >> >> the new and much simplified yet functional
> >> >> org.apache.wicket.requset.cycle.RequestCycle.
> >> >>
> >> >> the RequestHandler is analogous to IRequestTarget - its job is to
> >> >> generate a response to user's request.
> >> >>
> >> >> the RequestMapper is what maps urls to requesthandlers and back. this
> >> >> is the backbone of url handling. the interface is quiet simple, yet
> >> >> allows total flexibility. the mappers can be composed and chained,
> >> >> producing any kind of url scheme desirable. as well as allowing users
> >> >> to build the url hierarchy in any way they want rather then just
> >> >> working with absolute mounts like in 1.4.
> >> >>
> >> >> for example, the ever desirable /<locale>/<all else> url encoding
> >> >> scheme is now easily achievable by creating a mapper to take care of
> >> >> the /locale/ portion and chaining all other mappers behind that.
> >> >>
> >> >> and for the other ever desirable usecase of mounting things like so:
> >> >> /${user}/profile/${section}/detail there is now the
> >> >> org.apache.wicket.request.mapper.MountedMapper
> >> >>
> >> >> further, because mappers are chainable one can foresee a mapper who
> >> >> doesnt manipulate the url, but instead enforces a security constraint
> >> >> on a subset of url space.
> >> >>
> >> >> of interest are also: org/apache/wicket/request/url-format.txt and
> >> >> org/apache/wicket/page/page-management.txt
> >> >>
> >> >> feedback is welcome. above all we would like to hear all your weird
> >> >> and interesting url mapping scheme ideas so we can proof the api
> >> >> against them.
> >> >>
> >> >> -igor
> >> >>
> >> >
> >>
> >
>

[James Carman-3]

Ok, so, how does the WicketFilter figure out which mapper to use?

On Sat, Oct 3, 2009 at 12:50 AM, Igor Vaynberg <igor.vaynberg@...> wrote:

> it warms my heart to see that matej and i have slaved over a new
> design and an initial implementation to eliminate a huge pain point
> and the only feedback we get is about method names.
>
> i would much rather hear feedback about the design, the usecases the
> design supports, and more importantly the ones it does not.
>
> peace,
>
> -igor
>
> On Fri, Oct 2, 2009 at 8:05 PM, Jeremy Thomerson
> <jeremy@...> wrote:
>> public RequestHandler map(Request request);
>>
>> Is that one not more of a "resolve" action?
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>>
>>
>> On Fri, Oct 2, 2009 at 8:37 PM, Matej Knopp <matej.knopp@...> wrote:
>>
>>> The methods are
>>> public RequestHandler map(Request request);
>>> public Url map(RequestHandler requestHandler);
>>>
>>> is it not obvious from the parameter and return type what is mapped to
>>> what?
>>>
>>> -Matej
>>>
>>> On Sat, Oct 3, 2009 at 3:31 AM, James Carman
>>> <jcarman@...> wrote:
>>> > I'm not jazzed about the fact that both methods are named map() when
>>> > they're supposed to be inverses of one another.
>>> >
>>> > On Fri, Oct 2, 2009 at 6:47 PM, Igor Vaynberg <igor.vaynberg@...>
>>> wrote:
>>> >> as ive mentioned before, the focus of 1.5 will be the overhaul of how
>>> >> we handle the urls and process requests. this part of wicket has grown
>>> >> organically and has turned into a bunch of overcomplicated spaghetti
>>> >> code.
>>> >>
>>> >> matej and i (mostly matej) have been working on an clean room
>>> >> implementation that we think will be simpler, cleaner, and allow users
>>> >> to mangle their urls as much as they want.
>>> >>
>>> >> the preview is available here:
>>> >>
>>> https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng
>>> >>
>>> >> with a tiny test webapp here
>>> >>
>>> >>
>>> https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng-webapp
>>> >>
>>> >> this is just a small prototype to allow us to feel out the api before
>>> >> we begin the nightmarish task of merging this back into wicket proper.
>>> >>
>>> >> the main package of interest is org.apache.wicket.request which
>>> >> contains the two key players: RequestMapper and RequestHandler. these
>>> >> two entities work together to resolve and process urls, facilitated by
>>> >> the new and much simplified yet functional
>>> >> org.apache.wicket.requset.cycle.RequestCycle.
>>> >>
>>> >> the RequestHandler is analogous to IRequestTarget - its job is to
>>> >> generate a response to user's request.
>>> >>
>>> >> the RequestMapper is what maps urls to requesthandlers and back. this
>>> >> is the backbone of url handling. the interface is quiet simple, yet
>>> >> allows total flexibility. the mappers can be composed and chained,
>>> >> producing any kind of url scheme desirable. as well as allowing users
>>> >> to build the url hierarchy in any way they want rather then just
>>> >> working with absolute mounts like in 1.4.
>>> >>
>>> >> for example, the ever desirable /<locale>/<all else> url encoding
>>> >> scheme is now easily achievable by creating a mapper to take care of
>>> >> the /locale/ portion and chaining all other mappers behind that.
>>> >>
>>> >> and for the other ever desirable usecase of mounting things like so:
>>> >> /${user}/profile/${section}/detail there is now the
>>> >> org.apache.wicket.request.mapper.MountedMapper
>>> >>
>>> >> further, because mappers are chainable one can foresee a mapper who
>>> >> doesnt manipulate the url, but instead enforces a security constraint
>>> >> on a subset of url space.
>>> >>
>>> >> of interest are also: org/apache/wicket/request/url-format.txt and
>>> >> org/apache/wicket/page/page-management.txt
>>> >>
>>> >> feedback is welcome. above all we would like to hear all your weird
>>> >> and interesting url mapping scheme ideas so we can proof the api
>>> >> against them.
>>> >>
>>> >> -igor
>>> >>
>>> >
>>>
>>
>

[Matej Knopp]

On Sat, Oct 3, 2009 at 2:28 PM, James Carman
<jcarman@...> wrote:
> Ok, so, how does the WicketFilter figure out which mapper to use?

It goes roughly like this:

- Wicket filter extract the part of URL after wicket filter
(represented by Url object)
- RequestCycle gets the Url
- RequestCycle asks root RequestMapper for appropriate RequestHandler
for the Url
- Root RequestMapper is either CompoundRequestMapper or delegates to a
CompoundRequestMapper
- CompoundRequestMapper asks each of its mapper for a score for given
URL and then depending on the score asks the mappers to decode the URL

The code is rather straightforward (especially compared to current
wicket code) so you can take a look yourself.

-Matej

>
> On Sat, Oct 3, 2009 at 12:50 AM, Igor Vaynberg <igor.vaynberg@...> wrote:
>> it warms my heart to see that matej and i have slaved over a new
>> design and an initial implementation to eliminate a huge pain point
>> and the only feedback we get is about method names.
>>
>> i would much rather hear feedback about the design, the usecases the
>> design supports, and more importantly the ones it does not.
>>
>> peace,
>>
>> -igor
>>
>> On Fri, Oct 2, 2009 at 8:05 PM, Jeremy Thomerson
>> <jeremy@...> wrote:
>>> public RequestHandler map(Request request);
>>>
>>> Is that one not more of a "resolve" action?
>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wickettraining.com
>>>
>>>
>>>
>>> On Fri, Oct 2, 2009 at 8:37 PM, Matej Knopp <matej.knopp@...> wrote:
>>>
>>>> The methods are
>>>> public RequestHandler map(Request request);
>>>> public Url map(RequestHandler requestHandler);
>>>>
>>>> is it not obvious from the parameter and return type what is mapped to
>>>> what?
>>>>
>>>> -Matej
>>>>
>>>> On Sat, Oct 3, 2009 at 3:31 AM, James Carman
>>>> <jcarman@...> wrote:
>>>> > I'm not jazzed about the fact that both methods are named map() when
>>>> > they're supposed to be inverses of one another.
>>>> >
>>>> > On Fri, Oct 2, 2009 at 6:47 PM, Igor Vaynberg <igor.vaynberg@...>
>>>> wrote:
>>>> >> as ive mentioned before, the focus of 1.5 will be the overhaul of how
>>>> >> we handle the urls and process requests. this part of wicket has grown
>>>> >> organically and has turned into a bunch of overcomplicated spaghetti
>>>> >> code.
>>>> >>
>>>> >> matej and i (mostly matej) have been working on an clean room
>>>> >> implementation that we think will be simpler, cleaner, and allow users
>>>> >> to mangle their urls as much as they want.
>>>> >>
>>>> >> the preview is available here:
>>>> >>
>>>> https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng
>>>> >>
>>>> >> with a tiny test webapp here
>>>> >>
>>>> >>
>>>> https://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket-ng-webapp
>>>> >>
>>>> >> this is just a small prototype to allow us to feel out the api before
>>>> >> we begin the nightmarish task of merging this back into wicket proper.
>>>> >>
>>>> >> the main package of interest is org.apache.wicket.request which
>>>> >> contains the two key players: RequestMapper and RequestHandler. these
>>>> >> two entities work together to resolve and process urls, facilitated by
>>>> >> the new and much simplified yet functional
>>>> >> org.apache.wicket.requset.cycle.RequestCycle.
>>>> >>
>>>> >> the RequestHandler is analogous to IRequestTarget - its job is to
>>>> >> generate a response to user's request.
>>>> >>
>>>> >> the RequestMapper is what maps urls to requesthandlers and back. this
>>>> >> is the backbone of url handling. the interface is quiet simple, yet
>>>> >> allows total flexibility. the mappers can be composed and chained,
>>>> >> producing any kind of url scheme desirable. as well as allowing users
>>>> >> to build the url hierarchy in any way they want rather then just
>>>> >> working with absolute mounts like in 1.4.
>>>> >>
>>>> >> for example, the ever desirable /<locale>/<all else> url encoding
>>>> >> scheme is now easily achievable by creating a mapper to take care of
>>>> >> the /locale/ portion and chaining all other mappers behind that.
>>>> >>
>>>> >> and for the other ever desirable usecase of mounting things like so:
>>>> >> /${user}/profile/${section}/detail there is now the
>>>> >> org.apache.wicket.request.mapper.MountedMapper
>>>> >>
>>>> >> further, because mappers are chainable one can foresee a mapper who
>>>> >> doesnt manipulate the url, but instead enforces a security constraint
>>>> >> on a subset of url space.
>>>> >>
>>>> >> of interest are also: org/apache/wicket/request/url-format.txt and
>>>> >> org/apache/wicket/page/page-management.txt
>>>> >>
>>>> >> feedback is welcome. above all we would like to hear all your weird
>>>> >> and interesting url mapping scheme ideas so we can proof the api
>>>> >> against them.
>>>> >>
>>>> >> -igor
>>>> >>
>>>> >
>>>>
>>>
>>
>

[Erik van Oosten]

Hi,

* I am delighted that the root request mapper is also pluggable and that
request mappers can easily decorate other request mappers.

* In the new setup, am I correct in assuming that you can override the
root request mapper to make it possible to parse parameters for the
'home page'? I am looking for an easy way to parse URIs like "/?p1=v1".
I see that the example app still needs to override getHomePage. I guess
this is no longer needed always.

* With all respect to the given code, good names are important and
therefore comments on names are important as well. A good name will
deepen understanding. I too find that overloading of these 2 method
names is not correct as they do not perform the same function.

* There is also a little bell in my head saying that the 2 map methods
are not symmetric. I guess this can not be helped as incoming requests
have post data where as generated URLs do not. I like the URL class, in
a RequestMapper decorator it makes it possible to manipulate the URL
that was given by the chained RequestMapper.

* I am a bit confused about the RequestHandler interface. It contains
nothing to get the request's parameters. How is method
RequestMapper#map(RequestHandler) supposed to work then? I guess it will
always need to know about the types of RequestHandlers it supports. This
introduces a tight coupling I did not expect. (I am not saying it is
wrong, it just confused me.)

* I don't like AbstractRequestMapper. Its sole function is to provide
helper methods. These are better located in a separate helper class.

* Its not yet clear to me how to implement pages that put part of the
parameters in the URL and part in the page state. E.g. for a product
list page put the product category in the URL and the current sort order
in a component field. Will this be possible? Easy?

* I guess BufferedResponseMapper#getCompatibilityScore should return
Integer.MIN_VALUE (instead of 0) when it can not process the request. Or
is 0 a kind of magic value?

* What MountedMapper does is priceless!

* When I look at ThreadsafeCompoundRequestMapper I am a (little) bit
worried about performance. The main worry is that methods are called
multiple times for the same request. For example method
getCompatibilityScore of the nested RequestMappers is called in both
map(Request) as in getCompatibilityScore. A request mapper can not
simultaneously calculate a map and a compatibility score precluding some
optimizations.

My time is up. This is definitely an improvement over previous
implementations. Even though there are still some corner cases (I still
see a few instanceof's), it is much more straight forward. I hope to see
this code merged as soon as possible.

Regards,
    Erik.


Igor Vaynberg wrote:

> as ive mentioned before, the focus of 1.5 will be the overhaul of how
> we handle the urls and process requests. this part of wicket has grown
> organically and has turned into a bunch of overcomplicated spaghetti
> code.
>
> .........
>
> feedback is welcome. above all we would like to hear all your weird
> and interesting url mapping scheme ideas so we can proof the api
> against them.
>
> -igor
>  

--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/

[Matej Knopp]

On Sun, Oct 4, 2009 at 3:03 PM, Erik van Oosten <e.vanoosten@...> wrote:

> Hi,
>
> * I am delighted that the root request mapper is also pluggable and that
> request mappers can easily decorate other request mappers.
>
> * In the new setup, am I correct in assuming that you can override the root
> request mapper to make it possible to parse parameters for the 'home page'?
> I am looking for an easy way to parse URIs like "/?p1=v1". I see that the
> example app still needs to override getHomePage. I guess this is no longer
> needed always.

Yes. The root mapper can intercept all URLs. It can handle only
certain URLs and let the delegate handler others. Even better it can
easily transform the URLs.
>
> * With all respect to the given code, good names are important and therefore
> comments on names are important as well. A good name will deepen
> understanding. I too find that overloading of these 2 method names is not
> correct as they do not perform the same function.
Given the confusion the map methods cause we might consider renaming them.
>
> * There is also a little bell in my head saying that the 2 map methods are
> not symmetric. I guess this can not be helped as incoming requests have post
> data where as generated URLs do not. I like the URL class, in a
> RequestMapper decorator it makes it possible to manipulate the URL that was
> given by the chained RequestMapper.
Yes. Some mappers might need to see the POST data therefore the method
gets Request object instead of URL.
>
> * I am a bit confused about the RequestHandler interface. It contains
> nothing to get the request's parameters. How is method
> RequestMapper#map(RequestHandler) supposed to work then? I guess it will
> always need to know about the types of RequestHandlers it supports. This
> introduces a tight coupling I did not expect. (I am not saying it is wrong,
> it just confused me.)
RequestHandler should not care about request parameters at all. That's
what RequestMapper does. It takes request and produces RequestHandler.
It must of course know which handlers to produce and which it can
accept (to generate URLs). On the other hand RequestHandler doesn't
know about RequestMapper nor should it. It's not tight coupling, just
a chain of responsibility.

RequestMapper knows how to parse urls and create request handlers, it
also knows how to produce URLs for those request handlers. The
responsibility of RequestHandler is to produce response (which can
sometimes include other activities, such as invoking listener
interface on components).

>
> * I don't like AbstractRequestMapper. Its sole function is to provide helper
> methods. These are better located in a separate helper class.
Helper class with bunch of static methods? I really don't see any
benefit. i think it would just make the code uglier.
>
> * Its not yet clear to me how to implement pages that put part of the
> parameters in the URL and part in the page state. E.g. for a product list
> page put the product category in the URL and the current sort order in a
> component field. Will this be possible? Easy?
It should be much easier than in 1.4. If you want to store some state
as parameter you would call
getPage().getPageParameters().setNamedParameter("foo", "bar")  or
getPage().getPageParameters().setIndexedParameter(0, "abc");

Look at wicket-ng-webapp TestPage1.
>
> * I guess BufferedResponseMapper#getCompatibilityScore should return
> Integer.MIN_VALUE (instead of 0) when it can not process the request. Or is
> 0 a kind of magic value?
Well, if being the smallest positive number counts as magical then
yes. If java had unsigned numbers the result type would be unsigned
int. Look at RequestMapper#getCompatibilityScore javadoc. There is a
suggestion how the algorithm should work (matching number of
segments).
>
> * What MountedMapper does is priceless!
>
> * When I look at ThreadsafeCompoundRequestMapper I am a (little) bit worried
> about performance. The main worry is that methods are called multiple times
> for the same request. For example method getCompatibilityScore of the nested
> RequestMappers is called in both map(Request) as in getCompatibilityScore. A
> request mapper can not simultaneously calculate a map and a compatibility
> score precluding some optimizations.
Premature optimizations most probably. Unless you have thousands of
mount points. Also, implementation wise compatibility score
can be completely independent to request decoding.
Nevertheless should this become a bottleneck (which i think is highly
unlikely)  we can cache
the compatibility score during request in RequestCycle metadata.
>
> My time is up. This is definitely an improvement over previous
> implementations. Even though there are still some corner cases (I still see
> a few instanceof's), it is much more straight forward. I hope to see this
> code merged as soon as possible.
Some instanceofs are used in RequestMappers. Each request mapper knows
what kind of requesthandlers it can encode. We could probably
implement it without the instanceof checks but I really doubt it would
make the code any more readable or simpler.

Thanks for the feedback!

-Matej

>
> Regards,
>   Erik.
>
>
> Igor Vaynberg wrote:
>>
>> as ive mentioned before, the focus of 1.5 will be the overhaul of how
>> we handle the urls and process requests. this part of wicket has grown
>> organically and has turned into a bunch of overcomplicated spaghetti
>> code.
>>
>> .........
>>
>> feedback is welcome. above all we would like to hear all your weird
>> and interesting url mapping scheme ideas so we can proof the api
>> against them.
>>
>> -igor
>>
>
>
> --
> Erik van Oosten
> http://www.day-to-day-stuff.blogspot.com/
>
>

[Erik van Oosten]

Matej Knopp wrote:

> On Sun, Oct 4, 2009 at 3:03 PM, Erik van Oosten <e.vanoosten@...> wrote:
>  
>> * I am a bit confused about the RequestHandler interface. It contains
>> nothing to get the request's parameters. How is method
>> RequestMapper#map(RequestHandler) supposed to work then? I guess it will
>> always need to know about the types of RequestHandlers it supports. This
>> introduces a tight coupling I did not expect. (I am not saying it is wrong,
>> it just confused me.)
>>    
> RequestHandler should not care about request parameters at all. That's
> what RequestMapper does. It takes request and produces RequestHandler.
> It must of course know which handlers to produce and which it can
> accept (to generate URLs). On the other hand RequestHandler doesn't
> know about RequestMapper nor should it. It's not tight coupling, just
> a chain of responsibility.
>
> RequestMapper knows how to parse urls and create request handlers, it
> also knows how to produce URLs for those request handlers. The
> responsibility of RequestHandler is to produce response (which can
> sometimes include other activities, such as invoking listener
> interface on components).
>  

I think I get your point: each RequestMapper is responsible for both Url
<-> ReqeustHandler conversions and therefore should always know what its
doing. Still, there is a tight coupling (I now understand, a good
uni-directional one) between each RequestMapper instance to the
RequestHandlers it supports.

>> * I guess BufferedResponseMapper#getCompatibilityScore should return
>> Integer.MIN_VALUE (instead of 0) when it can not process the request. Or is
>> 0 a kind of magic value?
>>    
> Well, if being the smallest positive number counts as magical then
> yes. If java had unsigned numbers the result type would be unsigned
> int. Look at RequestMapper#getCompatibilityScore javadoc. There is a
> suggestion how the algorithm should work (matching number of
> segments).
>  

Right, I saw that. I guess some kind of documentation is needed that
will vaguely describe what numbers are expected. I was also thinking
about the name. The score is my thinking more about precedence then
about compatibility (though after some more thinking I understand the
term). What do you think about PrecedenceScore?

>> * When I look at ThreadsafeCompoundRequestMapper I am a (little) bit worried
>> about performance. The main worry is that methods are called multiple times
>> for the same request. For example method getCompatibilityScore of the nested
>> RequestMappers is called in both map(Request) as in getCompatibilityScore. A
>> request mapper can not simultaneously calculate a map and a compatibility
>> score precluding some optimizations.
>>    
> Premature optimizations most probably. Unless you have thousands of
> mount points. Also, implementation wise compatibility score
> can be completely independent to request decoding.
> Nevertheless should this become a bottleneck (which i think is highly
> unlikely)  we can cache
> the compatibility score during request in RequestCycle metadata.
>  

Yes, very true.

Regards,
     Erik.

--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/

[igor.vaynberg]

On Sun, Oct 4, 2009 at 6:03 AM, Erik van Oosten <e.vanoosten@...> wrote:

> * With all respect to the given code, good names are important and therefore
> comments on names are important as well. A good name will deepen
> understanding. I too find that overloading of these 2 method names is not
> correct as they do not perform the same function.

so as far as I see it, everyone so far likes the name RequestMapper,
or IRequestMapper as it soon may be named. Because that makes sense,
the mapper maps requests to handlers, and handlers to urls. yes, it is
unfortunately asymmetric.

so since a mapper maps requests why not simply name the methods map().
in fact, bot methods *do* the same thing - which is to map one thing
to another. what would better names be?

RequestHandler mapRequestToHandler(Request);
Url mapHandlerToUrl(Handler);

RequestHandler mapToHandler(Request);
Url mapToUrl(Url);

but then all you are doing is repeating the information that is
already in the method signature in the method name. why?

-igor

[Erik van Oosten]

On Sun, 4 Oct 2009 13:21:13 -0700, Igor Vaynberg <igor.vaynberg@...>
wrote:
> but then all you are doing is repeating the information that is
> already in the method signature in the method name. why?
>
> -igor

Very simple: communication. In my previous e-mail I constantly had to write
map(RequestHandler) or map(Request) in order to say which method I was
talking about. Also, in the reply of Matje I had to read very carefully to
see which map method he was writing about.

Regards,
    Erik.

[igor.vaynberg]

so the difference is

map(handler) vs maphandler() and map(url) vs mapurl() ?

-igor

On Mon, Oct 5, 2009 at 12:43 AM, Erik van Oosten <e.vanoosten@...> wrote:

>
> On Sun, 4 Oct 2009 13:21:13 -0700, Igor Vaynberg <igor.vaynberg@...>
> wrote:
>> but then all you are doing is repeating the information that is
>> already in the method signature in the method name. why?
>>
>> -igor
>
> Very simple: communication. In my previous e-mail I constantly had to write
> map(RequestHandler) or map(Request) in order to say which method I was
> talking about. Also, in the reply of Matje I had to read very carefully to
> see which map method he was writing about.
>
> Regards,
>    Erik.
>

[Daniel Stoch-2]

The great thing for me is that I'll be able to mounting something that
just implements RequestablePage interface, not only a Page class
descendants (if I've read this code correctly :)). It allows to handle
navigation more flexible and it allows to avoid creating hard to
maintain page class hierarchies.

--
Daniel

[igor.vaynberg]

ahha, here is something we need to change. we should have a
mountedmapper that allows one to mount a requesthandler rather then a
page. the user should not go as far as having to implement
requestablepage, there are a lot of extraneous methods there if all
you want to do is handle the request yourself.

-igor

On Tue, Oct 6, 2009 at 3:08 AM, Daniel Stoch <daniel.stoch@...> wrote:
> The great thing for me is that I'll be able to mounting something that
> just implements RequestablePage interface, not only a Page class
> descendants (if I've read this code correctly :)). It allows to handle
> navigation more flexible and it allows to avoid creating hard to
> maintain page class hierarchies.
>
> --
> Daniel
>

[Peter Ertl-3]

Could you change versionId from "1.4-SNAPSHOT" to "1.5-experimental-
SNAPSHOT" (or similar) to simplify testing with maven? It's a little  
nasty to overwrite the local repository...

Other that that the design looks very promising. I would love to have  
a simple way of mapping virtual urls to a DynamicContentPage for  
creating CMS-style pages

 From the request mapper part I would like to do something something  
like this easily:

   map content from virtual url  (which is mapped at /)
   e.g. /welcome.html would map to a database page, /logo.gif would  
map to a image/gif resource
   load dynamic content from database (which can be: page, image or  
other kind of resource, redirect to external url, etc.)
   output result:
   - render page
   - write resource
   - send redirect
   - ...

I still have to dig into the coding (so much code, so little time :-),  
probably all of this is already trivial and done :-)

Am 06.10.2009 um 17:13 schrieb Igor Vaynberg:

> ahha, here is something we need to change. we should have a
> mountedmapper that allows one to mount a requesthandler rather then a
> page. the user should not go as far as having to implement
> requestablepage, there are a lot of extraneous methods there if all
> you want to do is handle the request yourself.
>
> -igor
>
> On Tue, Oct 6, 2009 at 3:08 AM, Daniel Stoch  
> <daniel.stoch@...> wrote:
>> The great thing for me is that I'll be able to mounting something  
>> that
>> just implements RequestablePage interface, not only a Page class
>> descendants (if I've read this code correctly :)). It allows to  
>> handle
>> navigation more flexible and it allows to avoid creating hard to
>> maintain page class hierarchies.
>>
>> --
>> Daniel
>>

[Eelco Hillenius]

Looks like an overall improvement. Definitively reduces the spaghetti
a bit. Not crazy about getCompatibilityScore though. I understand it's
purpose and maybe it's the best solution, but it looks like a crutch.

Eelco

On Tue, Oct 6, 2009 at 8:13 AM, Igor Vaynberg <igor.vaynberg@...> wrote:

> ahha, here is something we need to change. we should have a
> mountedmapper that allows one to mount a requesthandler rather then a
> page. the user should not go as far as having to implement
> requestablepage, there are a lot of extraneous methods there if all
> you want to do is handle the request yourself.
>
> -igor
>
> On Tue, Oct 6, 2009 at 3:08 AM, Daniel Stoch <daniel.stoch@...> wrote:
>> The great thing for me is that I'll be able to mounting something that
>> just implements RequestablePage interface, not only a Page class
>> descendants (if I've read this code correctly :)). It allows to handle
>> navigation more flexible and it allows to avoid creating hard to
>> maintain page class hierarchies.
>>
>> --
>> Daniel
>>
>

[Eelco Hillenius]

Why not use toRequestHandler/ toHandler and toUrl in RequestMapper?

Eelco

On Tue, Oct 6, 2009 at 9:53 AM, Eelco Hillenius
<eelco.hillenius@...> wrote:

> Looks like an overall improvement. Definitively reduces the spaghetti
> a bit. Not crazy about getCompatibilityScore though. I understand it's
> purpose and maybe it's the best solution, but it looks like a crutch.
>
> Eelco
>
> On Tue, Oct 6, 2009 at 8:13 AM, Igor Vaynberg <igor.vaynberg@...> wrote:
>> ahha, here is something we need to change. we should have a
>> mountedmapper that allows one to mount a requesthandler rather then a
>> page. the user should not go as far as having to implement
>> requestablepage, there are a lot of extraneous methods there if all
>> you want to do is handle the request yourself.
>>
>> -igor
>>
>> On Tue, Oct 6, 2009 at 3:08 AM, Daniel Stoch <daniel.stoch@...> wrote:
>>> The great thing for me is that I'll be able to mounting something that
>>> just implements RequestablePage interface, not only a Page class
>>> descendants (if I've read this code correctly :)). It allows to handle
>>> navigation more flexible and it allows to avoid creating hard to
>>> maintain page class hierarchies.
>>>
>>> --
>>> Daniel
>>>
>>
>