wicket-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nino Saturnino Martinez Vazquez Wael <nino.marti...@jayway.dk>
Subject Re: wildcard support for mount paths
Date Fri, 08 Feb 2008 19:43:22 GMT
Yeah I guess that depends if wildcard only goes one layer deep..?

That way you could do this:



That for instance mean that /blog/foo/post/bar/snafu wouldnt be 
catched.. We could then have a all match


which would match all lower levels.. But I think this is one to watch 
out for, as having two filters match would give trouble..

Igor Vaynberg wrote:
> what happens if i have mounts
> /blog/*/post
> /blog/foo/post/bar
> which one is matched? do we not allow this to happen? i would really
> hate to see a situation where the order of calls to mount plays into
> resolution...
> -igor
> On Feb 8, 2008 2:42 AM, Gerolf Seitz <gerolf.seitz@gmail.com> wrote:
>> hi all,
>> i was wondering whether it's possible to have wildcards in mountpaths.
>> this would give us more flexibility, as it allows page parameters to be
>> somehow
>> part of the mount path.
>> take for example this mount path: /blog/*/post
>> the * means that there needs to be exactly one parameter between the path
>> fragments blog and post.
>> after the path fragment post, there can be 0 or more parameters, as usual.
>> some more thoughts
>> # wildcards only make sense when a page is mounted with
>> Indexed*UrlCodingStrategy,
>> as the parameters are ordered (0,1,2,...) with these strategies. otherwise,
>> how do you decide
>> which parameter is used for which wildcard? and since parameters are denoted
>> by name, the order
>> doesn't matter, also not where in the path the parameter is located (but
>> typically it will be after the mount path)
>> # the parameter ordering is the same as we have it now, regardless where the
>> parameter is located.
>> mountpath: /blog/*/post
>> path for a request: /blog/gseitz/post/2008/
>> "gseitz" ... 0th param
>> "2008" ... 1st param
>> # there must be at least one "fixed" mount path fragment (again, same as we
>> have it now),
>> but it doesn't matter _where_ the fragment is positioned in the mount path.
>> so it's possible to mount a page like this: /*/profile
>> mountpaths like /* or /*/* etc. are not allowed (at least not for
>> urlstrategies that support wildcards
>> via an interface like IWildcardProcessingUrlCodingStrategy)
>> # in case the actual parameter for the wildcard parameter is omitted, the
>> request isn't even
>> handed over to the specific urlcodingstrategy
>> i have a working implementation for the above mentioned use cases, but i
>> certainly wanted to get
>> some opinions whether we want to integrate this. so i appreciate any
>> feedback.
>> cheers,
>>   Gerolf

Nino Martinez Wael
Java Specialist @ Jayway DK
+45 2936 7684

View raw message