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. - 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). - Bugs in the user implementation are substantially harder to track than a forgotten setOutputMarkupId(true) in the current API. - This will break existing API functionality and code in a big way.
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... On Tuesday, September 20, 2011 12:52 PM, "Korbinian Bachl - privat" <[email protected]> wrote: > > > Am 20.09.11 12:30, schrieb Martin Grigorov: > > On Tue, Sep 20, 2011 at 1:11 PM, Korbinian Bachl - privat > > <[email protected]> wrote: > ... > >> > >> Wrong approach IMHO. The question is: Do we need outprinted Id's to find an > >> element in DOM? > >> Answer is: No, we don't as long as we know the path (!). Funnywise this > >> path > >> is the same path wicket builds and traverses during its rendering phase. > > This relies on a great assumption: the user application MUST do any > > DOM manipulations thru Wicket, even simple effects or client side > > validation for faster feedback. Because if you add a simple<span> > > just to show something that shouldn't update the server side state > > then you cant rely anymore that Wicket will be able to find your > > components from there on. > > > > Another problem is that querySelector() is fastest when looking up by > > id. Everything else becomes slower depending on the size of the DOM > > tree. > > These are valid points. Question is if there is only the "real" path or > not. Possible ways would be to use DOM from an somewhere present ID, > limiting the OutputMarkupID to as few places as possible and still > allowing traversal from that point and this manipulation of DOM parts > that are not even existing (think of repeaters). > > This would mean in default we have a "null" ID that is the page itself, > while when the dev wants to finger around using third party JS he could > specify an ID that is relative to the wicket part he wants to wicket to > manipulate while the rest outside wont make differences. > > e.g.: > > divA>divB>divC > > he now wants to transform divB using another JS framework > > he only needs to specify wicket's JS id on element divC if he wants > wicket to manipulate this as divA is still reachable from page level > > This way we also can introduce new content at places where it hasn't > been and finally solve the repeater and ajax issues; > > Regarding the speed: I'm not sure that its so dramatic in the end and > see it as solvable in the end when we hit sth. (remember: premature > optimization is evil); > > my2c :) >
