On 11/16/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> 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. ok if this is your way as implementors of the framework our primary concern is to make sure our api is clear for our users. sometimes this means stripping things that we later realize can be confusing or have a high chance of being error-prone when used. - im not discussing this item anyonger, ill use a own implementation and
thats it...
our secondary concern is to leave enough hooks/flexibility in the api so our users can customize the existing default functionality but dont wonder if more
people complain if you strip out existent functionality...
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. 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. -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 >
