:
http://www.nabble.com/-wicket-1.5--url-handling-refactor-preview-tp25723884p25914432.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
mad typos :-)
is not a bug deal but not a big deal *lol*
Am 07.10.2009 um 09:40 schrieb Peter Ertl:
well, not a bug deal!
/image/${fullnameIncludingExtension} can be parsed easily :-)
Am 07.10.2009 um 02:14 schrieb Igor Vaynberg:
erm, although we do not quiet support
/${name}.${format}/
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
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
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
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.vaynb...@gmail.com wrote:
Why not use toRequestHandler/ toHandler and toUrl in RequestMapper?
Eelco
On Tue, Oct 6, 2009 at 9:53 AM, Eelco Hillenius
eelco.hillen...@gmail.com wrote:
Looks like an overall improvement. Definitively reduces the spaghetti
a bit. Not crazy about getCompatibilityScore though. I understand
Well, I wouldn't mind changing the name to getPrecedenceScore(), but
that's just naming issue.
Two request mappers can handle same URL, i.e. one is for /mount/point
and one is for /mount/point/more/specific. How would you decide which
one gets to handle the request?
-Matej
On Tue, Oct 6, 2009 at
maybe the same mapper can handle /mount/point by default or
/mount/point/more/specific if some query parameter is present
-igor
On Tue, Oct 6, 2009 at 9:58 AM, Matej Knopp matej.kn...@gmail.com wrote:
Well, I wouldn't mind changing the name to getPrecedenceScore(), but
that's just naming
+1.000 for that
mount RequestHandler will allow any kind of browser output (resources,
pages, server side redirects to external urls, etc.)
being able to access placeholders from resources will be great :-)
thinking of something like:
mount(new MountedMapper(image/${name}.${format},
svn up and see org.apache.wicket.request.mapper.mount
-igor
On Tue, Oct 6, 2009 at 5:11 PM, Peter Ertl pe...@gmx.org wrote:
+1.000 for that
mount RequestHandler will allow any kind of browser output (resources,
pages, server side redirects to external urls, etc.)
being able to access
erm, although we do not quiet support
/${name}.${format}/ only a full path segment can be a placeholder for now.
-igor
On Tue, Oct 6, 2009 at 5:13 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
svn up and see org.apache.wicket.request.mapper.mount
-igor
On Tue, Oct 6, 2009 at 5:11 PM,
also it would be great to provide some easy mechanism of synchronizing
RequestMappers with the wicket session (e.g. rendering data that
depends on the current user info in the session).
Am 07.10.2009 um 02:11 schrieb Peter Ertl:
+1.000 for that
mount RequestHandler will allow any kind of
you can mount a requestmapper that creates threadlocal instances of
handlers :) or has a sync block on session.get(). the possibilities
are endless.
-igor
On Tue, Oct 6, 2009 at 5:20 PM, Peter Ertl pe...@gmx.org wrote:
also it would be great to provide some easy mechanism of synchronizing
On Sun, 4 Oct 2009 13:21:13 -0700, Igor Vaynberg igor.vaynb...@gmail.com
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
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.vanoos...@grons.nl wrote:
On Sun, 4 Oct 2009 13:21:13 -0700, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
but then all you are doing is repeating the
On Sun, Oct 4, 2009 at 3:03 PM, Erik van Oosten e.vanoos...@grons.nl 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
Matej Knopp wrote:
On Sun, Oct 4, 2009 at 3:03 PM, Erik van Oosten e.vanoos...@grons.nl 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
On Sun, Oct 4, 2009 at 6:03 AM, Erik van Oosten e.vanoos...@grons.nl 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
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
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
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.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
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
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
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
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
26 matches
Mail list logo
