On Tuesday, September 20, 2011 2:28 PM, "Korbinian Bachl - privat" <korbinian.ba...@whiskyworld.de> wrote: > > 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?
Than please just try to get beyond your rough idea into a design on paper. Start with a DOM-tree builder that computes a DOM-tree from all the template snippets that Wicket uses to generate pages, factor in repeaters, optional components etc. Than design models and algorithms to map that on Wickets component hierarchy, etc. Factor in client side changes and browser differences to the DOM-tree, and server side changes to component hierarchy. It's really not a bad idea to try to understand the implications of your rough idea. > > - 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? Yes I have, with pretty complicated designs as well with a lot of jQuery UI, layouts managed at the client side, etc. And this has never been a problem for me, while your proposal would give me headaches because I have to think about letting Wicket know how I'm changing the DOM-tree at the client side. My one and only gripe with the wicket-ajax stuff is the complicated way to render callbacks in javascript to server side functions. > > - Bugs in the user implementation are substantially harder to track than > > a forgotten setOutputMarkupId(true) in the current API. > > sure? Yes sure. A forgotten setOutputMarkupId(true) will trigger an exception when trying to add that component to an AjaxRequestTarget. That's pretty hard to miss, and the offending component is easy to locate from the exception. > > - 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.... Of course. It's also the reason I'm responding ;-). So far all API breaks in Wicket I've had to deal with were easy to migrate to. I can't see how your proposal can be incorporated in an evolutionary API design change. But feel free to prove me wrong. > > 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.... Sorry but I did read that. My response was for your proposal to manage a DOM-tree in wicket.
