On 11/16/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> what a stupid thing to say considering it was probably johan > that wrote that > part of the code in the first place. you wont be making any > friends here > saying things like these. i replied to his statement - and if im on a black list cause i critizise him, so it be.
we dont have a black list. in my book you have lost proverbial "notch". i dont know if he wrote that or did it as i never made him
resonsible for that, the thing i dont like is this eternal "and will stay" -
he spent a lot of time trying to explain to you the reasons for this - you just refuse to listen because this broken functionality worked in your very particular usecase. in the end there is nothing wrong with a committer telling you that the api will stay the way it is. we are the ones working on it, so we make the decisions. we try to be as accomodating as possible, but when n00b users ask for what we think will do more harm then good we are free to say no. of course you are free to fork wicket if you do not like how we run it.
you used that api in a way it was not meant to be used. it is > "lucky" that > it worked for you because it was not our intention to make > your usecase > work. this why we stripped this functionality. btw, it was > stripped way > before you showed up or someone tried to do what you did. maybe it wasnt meant for this... the internet wasnt meant to be what its today, so should we strip it away? (yes, this was polemic but is near to the point)
huh?
in the end i think what you want can be implemented if you > have the ability > to mount the homepage on "/" with the index coding strategy. coding > strategies for the homepage or "/" is not something we > support right now. so > if you think this will solve your usecase add an rfe to the jira. this point is now what i call constructive - in the thread i got no solution or anything mentioned near to that, but a "no", "dont work" etc.
what you got was an explanation of why what you were doing was wrong. that is very constructive imho, you just need to listen. dont forget it is not our job to tell you how to solve your problems - so take any help you can get. regarding the "/" mount for the app Home Page: isn't this an JEE antipattern
as the welcome-page should be declared in web.xml?
"/" is relative to your servlet mapping not the "context/" unless you map it that way - it is up to you. -igor regards
Korbinian > > -igor > > > -----Ursprüngliche Nachricht----- > > > Von: Johan Compagner [mailto:[EMAIL PROTECTED] > > > Gesendet: Donnerstag, 16. November 2006 14:50 > > > An: wicket-dev@incubator.apache.org > > > Betreff: Re: wicket2 / multi-mounts to class > > > > > > > so you manually change your link to be at the mountpoint... > > > > > > > > > > > > Where do you manually change it? > > > I was just pointing out that the 2 mount params must be in > > > sync in wicket else it doesn't work by default. If somebody > > > makes a mistake an configures it like i said it goes wrong. > > > The url will be encoded to something that when it is clicked > > > on will not be decoded. > > > That why it is dangerous to have the mount(string,coder) > > > method and why it is removed in wicket 2.0 (and it will > stay that way) > > > > > > > > > URLs are build like that: preParams / postParams > > > > while the first part of the preParams is the mountpoint... > > > > > > > > i didnt consider it a bug, but a big feature as it also > allows even > > > > the most complicated URL creation schemes as well as > more enhanced > > > > CodingStrategies > > > > > > > > > > > > Where do you use your coding strategies then for then? > > > Because or you don't use it completely for the encoding > > > (setResponsePage( > > > Page.class)) > > > or you don't use it complete for the decoding when a > request comes in. > > > > > > mount("/path/to/page2", new > > > > > BookmarkablePageRequestTargetUrlCodingStrategy("", > > > > > Page2.class,null)); > > > > > > > > is IMHO not a mountpoint but a pain - a mountpoint is a "short" > > > > description > > > > of what comes to a page > > > > > > > > e.g: "/path/" would be enough here... everything of a URL > > > is logic - > > > > and that has to be handled by the appropriate class and > not coded > > > > fixed into a init function > > > > > > > > > > > > That was just an example fine we use your example: > > > > > > mount("/path", new > BookmarkablePageRequestTargetUrlCodingStrategy("", > > > Page2.class,null)); > > > > > > Still doesn't work at all. > > > The encode will generate a "/" url (with nothing behind it if > > > there are no page params) the decode will only accept urls > > > that starts with "/path" > > > > > > johan > > > > > > > >
