Heya,
Am 20.09.11 11:37, schrieb Martin Grigorov:
...
Ok, well, wicket consists of components. So basically it is making a page
full of a tree with components. Wicket now could scan the component if it
has any Ajax on it - then auto add what it needs like the setOuput... - so
we got rid of this.
Consider this example:
Label label = new Label(...);
add(label);
AjaxLink link = new AjaxLink(id) {
public void onClick(ART target) {
label.setDefaultModelObject("something new");
target.add(label);
}
}
Now tell me how visiting 'label' or 'link' components you can
automatically extract that 'label' should have
.setOutputMarkupId(true) and set it ?
Visiting the components is fast but do you really want to traverse the
whole page (it can be a big component tree!) and waste CPU just
because you hate to add .setOutputMarkupId(true) where needed or
rolling your own AjaxLabel component which does this in its
constructor.
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.
Then the AjaxRequestTarget. Maybe its me but I find passing around this
thing all over more a headache then a help. Basically, what we do with ajax
is that we do it twice. Add it to page via .add and to target.addComponent -
so why? Because wicket differs between those scopes, even they are same in
the end (only question is: send the whole page or just a part to the
browser?).
So we really need to ask ourself why we need 2 things? If a page is changed
after beeing send to browser, don't we know automatically it is Ajaxified
when we get an ajax request? Can't the default request not behave
accordingly, so we can get rid of the whole AjaxRequestTarget? I mean the
whole wicket-ajax needs to be thought about.
Moving all this logic in Component#add(Component...) sounds scary...
How do you imagine target.appendJavaScript() to be implemented with
your approach? Just curious.
You missed me. I dont want to make Component another thousand lines
long, but instead rise the question why we follow the current approach
like the lemmings and not think about different ways to solve the
partial ajax updates. And also remember that current Ajax won't work on
certain elements - or easy spoken: as soon as we don't have our magic
ID's all goes down the flow.
Now if we say we only have a html manipulator thats based upon the DOM
tree instead we could get rid of half of the work by just telling the JS
lib:
element with path "div[2]>span[1]>table[0]" gets a new "tr[14]" with
code ...
or
element with path "div[2]>span[1]>table[0]" gets deleted/ swapped
"tr[9]" with code....
Imagine now that this would mean wicket can manipulate any element not
matter if the component behind is Ajaxified or not! Only thing to react
on would be the Request itself - if its Ajax or nonAjax, then construct
the pages and differ them internally (already mostly done yet as we have
a pagemap holding our old pages) and send the right answer to the
request, be it partial Ajax or Full page.
Or do you see a big problem in that idea?
