This is really overly complex... Keep it simple, ask do you really need such a thing...
On 2/8/08, Nino Saturnino Martinez Vazquez Wael <[EMAIL PROTECTED]> wrote: > Yeah I guess that depends if wildcard only goes one layer deep..? > > That way you could do this: > > /*/foo > /blog/*/post > /blog/foo/* > /blog/foo/post/* > > etc.. > > That for instance mean that /blog/foo/post/bar/snafu wouldnt be > catched.. We could then have a all match > > /blog/foo* > > 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 <[EMAIL PROTECTED]> 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 > http://www.jayway.dk > +45 2936 7684 > >
