> > > 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) > > > > ok, basically this comes to: you never got it working/ dont > understand > > it so stripped it... > > > 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. 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" - > 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) > > 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. regarding the "/" mount for the app Home Page: isn't this an JEE antipattern as the welcome-page should be declared in web.xml? regards Korbinian > > -igor > > > -----Ursprüngliche Nachricht----- > > > Von: Johan Compagner [mailto:[EMAIL PROTECTED] > > > Gesendet: Donnerstag, 16. November 2006 14:50 > > > An: [email protected] > > > 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 > > > > > > > >
