Ok, so, how does the WicketFilter figure out which mapper to use?
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 >>> >> >>> > >>> >> >
