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: wicket-dev@incubator.apache.org
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
