right, the order of the mount calls should never be important. and in fact, it isn't. the mount paths are stored in a TreeMap wich sorts the mount paths lexically and by length. this yields the following order in checking mount points for resolving the request target: foo/baz foo/bar foo/*/bar foo bar
now let's assume foo/baz is mounted with mountBookmarkablePage(..) and the path for the request is foo/baz/bar and you originally wanted the request to target the mount point foo/*/bar. as of now, this doesn't work. the first (relevant) mount point that will be checked is foo/baz, _but_ an exception will be thrown, because of an unmatched key/value pair: bar now the question arises: should an IRequestTargetUrlCodingStrategy return true in the matches method, even if it knows that it can't handle the request? gerolf On Feb 8, 2008 7:57 PM, Igor Vaynberg <[EMAIL PROTECTED]> 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 > > >
