Am 20.09.11 13:11, schrieb Pointbreak:
I'm completely agreeing with Martin on this one. The things you are
suggesting imho have the following consequences:
- Wicket implementation becomes way more complicated, because Wicket has
to translate between component hierarchy and browser DOM-tree, which is
non-trivial, and requires a lot of extra server side processing.
just a rough idea and not a single implementation yet but we know how
hard it is to compute?
- User implementation becomes substantially more complicated because one
way or another, the user has to give hints to Wicket how eventual
client-side javascripts not managed by wicket are manipulating the
DOM-tree (which by the way is easy to break between browsers, as
DOM-trees for the same HTML may differ substantially between browsers).
thats a problem either way - ever tried to integrate third party JS with
wicket?
- Bugs in the user implementation are substantially harder to track than
a forgotten setOutputMarkupId(true) in the current API.
sure?
- This will break existing API functionality and code in a big way.
thats the reason were talking about wicket.next and not wicket.now - and
api breaks will at some point come else wicket can't go forward....
And all that for not having a few extra setOutputMarkupId(true) calls?
If setOutputmarkupId bothers you that much, it's easy to write a visitor
that just calls it for all your components...
now honestly - thanks for not ready anything in the long posts before;
the reason why I'd favor such a thing is that it makes wicket able to
ajaxify *any* component. Current ajax won't work on all current core
components - thats it. There is a reason why Martin wanted to completely
rewrite wicket ajax a time back and it wasn't that he had too much
leisure time....
