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 :)
