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.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 > >> >> > >> > > >> > > >
