On Tue, Sep 20, 2011 at 1:11 PM, Korbinian Bachl - privat <[email protected]> wrote: > 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. 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. > >>> >>> 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? > > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
