Whats the primary advantage of using relative URLs in the first place? Jörn
On Thu, Oct 16, 2008 at 4:58 PM, Johan Compagner <[EMAIL PROTECTED]> wrote: > Hi, > > i am fishing for some idea's because i have a problem that i dont see a > solution at this time > > What happens is that we show 2 modal dialogs at once so 1 modal shows > another modal again. > > This works fine with normal urls but if somehow the pages in the modal > dialogs are bookmarkable (hybrid encoding like that) > then in IE it goes wrong because in IE the second modal dialog url that > wicket generates is without and ../../ because wicket > sees that it comes from the first modal dialog that doesnt have a deep path > > But the url in the browser is also a bookmarkable url with some params. and > that does have a path like /x/y/z > So the first modal dialog does generate something like ../../mymodaldialog.1 > (hybrid) > > but the second modal dialog does generate mymodaldialog.2 > > but IE then doesnt use the src url of the first modal dialog but the url of > the real browser window so the /x/y/z > what happens then that you get something like: > > x/y/mymodaldialog.2 which is a mounted/bookmarkable url of 2 pages > combined.. which wicket cant resolve ofcourse. > > So this is an area where the relative url behavior that wicket has really > bites me because i have no idea where the to fix that (and it is IE specific > FF does it correctly) > on the server we dont have enough info of the real url browser > on the client we dont really have enough info again what really is the > context root and that kind of stuff. > > so for this modal dialog problem we shoud almost really generate the full > url so starting with an /context/path/x > > any idea's how to fix this? > > johan >
