Hi,
On Tue, Sep 20, 2011 at 12:08 PM, Korbinian Bachl - privat
<[email protected]> wrote:
> Hi Martin,
>
> Am 20.09.11 09:59, schrieb Martin Grigorov:
> ...
>>>
>>> Well, I think there is consent that we can say current wicket ajax is
>>> quite
>>> broken and a big pain in everyday usage.
>>
>> Really? Is that broken ?
>> Neither mailing lists questions nor tickets prove that statement.
>>>
>>> The current ajax means loads of code in java for even trivial things.
>>> Triple-checking that a component knows its ajax and so on. So even *if*
>>> it
>>> will break api in future, I don't see a way around this!
>>>
>>> Do we want all those AjaxRequestTargets, .setOutput******(boolean) and
>>> more
>>> of this even here in some years? Don't think so.
>>
>> What do you suggest ?
>> The only option that I see as automatic is to set it for each and
>> every component, no matter whether it will be ever updated with Ajax
>> or not.
>
>
> 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.
>
> 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.
>
> Imagine that we could unite Link and AjaxLink and AjaxFallbackLink to just a
> general Link with a simple onClick() method and if you want ajax you just
> did link.actAsAjax(true);
>
> Wepapps are getting more and more dynamic and we need to look if we can't
> make it more a breeze to work with. Currently I love wicket and praise it
> when I work with traditional pages, but as soon as have more than one Ajax
> component on a page I start asking myself if I shouldn't dump it.
>
>>>
>>> The other question is now what to do (from a higher perspective):
>>>
>>> 1st: do it on own
>>> 2nd: use somebody else's work
>>>
>>> I would go for 2 and most specific go for a complete jQuery based wicket.
>>
>> This is clear.
>
> oh is it already? :)
>
>>> Reasons are:
>
> ...
>>
>> Not sure whether you invested some of your time to see what is needed
>> by wicket-ajax.js and what JQuery (or other major JS libs) offers but
>> my investigation showed that none of them solves the problem with
>> replaceOuterHtml() out of the box. So we will have to translate our
>> code in JQuery parlance but still will have to keep the "hacks".
>
> Well I tend to go from top to bottom, not vice versa. That "hacks" are
> needed (would more call it an adapter) is clear, but if you have 2 solid
> ends (wicket at one, jQuery at other) is quite more easy to plug them
> together then to dump one end because there maybe some hack (tm) at it. As I
> outlined above, I would like to ask if the current AjaxRequestTarget way is
> the way to go - that of course affects the rest like wicket-ajax.js;
>
> best
>
> ...
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
