Yes this is fine, i just want to see what is easy to understand (and implement for us and use) I think this will not be suported:
/*/blog Thats just horrible. Then we really have to parse every url... What i do like is something like this: /blog/*/xxx and that then only means that that encoding strategy is mounted on: /blog that /*/xxx is then inteprted by the encoding strategy (and they can have ofcourse more then 1) For an indexed this means that * can have something and xxxx is added as the last part) for a query string it means that xxxx param must be there or something .. this only means that the encoding strategies have to have a bit more logic because they are not only matched by the mount but also internally on something else.. (mounts in mounts) johan On Feb 9, 2008 11:32 AM, Gerolf Seitz <[EMAIL PROTECTED]> wrote: > 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 > > > > > >
