true.. Better to solve 90 percent (maybe more), and have a simple
understandable solution..
Johan Compagner wrote:
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
--
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
