Hi Matej, im not sure on this one. If every component may be hooked to a unique URL Part, then it wont matter at what location it is, would it?
I mean i use the bookmarkable system we have and just transfer it to the components. e.g: Component A = mounted to(/A) Component B = mounted to (/B) Component C = mounted to (/C) if a page now is called using /page/a/12/b/13 it knows that A gets a string "12" - but if a is not incorporated it does nothing - and if there is a component A it gets it - if there is A + B A gets 12, B 13, if there is only B it gets 13 - rest is just ignored, so why cant you switch then??? The hirarchy doesnt count, as it wouldnt matter to what A is linked as long as its any component The par with the map, is something i dont understand properly. What do you store in there ? And why does the instance count? Regards > -----Ursprüngliche Nachricht----- > Von: Matej Knopp [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 11. Oktober 2006 20:28 > An: [email protected] > Betreff: Re: AW: externalizing state by components > > I'm affraid something like this would not work, at least not > without major changes in Wicket. You're making assumption > that component hierarchy is static and predictable. But > that's not. Components on page can change. Every request you > can change component hierarchy. Therefore you need page id in > the request (page id is used to get page instance from page map). > > The state of page is more than just a couple of component > properties. It is the whole component structure. > > -Matej > > Korbinian Bachl wrote: > > Hi, > > > > i hope its ok to hok me in, even if im new to wicket and not one of > > the developers. > > > > I think i lead eelco this way, regarding nice URLs. > > > > With nice URLs you have following advantages: > > > > * Since all requests are routed through a single servlet > > (typically mapped to /app), J2EE declarative security, which is > > path-based, is defeated. > > * Ugly URLs tend to be longer than friendly URLs, which > can make a > > difference when creating a WML application. > > * A single directory may contain all the artifacts (HTML > > templates, specifications, properties files) for all the > pages in an > > entire application. There isn't a sanctioned approach to organizing > > things into subdirectories. > > * The reliance on query parameters means that common search > > engines will only see a tiny fraction of the application. > > > > Plus (!) the important security feature that your technology is not > > revealed to the outer world, making attacks on it mor difficult (if > > your url is > > > http://127.0.0.1:8080/WhiskyworldV6-war?wicket:interface=:0:pagination > > :navig ation:1:pageLink::ILinkListener its easy to know > that wicket is > > used, and its a JEE server then...) > > > > For me, the big question is > > > > a, why do we need state all time? - and if we have a state, > cant it be > > serialized ? (e.g: parameters?) b, if we neednt state all time, why > > cant this be translated to a nice link? > > > > at least, when wicket creates a link it has to know (!) > where it ends, > > meaning that it shouldnt be a difference if its used /link/a or > > ?wicket:interface=.... ending both in same actions. So, if wicket > > knows where the link goes to, and what it transports, why > cant this be > > formed well then? > > > > e.g: > > > > Page: Index > > has component: SearchfieldComp > > has component: FooterComp > > (footer has component UselessComp) > > > > we need nothing but a link to /Index > > > > if now UselessComp has a state like UselessThing is String > "thing" it > > could be a link to /Index/thing > > > > Why? because its the first thing in the URL after the > Index/ - and its > > the first thing the component would need and UselessComp gets it > > because its the first component that needs sth. > > > > if now SearchField also contains a String "Foo" it would then be: > > /Index/Foo/thing > > > > now we only have the problem that we dont know if wether > Searchfield > > gets Foo or thing (1st example) > > > > the soluton would be to encode the component name itself > and to give > > the developer the chance to alter this name e.g: same as we do with > > mount for pages, we could do this for Components > > > > e.g: > > Page: Index > > has component: SearchfieldComp (mounted to LOOK) has component: > > FooterComp (mounted to nothing as it never gets anything) > (footer has > > component UselessComp) (mounted to USELESS) > > > > -> solutionlink: /Index/LOOK/Foo/USELESS/thing > > > > this would be the key solution - if the wicket user needs > nice URL he > > gets the maximum possibility to alter the names if not, he > gets ugly > > URLs like before. > > > > This means, if we also provide names to components (the > ability) then > > we clould also unify bookmarkable link as well as link as > it wouldnt > > matter what kind we have, we would only check if all > components nested > > in that page have names, if not -> ugly URL, if they have > -> nice URL ! > > > > now, wouldnt this be a solution worth digging in??? > > > > Best Regards, > > > > Korbinian > > > > > >> -----Ursprüngliche Nachricht----- > >> Von: Eelco Hillenius [mailto:[EMAIL PROTECTED] > >> Gesendet: Mittwoch, 11. Oktober 2006 19:00 > >> An: [email protected] > >> Betreff: Re: externalizing state by components > >> > >> On 10/11/06, Frank Bille <[EMAIL PROTECTED]> wrote: > >>> But shouldn't the page be bookmarkable then? How else are > >> you going to > >>> make use of that externalized component? Except if I have > got your > >>> concept of "externalizing" wrong (= bookmarkable) > >> No this externalizable thing only means that 'state' is > being passed > >> as part of the URL. So an URL like this > >> > >> > http://localhost:8081/tsp/web?wicket:interface=_wf_component:1:10:1: > >> > >> could be something like > >> > >> http://localhost:8081/tsp/web?wicket:interface=_wf_component:1 > >> :10:1:&wicket:state=dfskajkladsjf676sdfa > >> > >> where that state is an encoded set of parameters. That > encoding could > >> be overridden to make them look nice (but less > >> efficient) on a component basis (ParameterUrlEncoder), so that it > >> could look like > >> > >> http://someserver/foo/bar/books/Brave_New_World > >> > >> Where books,Brave_New_World is what is contributed by the > component, > >> and points to a bookmarkable page mounted at /bar/books. > >> > >> Also: please note that I'm still thinking about this. It would be > >> more helpful to think with me how we could pull this off, > then to try > >> to find things why it couldn't work. IMO, if we can > implement this, > >> it would be a huge potential improvement in our scalability and > >> bookmarkability options. > >> > >> Eelco > >> > > > > > >
