On Sat, Oct 3, 2009 at 2:28 PM, James Carman <jcar...@carmanconsulting.com> 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.vaynb...@gmail.com> > 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 >> <jer...@wickettraining.com> 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.kn...@gmail.com> 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 >>>> <jcar...@carmanconsulting.com> 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.vaynb...@gmail.com> >>>> 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 >>>> >> >>>> > >>>> >>> >> >
