I think this will make things more comples. And what you want is easily solved by just making the 'post' url string part also an parameter. You dont do anything with it but your example like
/blog/gerolf/2008/post Where for you only the middle 2 are importand but the last one is just discarded. Or are you saying that you also want to have besides that bookmark another one like /blog/*/view ? This is also already 'possible' to do in wicket but thats not very nice solution, i agree. So if it is the case that you want to have /blog/*/view and /blog/*/post then i would say that * means any param must be post.. Then it is very easy to implement.. It is just mounted under /blog but the indexed can have another hit criteria and that is 1 of its params must be view. If we add the second 'post' then it is still under the mount /blog but added to the other one that now also checks for post param. Then we loose thism, this /blog/*/*/post is the same as /blog/*/post but if that really matters... By the way * mostly already means 1 or more. Look at regexp. So for me its not a wildcard expression but a mount path to tell that there must be a param in it. Then we also can use it for all other coding strategies. On 2/8/08, 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 >
