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.
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.
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
...
