i agree the * symbol wasn't the best choice. the original idea for this was to avoid having users create dispatch pages which only check for the existence of parameters and then forward the request to another page, but rather mount the right page directly to the desired path.
maybe there's already a better way of doing this some other way, but i thought it might be worth exploring whether this can be handled for users. Gerolf On Feb 9, 2008 9:38 AM, Johan Compagner <[EMAIL PROTECTED]> wrote: > 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 > > >
