You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martin Grigorov <mg...@apache.org> on 2011/09/19 17:29:27 UTC
Ajax in Wicket.next
Hi,
In the recent ticket changes by Igor I mentioned few comments that
Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
call it).
I want to share my experience with trying to re-vive Matej's work at [1], [2].
The changes there are a bit drastic (maybe because the task hasn't
been finished and the API breaks not cleaned) and knowing how Ajax
heavy are the applications I've worked on I think it will be quite a
work to migrate the apps from 1.5 to Wicket.next.
I also tried to introduce wicket-ajax.jar with the new impl and keep
the old one for transition but that wasn't easy too.
So I want to propose a two step approach:
1) introduce some JavaScript library for Wicket.next and improve
wicket-xyz.js files by using it
2) improve/reimplement Wicket Ajax for Wicket.next+1
martin-g
1. http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
2. https://github.com/martin-g/wicket/tree/ajax2
Re: Ajax in Wicket.next
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Sep 19, 2011 at 7:11 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> staged approach is fine, however its step 2 only that will cause
> migration headaches, so this is just delaying the inevitable...
Matej's work is re-work both of client and server side and I think it
will take some time to implement and stabilize.
I don't want Wicket.next to take long period as 1.5...
It depends what other new features will be planned for Wicket.next
>
> -igor
>
>
> On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov <mg...@apache.org> wrote:
>> Hi,
>>
>> In the recent ticket changes by Igor I mentioned few comments that
>> Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
>> call it).
>>
>> I want to share my experience with trying to re-vive Matej's work at [1], [2].
>> The changes there are a bit drastic (maybe because the task hasn't
>> been finished and the API breaks not cleaned) and knowing how Ajax
>> heavy are the applications I've worked on I think it will be quite a
>> work to migrate the apps from 1.5 to Wicket.next.
>> I also tried to introduce wicket-ajax.jar with the new impl and keep
>> the old one for transition but that wasn't easy too.
>>
>> So I want to propose a two step approach:
>> 1) introduce some JavaScript library for Wicket.next and improve
>> wicket-xyz.js files by using it
>> 2) improve/reimplement Wicket Ajax for Wicket.next+1
>>
>>
>> martin-g
>>
>> 1. http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
>> 2. https://github.com/martin-g/wicket/tree/ajax2
>>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: Ajax in Wicket.next
Posted by Frank van Lankvelt <fr...@a-eskwadraat.nl>.
On 20 sep. 2011, at 19:12, Juliano Viana <ju...@logicstyle.com> wrote:
> Hi,
>
> I have been following this discussion and I think its not fair to call
> Wicket Ajax support broken.
> I started using Wicket back in 2007, and the environment then was:
>
> - Support for IE 6 was a must.
> - JavaScript on the browser was still slow and unreliable
> - The applications where designed to work mostly with standard HTTP
> request/replies, with only some specific functionalities being implemented
> in Ajax.
>
> Since then the web has evolved a lot - IE 6 is dead (or dying), Google
> Chrome raised the bar for the JavaScript engines and most modern browsers
> now support WebSockets for low latency communications. We are now at the
> point where some people are deciding not to use a web framework at all, and
> rely instead on JavaScript plus RESTful web services (Google Plus is an
> example of such an architecture).
>
> Wicket is still very good at what it does, specially considering the
> environment in which it evolved. I personally dont think the API is an
> issue - every API is a compromise and once you learn to live within its
> limitations there is very little you can't do with Wicket Ajax one way or
> another.
>
> The issue I see is: there is a lot of opportunity for making applications a
> lot more interactive by moving processing to the browser. GWT does that by
> compiling Java into JavaScript, but my latest experiences with JavaScript
> have convinced me that this step is probably unnecessary - you can be pretty
> confident that once you use a framework like JQuery your code will run
> unmodified in the major web browsers. The only thing that is not so easy to
> do is to interact with the server-side state.
>
> This is where I believe improvements can be made - enabling JavaScript to
> interact easily with Wicket models and listeners. This would make it
> easier to write more compelling user interfaces by leveraging current and
> future JS frameworks while preserving the Wicket component and model
> structure, which is in my oppinion Wicket's strongest point.
>
Hear, hear!
With the server-side events now in place, would the next step be to expose them to the client? I think this would open up some nice possibilities where wicket ajax acts as the event hub.
One thing that i've run into a few times was the need to hook an ajax call. I've needed to put in synchronous calls. It would be a lot better to (async) execute them before the original call. (restrictions such as skipping the render phase would be acceptable)
Continuing the theme, server-push of updates would be nice-to-have imo. I don't know if it can/should be integrated with component rendering though.
Another thing is splitting the action and render phase further. I've been pretty satisfied with separate action, (external) event processing and render phases.
Cheers, Frank
> Regards,
> - Juliano.
Re: Ajax in Wicket.next
Posted by Martin Grigorov <mg...@apache.org>.
On Wed, Sep 21, 2011 at 2:43 AM, Ben Tilford <be...@tilford.info> wrote:
> With the js framework suggestions I havn't seen anyone mention a module
> system like require.js this would be something I'd wan't to see used. If
> something like jQuery gets included without a module system it would only be
> a matter of time until jQuery.next was released and someone wants to use it.
> A module system would allow the app developer to specify dependency versions
> without causing conflicts with those provided by the library (Wicket).
Actually I did mention it earlier in this thread. Search for CommonJS/AMD.
Even if we choose JQuery (this is the decision for now) we will allow
to load custom ResourceReference.
This way Wicket may come with version X of the JS library and the user
will be able to do something like:
getAjaxSettings().setJSReference(new
PackageResourceReference(SomeUserClass.class, "jquery-X+1.min.js"))
If we do the same for wicket-ajax.js then there is no need to use an
adapter as I suggested in the same mail earlier.
This way the user may use YUI instead with its own impl of
wicket-ajax.js (e.g. translation from JQuery to YUI)
>
>
> On Tue, Sep 20, 2011 at 12:59 PM, Dan Retzlaff <dr...@gmail.com> wrote:
>
>> Well said, Juliano! Thanks for your contribution.
>>
>> In my experience the awkward parts of interacting with JS/JQuery objects
>> from Wicket are
>> 1. Converting model objects to/from JS strings
>> 2. Invoking JS initialization functions (with data arguments) at the right
>> time, i.e. when a certain Wicket component get (re)rendered.
>> 3. Keeping track of server-side behavior callback URLs, and invoking them
>> with additional parameters from within JS functions.
>>
>> As has been said, there's nothing particularly hard about these, but in the
>> end there tends to be more boiler plate than business.
>>
>> Re #1, Wicket has a nice IConverter framework for object/string marshalling
>> used mostly by FormComponents. Maybe this could be leveraged to push/pull
>> model values to/from JavaScript without explicit application code.
>>
>> Re #2, what if components could be told to export their model values into
>> the DOM, and the value were accessible through something like
>> http://api.jquery.com/data/? Then a normal (anonymous) dom/document ready
>> event handler can be used to init the JS world without additional Java.
>>
>> Re #3, maybe the Wicket JS API can include a way to initiate a request,
>> similar to form submit, to push new values back to the server. The main
>> difference with actual form submit is that you needn't have <form> and
>> <input> tags and wicket:ids; the existing components and their models are
>> sufficient. This may be a naive suggestion, though, since most of the form
>> validation process would still need to apply, and need to be customizable
>> per component / model object.
>>
>> Just a few suggestions. Please don't pull your punches tearing them down.
>> :)
>>
>> Dan
>>
>> On Tue, Sep 20, 2011 at 10:12 AM, Juliano Viana <juliano@logicstyle.com
>> >wrote:
>>
>> > Hi,
>> >
>> > I have been following this discussion and I think its not fair to call
>> > Wicket Ajax support broken.
>> > I started using Wicket back in 2007, and the environment then was:
>> >
>> > - Support for IE 6 was a must.
>> > - JavaScript on the browser was still slow and unreliable
>> > - The applications where designed to work mostly with standard HTTP
>> > request/replies, with only some specific functionalities being
>> implemented
>> > in Ajax.
>> >
>> > Since then the web has evolved a lot - IE 6 is dead (or dying), Google
>> > Chrome raised the bar for the JavaScript engines and most modern browsers
>> > now support WebSockets for low latency communications. We are now at the
>> > point where some people are deciding not to use a web framework at all,
>> and
>> > rely instead on JavaScript plus RESTful web services (Google Plus is an
>> > example of such an architecture).
>> >
>> > Wicket is still very good at what it does, specially considering the
>> > environment in which it evolved. I personally dont think the API is an
>> > issue - every API is a compromise and once you learn to live within its
>> > limitations there is very little you can't do with Wicket Ajax one way or
>> > another.
>> >
>> > The issue I see is: there is a lot of opportunity for making applications
>> a
>> > lot more interactive by moving processing to the browser. GWT does that
>> by
>> > compiling Java into JavaScript, but my latest experiences with JavaScript
>> > have convinced me that this step is probably unnecessary - you can be
>> > pretty
>> > confident that once you use a framework like JQuery your code will run
>> > unmodified in the major web browsers. The only thing that is not so easy
>> to
>> > do is to interact with the server-side state.
>> >
>> > This is where I believe improvements can be made - enabling JavaScript to
>> > interact easily with Wicket models and listeners. This would make it
>> > easier to write more compelling user interfaces by leveraging current and
>> > future JS frameworks while preserving the Wicket component and model
>> > structure, which is in my oppinion Wicket's strongest point.
>> >
>> > Regards,
>> > - Juliano.
>> >
>>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: Ajax in Wicket.next
Posted by Brian Topping <to...@codehaus.org>.
Yep, this is really important.
A bit of a rhetorical question: Why not design wicket.next with modularity as a first-class requirement?
On Sep 20, 2011, at 7:43 PM, Ben Tilford wrote:
> With the js framework suggestions I havn't seen anyone mention a module
> system like require.js this would be something I'd wan't to see used. If
> something like jQuery gets included without a module system it would only be
> a matter of time until jQuery.next was released and someone wants to use it.
> A module system would allow the app developer to specify dependency versions
> without causing conflicts with those provided by the library (Wicket).
>
>
> On Tue, Sep 20, 2011 at 12:59 PM, Dan Retzlaff <dr...@gmail.com> wrote:
>
>> Well said, Juliano! Thanks for your contribution.
>>
>> In my experience the awkward parts of interacting with JS/JQuery objects
>> from Wicket are
>> 1. Converting model objects to/from JS strings
>> 2. Invoking JS initialization functions (with data arguments) at the right
>> time, i.e. when a certain Wicket component get (re)rendered.
>> 3. Keeping track of server-side behavior callback URLs, and invoking them
>> with additional parameters from within JS functions.
>>
>> As has been said, there's nothing particularly hard about these, but in the
>> end there tends to be more boiler plate than business.
>>
>> Re #1, Wicket has a nice IConverter framework for object/string marshalling
>> used mostly by FormComponents. Maybe this could be leveraged to push/pull
>> model values to/from JavaScript without explicit application code.
>>
>> Re #2, what if components could be told to export their model values into
>> the DOM, and the value were accessible through something like
>> http://api.jquery.com/data/? Then a normal (anonymous) dom/document ready
>> event handler can be used to init the JS world without additional Java.
>>
>> Re #3, maybe the Wicket JS API can include a way to initiate a request,
>> similar to form submit, to push new values back to the server. The main
>> difference with actual form submit is that you needn't have <form> and
>> <input> tags and wicket:ids; the existing components and their models are
>> sufficient. This may be a naive suggestion, though, since most of the form
>> validation process would still need to apply, and need to be customizable
>> per component / model object.
>>
>> Just a few suggestions. Please don't pull your punches tearing them down.
>> :)
>>
>> Dan
>>
>> On Tue, Sep 20, 2011 at 10:12 AM, Juliano Viana <juliano@logicstyle.com
>>> wrote:
>>
>>> Hi,
>>>
>>> I have been following this discussion and I think its not fair to call
>>> Wicket Ajax support broken.
>>> I started using Wicket back in 2007, and the environment then was:
>>>
>>> - Support for IE 6 was a must.
>>> - JavaScript on the browser was still slow and unreliable
>>> - The applications where designed to work mostly with standard HTTP
>>> request/replies, with only some specific functionalities being
>> implemented
>>> in Ajax.
>>>
>>> Since then the web has evolved a lot - IE 6 is dead (or dying), Google
>>> Chrome raised the bar for the JavaScript engines and most modern browsers
>>> now support WebSockets for low latency communications. We are now at the
>>> point where some people are deciding not to use a web framework at all,
>> and
>>> rely instead on JavaScript plus RESTful web services (Google Plus is an
>>> example of such an architecture).
>>>
>>> Wicket is still very good at what it does, specially considering the
>>> environment in which it evolved. I personally dont think the API is an
>>> issue - every API is a compromise and once you learn to live within its
>>> limitations there is very little you can't do with Wicket Ajax one way or
>>> another.
>>>
>>> The issue I see is: there is a lot of opportunity for making applications
>> a
>>> lot more interactive by moving processing to the browser. GWT does that
>> by
>>> compiling Java into JavaScript, but my latest experiences with JavaScript
>>> have convinced me that this step is probably unnecessary - you can be
>>> pretty
>>> confident that once you use a framework like JQuery your code will run
>>> unmodified in the major web browsers. The only thing that is not so easy
>> to
>>> do is to interact with the server-side state.
>>>
>>> This is where I believe improvements can be made - enabling JavaScript to
>>> interact easily with Wicket models and listeners. This would make it
>>> easier to write more compelling user interfaces by leveraging current and
>>> future JS frameworks while preserving the Wicket component and model
>>> structure, which is in my oppinion Wicket's strongest point.
>>>
>>> Regards,
>>> - Juliano.
>>>
>>
Re: Ajax in Wicket.next
Posted by Ben Tilford <be...@tilford.info>.
With the js framework suggestions I havn't seen anyone mention a module
system like require.js this would be something I'd wan't to see used. If
something like jQuery gets included without a module system it would only be
a matter of time until jQuery.next was released and someone wants to use it.
A module system would allow the app developer to specify dependency versions
without causing conflicts with those provided by the library (Wicket).
On Tue, Sep 20, 2011 at 12:59 PM, Dan Retzlaff <dr...@gmail.com> wrote:
> Well said, Juliano! Thanks for your contribution.
>
> In my experience the awkward parts of interacting with JS/JQuery objects
> from Wicket are
> 1. Converting model objects to/from JS strings
> 2. Invoking JS initialization functions (with data arguments) at the right
> time, i.e. when a certain Wicket component get (re)rendered.
> 3. Keeping track of server-side behavior callback URLs, and invoking them
> with additional parameters from within JS functions.
>
> As has been said, there's nothing particularly hard about these, but in the
> end there tends to be more boiler plate than business.
>
> Re #1, Wicket has a nice IConverter framework for object/string marshalling
> used mostly by FormComponents. Maybe this could be leveraged to push/pull
> model values to/from JavaScript without explicit application code.
>
> Re #2, what if components could be told to export their model values into
> the DOM, and the value were accessible through something like
> http://api.jquery.com/data/? Then a normal (anonymous) dom/document ready
> event handler can be used to init the JS world without additional Java.
>
> Re #3, maybe the Wicket JS API can include a way to initiate a request,
> similar to form submit, to push new values back to the server. The main
> difference with actual form submit is that you needn't have <form> and
> <input> tags and wicket:ids; the existing components and their models are
> sufficient. This may be a naive suggestion, though, since most of the form
> validation process would still need to apply, and need to be customizable
> per component / model object.
>
> Just a few suggestions. Please don't pull your punches tearing them down.
> :)
>
> Dan
>
> On Tue, Sep 20, 2011 at 10:12 AM, Juliano Viana <juliano@logicstyle.com
> >wrote:
>
> > Hi,
> >
> > I have been following this discussion and I think its not fair to call
> > Wicket Ajax support broken.
> > I started using Wicket back in 2007, and the environment then was:
> >
> > - Support for IE 6 was a must.
> > - JavaScript on the browser was still slow and unreliable
> > - The applications where designed to work mostly with standard HTTP
> > request/replies, with only some specific functionalities being
> implemented
> > in Ajax.
> >
> > Since then the web has evolved a lot - IE 6 is dead (or dying), Google
> > Chrome raised the bar for the JavaScript engines and most modern browsers
> > now support WebSockets for low latency communications. We are now at the
> > point where some people are deciding not to use a web framework at all,
> and
> > rely instead on JavaScript plus RESTful web services (Google Plus is an
> > example of such an architecture).
> >
> > Wicket is still very good at what it does, specially considering the
> > environment in which it evolved. I personally dont think the API is an
> > issue - every API is a compromise and once you learn to live within its
> > limitations there is very little you can't do with Wicket Ajax one way or
> > another.
> >
> > The issue I see is: there is a lot of opportunity for making applications
> a
> > lot more interactive by moving processing to the browser. GWT does that
> by
> > compiling Java into JavaScript, but my latest experiences with JavaScript
> > have convinced me that this step is probably unnecessary - you can be
> > pretty
> > confident that once you use a framework like JQuery your code will run
> > unmodified in the major web browsers. The only thing that is not so easy
> to
> > do is to interact with the server-side state.
> >
> > This is where I believe improvements can be made - enabling JavaScript to
> > interact easily with Wicket models and listeners. This would make it
> > easier to write more compelling user interfaces by leveraging current and
> > future JS frameworks while preserving the Wicket component and model
> > structure, which is in my oppinion Wicket's strongest point.
> >
> > Regards,
> > - Juliano.
> >
>
Re: Ajax in Wicket.next
Posted by Dan Retzlaff <dr...@gmail.com>.
Well said, Juliano! Thanks for your contribution.
In my experience the awkward parts of interacting with JS/JQuery objects
from Wicket are
1. Converting model objects to/from JS strings
2. Invoking JS initialization functions (with data arguments) at the right
time, i.e. when a certain Wicket component get (re)rendered.
3. Keeping track of server-side behavior callback URLs, and invoking them
with additional parameters from within JS functions.
As has been said, there's nothing particularly hard about these, but in the
end there tends to be more boiler plate than business.
Re #1, Wicket has a nice IConverter framework for object/string marshalling
used mostly by FormComponents. Maybe this could be leveraged to push/pull
model values to/from JavaScript without explicit application code.
Re #2, what if components could be told to export their model values into
the DOM, and the value were accessible through something like
http://api.jquery.com/data/? Then a normal (anonymous) dom/document ready
event handler can be used to init the JS world without additional Java.
Re #3, maybe the Wicket JS API can include a way to initiate a request,
similar to form submit, to push new values back to the server. The main
difference with actual form submit is that you needn't have <form> and
<input> tags and wicket:ids; the existing components and their models are
sufficient. This may be a naive suggestion, though, since most of the form
validation process would still need to apply, and need to be customizable
per component / model object.
Just a few suggestions. Please don't pull your punches tearing them down. :)
Dan
On Tue, Sep 20, 2011 at 10:12 AM, Juliano Viana <ju...@logicstyle.com>wrote:
> Hi,
>
> I have been following this discussion and I think its not fair to call
> Wicket Ajax support broken.
> I started using Wicket back in 2007, and the environment then was:
>
> - Support for IE 6 was a must.
> - JavaScript on the browser was still slow and unreliable
> - The applications where designed to work mostly with standard HTTP
> request/replies, with only some specific functionalities being implemented
> in Ajax.
>
> Since then the web has evolved a lot - IE 6 is dead (or dying), Google
> Chrome raised the bar for the JavaScript engines and most modern browsers
> now support WebSockets for low latency communications. We are now at the
> point where some people are deciding not to use a web framework at all, and
> rely instead on JavaScript plus RESTful web services (Google Plus is an
> example of such an architecture).
>
> Wicket is still very good at what it does, specially considering the
> environment in which it evolved. I personally dont think the API is an
> issue - every API is a compromise and once you learn to live within its
> limitations there is very little you can't do with Wicket Ajax one way or
> another.
>
> The issue I see is: there is a lot of opportunity for making applications a
> lot more interactive by moving processing to the browser. GWT does that by
> compiling Java into JavaScript, but my latest experiences with JavaScript
> have convinced me that this step is probably unnecessary - you can be
> pretty
> confident that once you use a framework like JQuery your code will run
> unmodified in the major web browsers. The only thing that is not so easy to
> do is to interact with the server-side state.
>
> This is where I believe improvements can be made - enabling JavaScript to
> interact easily with Wicket models and listeners. This would make it
> easier to write more compelling user interfaces by leveraging current and
> future JS frameworks while preserving the Wicket component and model
> structure, which is in my oppinion Wicket's strongest point.
>
> Regards,
> - Juliano.
>
Re: Ajax in Wicket.next
Posted by Juliano Viana <ju...@logicstyle.com>.
Hi,
I have been following this discussion and I think its not fair to call
Wicket Ajax support broken.
I started using Wicket back in 2007, and the environment then was:
- Support for IE 6 was a must.
- JavaScript on the browser was still slow and unreliable
- The applications where designed to work mostly with standard HTTP
request/replies, with only some specific functionalities being implemented
in Ajax.
Since then the web has evolved a lot - IE 6 is dead (or dying), Google
Chrome raised the bar for the JavaScript engines and most modern browsers
now support WebSockets for low latency communications. We are now at the
point where some people are deciding not to use a web framework at all, and
rely instead on JavaScript plus RESTful web services (Google Plus is an
example of such an architecture).
Wicket is still very good at what it does, specially considering the
environment in which it evolved. I personally dont think the API is an
issue - every API is a compromise and once you learn to live within its
limitations there is very little you can't do with Wicket Ajax one way or
another.
The issue I see is: there is a lot of opportunity for making applications a
lot more interactive by moving processing to the browser. GWT does that by
compiling Java into JavaScript, but my latest experiences with JavaScript
have convinced me that this step is probably unnecessary - you can be pretty
confident that once you use a framework like JQuery your code will run
unmodified in the major web browsers. The only thing that is not so easy to
do is to interact with the server-side state.
This is where I believe improvements can be made - enabling JavaScript to
interact easily with Wicket models and listeners. This would make it
easier to write more compelling user interfaces by leveraging current and
future JS frameworks while preserving the Wicket component and model
structure, which is in my oppinion Wicket's strongest point.
Regards,
- Juliano.
Re: Ajax in Wicket.next
Posted by Bruno Borges <br...@gmail.com>.
If you are playing with Scala, and don't want to use the
instantiationListener because not all of your components are to be
ajaxified, you can then do:
object field1 extends TextField("field1") with AjaxReady
object field2 extends TextField("field2") with AjaxReady
object field3 extends TextField("field3") with AjaxReady
Or
var field1 = new TextField("field1) with AjaxReady
And here's the trait:
trait AjaxReady {
self: MarkupContainer
override def onInitialize() {
super.onInitialize();
setOutputMarkupId(true);
setOutputMarkupPlaceholderTag(true);
}
}
*Bruno Borges*
(21) 7672-7099
*www.brunoborges.com*
On Tue, Sep 20, 2011 at 1:23 PM, Igor Vaynberg <ig...@gmail.com>wrote:
> On Tue, Sep 20, 2011 at 12:53 AM, Korbinian Bachl - privat
> <ko...@whiskyworld.de> wrote:
> > tetsu, ever tried to:
> >
> > - get an AjaxRequestTarget in a component that was not designed by ajax
> in
> > mind?
>
> AjaxRequestTarget.get()
>
> >
> > - tried to ajaxify a table-row in a dataTable component?
>
> new datatable() { new item() { return super.item().setoutputmarkupid(true);
> }
>
> > - tried ajax with repeaters?
>
> target.addcomponent(repeater.getparent());
>
> > - tried to interact with a modal window from inside in case you have a
> pure
> > non-ajax page within it?
>
> window.opener.<whatever modal func you need>
>
> > of even
> >
> > - got tired with the verbose .setOut... .setMark... true?
>
> use instantiation listener to enable it on everything
>
> > - wondered why my ajaxified component got more lines of code then the
> rest
> > of the page?
>
> no, i dont wonder about *your* ajaxified components :)
>
> -igor
>
>
> >
> >
> >
> >
> > Am 19.09.11 19:20, schrieb tetsuo:
> >>
> >> What is so broken about the current ajax in Wicket, that requires such
> >> rewrite?
> >>
> >>
> >>
> >> On Mon, Sep 19, 2011 at 1:11 PM, Igor
> >> Vaynberg<ig...@gmail.com>wrote:
> >>
> >>> staged approach is fine, however its step 2 only that will cause
> >>> migration headaches, so this is just delaying the inevitable...
> >>>
> >>> -igor
> >>>
> >>>
> >>> On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov<mg...@apache.org>
> >>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> In the recent ticket changes by Igor I mentioned few comments that
> >>>> Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
> >>>> call it).
> >>>>
> >>>> I want to share my experience with trying to re-vive Matej's work at
> >>>> [1],
> >>>
> >>> [2].
> >>>>
> >>>> The changes there are a bit drastic (maybe because the task hasn't
> >>>> been finished and the API breaks not cleaned) and knowing how Ajax
> >>>> heavy are the applications I've worked on I think it will be quite a
> >>>> work to migrate the apps from 1.5 to Wicket.next.
> >>>> I also tried to introduce wicket-ajax.jar with the new impl and keep
> >>>> the old one for transition but that wasn't easy too.
> >>>>
> >>>> So I want to propose a two step approach:
> >>>> 1) introduce some JavaScript library for Wicket.next and improve
> >>>> wicket-xyz.js files by using it
> >>>> 2) improve/reimplement Wicket Ajax for Wicket.next+1
> >>>>
> >>>>
> >>>> martin-g
> >>>>
> >>>> 1.
> >>>
> >>>
> >>>
> http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
> >>>>
> >>>> 2. https://github.com/martin-g/wicket/tree/ajax2
> >>>>
> >>>
> >>
> >
>
Re: Ajax in Wicket.next
Posted by Igor Vaynberg <ig...@gmail.com>.
On Tue, Sep 20, 2011 at 12:53 AM, Korbinian Bachl - privat
<ko...@whiskyworld.de> wrote:
> tetsu, ever tried to:
>
> - get an AjaxRequestTarget in a component that was not designed by ajax in
> mind?
AjaxRequestTarget.get()
>
> - tried to ajaxify a table-row in a dataTable component?
new datatable() { new item() { return super.item().setoutputmarkupid(true); }
> - tried ajax with repeaters?
target.addcomponent(repeater.getparent());
> - tried to interact with a modal window from inside in case you have a pure
> non-ajax page within it?
window.opener.<whatever modal func you need>
> of even
>
> - got tired with the verbose .setOut... .setMark... true?
use instantiation listener to enable it on everything
> - wondered why my ajaxified component got more lines of code then the rest
> of the page?
no, i dont wonder about *your* ajaxified components :)
-igor
>
>
>
>
> Am 19.09.11 19:20, schrieb tetsuo:
>>
>> What is so broken about the current ajax in Wicket, that requires such
>> rewrite?
>>
>>
>>
>> On Mon, Sep 19, 2011 at 1:11 PM, Igor
>> Vaynberg<ig...@gmail.com>wrote:
>>
>>> staged approach is fine, however its step 2 only that will cause
>>> migration headaches, so this is just delaying the inevitable...
>>>
>>> -igor
>>>
>>>
>>> On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov<mg...@apache.org>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> In the recent ticket changes by Igor I mentioned few comments that
>>>> Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
>>>> call it).
>>>>
>>>> I want to share my experience with trying to re-vive Matej's work at
>>>> [1],
>>>
>>> [2].
>>>>
>>>> The changes there are a bit drastic (maybe because the task hasn't
>>>> been finished and the API breaks not cleaned) and knowing how Ajax
>>>> heavy are the applications I've worked on I think it will be quite a
>>>> work to migrate the apps from 1.5 to Wicket.next.
>>>> I also tried to introduce wicket-ajax.jar with the new impl and keep
>>>> the old one for transition but that wasn't easy too.
>>>>
>>>> So I want to propose a two step approach:
>>>> 1) introduce some JavaScript library for Wicket.next and improve
>>>> wicket-xyz.js files by using it
>>>> 2) improve/reimplement Wicket Ajax for Wicket.next+1
>>>>
>>>>
>>>> martin-g
>>>>
>>>> 1.
>>>
>>>
>>> http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
>>>>
>>>> 2. https://github.com/martin-g/wicket/tree/ajax2
>>>>
>>>
>>
>
Re: Ajax in Wicket.next
Posted by tetsuo <ro...@gmail.com>.
>
> tetsu, ever tried to:
>
It's tetsu*o*.
> - get an AjaxRequestTarget in a component that was not designed by ajax in
> mind?
>
Yes, and it works pretty well. I can't really remember a single case that I
couldn't do what I wanted to do. Sometimes I had to do it in a different way
than I tried to do first, but it always ends up working.
- tried to ajaxify a table-row in a dataTable component?
>
I don't know, probably. I do remember trying to ajax-refreshing treetable (a
third-party, not the built-in one) rows, and it did work. I think I had to
do something like target.add(getParent().getParent()). Not the most
beautiful thing in the world, but it worked.
- tried ajax with repeaters?
>
Yes, the way it is supposed to be done, refreshing its parent container, or
the items individually.
- tried to interact with a modal window from inside in case you have a pure
> non-ajax page within it?
>
With iframes? I think it works ok, unless you are trying to do it
cross-domain, which isn't allowed by the browser, not by Wicket.
> of even
>
> - got tired with the verbose .setOut... .setMark... true?
>
No, because I use a ComponentInstantiationListener to call
.setOutputMarkupId(true) in all components.
- wondered why my ajaxified component got more lines of code then the rest
> of the page?
>
Maybe because your ajaxified components are much more complex than mine?
Maybe because you don't know what you are doing? My ajaxified pages are
usually very, very similar to the non-ajaxified ones.
Wicket's ajax support is the best I've ever seen in any framework. It's
simple, it's direct, it's intuitive, it's easy to use. Maybe the internals
are fragile or messy, then it needs some refactoring. Maybe some things
aren't possible (that is what I asked, because I haven't hit any of those
cases), but it has always worked brilliantly for me.
But it's definitely not broken.
>
>
>
> Am 19.09.11 19:20, schrieb tetsuo:
>
> What is so broken about the current ajax in Wicket, that requires such
>> rewrite?
>>
>>
Re: Ajax in Wicket.next
Posted by Korbinian Bachl - privat <ko...@whiskyworld.de>.
tetsu, ever tried to:
- get an AjaxRequestTarget in a component that was not designed by ajax
in mind?
- tried to ajaxify a table-row in a dataTable component?
- tried ajax with repeaters?
- tried to interact with a modal window from inside in case you have a
pure non-ajax page within it?
of even
- got tired with the verbose .setOut... .setMark... true?
- wondered why my ajaxified component got more lines of code then the
rest of the page?
Am 19.09.11 19:20, schrieb tetsuo:
> What is so broken about the current ajax in Wicket, that requires such
> rewrite?
>
>
>
> On Mon, Sep 19, 2011 at 1:11 PM, Igor Vaynberg<ig...@gmail.com>wrote:
>
>> staged approach is fine, however its step 2 only that will cause
>> migration headaches, so this is just delaying the inevitable...
>>
>> -igor
>>
>>
>> On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov<mg...@apache.org>
>> wrote:
>>> Hi,
>>>
>>> In the recent ticket changes by Igor I mentioned few comments that
>>> Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
>>> call it).
>>>
>>> I want to share my experience with trying to re-vive Matej's work at [1],
>> [2].
>>> The changes there are a bit drastic (maybe because the task hasn't
>>> been finished and the API breaks not cleaned) and knowing how Ajax
>>> heavy are the applications I've worked on I think it will be quite a
>>> work to migrate the apps from 1.5 to Wicket.next.
>>> I also tried to introduce wicket-ajax.jar with the new impl and keep
>>> the old one for transition but that wasn't easy too.
>>>
>>> So I want to propose a two step approach:
>>> 1) introduce some JavaScript library for Wicket.next and improve
>>> wicket-xyz.js files by using it
>>> 2) improve/reimplement Wicket Ajax for Wicket.next+1
>>>
>>>
>>> martin-g
>>>
>>> 1.
>> http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
>>> 2. https://github.com/martin-g/wicket/tree/ajax2
>>>
>>
>
Re: Ajax in Wicket.next
Posted by Brian Topping <to...@codehaus.org>.
+1 as well, a compliment of [1]. There are a number of standardized client architectures (like backbone) with significant followings, being able to "Wicketize" a live mockup written in a single would be powerful. Creating a standardized server environment to work with many of these platforms would be huge. But of course, backwards compatibility being what it is...
[1] http://markmail.org/message/bdv6nk7vdbv33tmj
On Sep 19, 2011, at 8:22 PM, robert.mcguinness wrote:
> +1 for what Juliano said...something in the lines of what backbone.js but for
> Wicket...History API support (pushState, replaceState, onPopState) would be
> "wicket-ed".
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Ajax-in-Wicket-next-tp3824240p3825552.html
> Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
>
Re: Ajax in Wicket.next
Posted by "robert.mcguinness" <ro...@gmail.com>.
+1 for what Juliano said...something in the lines of what backbone.js but for
Wicket...History API support (pushState, replaceState, onPopState) would be
"wicket-ed".
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Ajax-in-Wicket-next-tp3824240p3825552.html
Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: Ajax in Wicket.next
Posted by Juliano Viana <ju...@logicstyle.com>.
Hi,
I have created some pretty sophisticated Ajax components for a customer
project using Prototype and JQuery.
I believe client-side JavaScript is becoming more and more reliable, which
means a lot of functionality can be moved from the server side to the
client side.
When creating a sophisticated Ajax component with Wicket, the most dificult
part is to make the JavaScript code interact with the server-side models.
If Wicket would provide an abstraction layer on the JavaScript side that
would allow scripts to easily interact with a component model , then it
would be much easier to create Ajax components and behaviours, and would
probably make it possible to implement standard Wicket components in a way
that is more independent from the underlying JS framework.
Regards,
- Juliano Viana
On Mon, Sep 19, 2011 at 4:25 PM, tetsuo <ro...@gmail.com> wrote:
> Spring-JavaScript (a submodule of Spring WebFlow) used a modular approach,
> in which you could (in theory, at least) provide multiple implementations
> of
> a javascript API (
>
> http://static.springsource.org/spring-webflow/docs/2.0.x/reference/html/ch11s03.html
> ).
>
> You'd import the underlying library (dojo.js), the high-level library API
> (spring.js), and then the implementation of the low-level API, used by the
> high-level library (spring-dojo.js).
>
> I say in theory because they have a Dojo implementation, but never bothered
> to provide other implementations (
> https://jira.springsource.org/browse/SWF-1288)...
>
>
> Ah, one more item in the wishlist is the possibility of joining the many
> js/css resources in one big file. I think it's very hard/impossible to do
> it
> transparently (due the high granularity), but should be relatively easy if
> it required fine-tunning of the app (for example, registering all js/css
> resources to be joined/omitted in some application-wide setting).
>
> Tetsuo
>
>
> On Mon, Sep 19, 2011 at 4:03 PM, Martin Grigorov <mgrigorov@apache.org
> >wrote:
>
> > On Mon, Sep 19, 2011 at 8:49 PM, Igor Vaynberg <ig...@gmail.com>
> > wrote:
> > > here is my take on the areas that need improvement:
> > >
> > > * there is a potential to significantly reduce the size of our
> > > wicket-ajax.js by rebuilding it on top of a js library like jquery
> > > which provides all the basics such as an ajax pipeline and
> > > replaceOuterHtml() function.
> > I also think that JQuery will be the best to pick at the moment, but
> > seeing what happened with Tapestry choice to use Prototype and their
> > efforts to escape from it now. Also following Node.js trends (see
> > Ender with its Jeesh (Bonzo, Bean, Qwery, ...), see CoffeeScript,
> > Underscore, all these specialized CommonJS/AMD modules) I still think
> > that picking any JS library will make some developers life harder. For
> > example if my application is based on Dojo/ExtJS/... choosing JQuery
> > will just add more some more bytes to my response ...
> > That's why I think making it with adapter with default impl based on
> > JQuery will be the best. This way Dojo users can implement the adapter
> > and be happy. Check https://github.com/balupton/History.js to see what
> > I mean.
> > > * currently we use inline attributes, eg adding a behavior to a
> > > component adds javascript in an onclick attribute. we need to switch
> > > to using dom events for this. this will solve the long outstanding
> > > problem of "cant add multiple behaviors to the same event"
> > I think adding multiple behaviors will be anti-pattern.
> > This way the user will be able to add several onclick handlers and
> > thus do several Ajax requests and this will make the processing
> > slower, especially if they are queued.
> > It will be better to have one event handler and split the work on the
> > server side.
> > > * server-side customization of callbacks is very difficult. eg it is
> > > not easy to add a callback variable that clientside js would pass to
> > > the serverside callback. this essentially requires a
> > > sql-injection-like attack on the callback url generated by wicket - so
> > > its a big hack.
> > > * ajax generates *a lot* of javascript in the source, making the
> > > document bigger. we can reduce that significantly.
> > > * better support for ajax channels and blocking behavior. eg right now
> > > its pretty hard to write an ajax button/link that blocks multiple hits
> > > or perhaps blocks all other ajax activity on the page.
> > >
> > > -igor
> > >
> > >
> > > On Mon, Sep 19, 2011 at 10:20 AM, tetsuo <ro...@gmail.com>
> > wrote:
> > >> What is so broken about the current ajax in Wicket, that requires such
> > >> rewrite?
> > >>
> > >>
> > >>
> > >> On Mon, Sep 19, 2011 at 1:11 PM, Igor Vaynberg <
> igor.vaynberg@gmail.com
> > >wrote:
> > >>
> > >>> staged approach is fine, however its step 2 only that will cause
> > >>> migration headaches, so this is just delaying the inevitable...
> > >>>
> > >>> -igor
> > >>>
> > >>>
> > >>> On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov <
> mgrigorov@apache.org
> > >
> > >>> wrote:
> > >>> > Hi,
> > >>> >
> > >>> > In the recent ticket changes by Igor I mentioned few comments that
> > >>> > Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever
> we
> > >>> > call it).
> > >>> >
> > >>> > I want to share my experience with trying to re-vive Matej's work
> at
> > [1],
> > >>> [2].
> > >>> > The changes there are a bit drastic (maybe because the task hasn't
> > >>> > been finished and the API breaks not cleaned) and knowing how Ajax
> > >>> > heavy are the applications I've worked on I think it will be quite
> a
> > >>> > work to migrate the apps from 1.5 to Wicket.next.
> > >>> > I also tried to introduce wicket-ajax.jar with the new impl and
> keep
> > >>> > the old one for transition but that wasn't easy too.
> > >>> >
> > >>> > So I want to propose a two step approach:
> > >>> > 1) introduce some JavaScript library for Wicket.next and improve
> > >>> > wicket-xyz.js files by using it
> > >>> > 2) improve/reimplement Wicket Ajax for Wicket.next+1
> > >>> >
> > >>> >
> > >>> > martin-g
> > >>> >
> > >>> > 1.
> > >>>
> >
> http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
> > >>> > 2. https://github.com/martin-g/wicket/tree/ajax2
> > >>> >
> > >>>
> > >>
> > >
> >
> >
> >
> > --
> > Martin Grigorov
> > jWeekend
> > Training, Consulting, Development
> > http://jWeekend.com
> >
>
Re: Ajax in Wicket.next
Posted by Renaud Bruyeron <br...@fullsix.com>.
2011/9/19 tetsuo <ro...@gmail.com>
> Ah, one more item in the wishlist is the possibility of joining the many
> js/css resources in one big file. I think it's very hard/impossible to do
> it
> transparently (due the high granularity), but should be relatively easy if
> it required fine-tunning of the app (for example, registering all js/css
> resources to be joined/omitted in some application-wide setting).
>
>
I think this is what things like jawr do. There is a wicket module, though I
do not know its status.
http://jawr.java.net/
Renaud
Re: Ajax in Wicket.next
Posted by tetsuo <ro...@gmail.com>.
Spring-JavaScript (a submodule of Spring WebFlow) used a modular approach,
in which you could (in theory, at least) provide multiple implementations of
a javascript API (
http://static.springsource.org/spring-webflow/docs/2.0.x/reference/html/ch11s03.html
).
You'd import the underlying library (dojo.js), the high-level library API
(spring.js), and then the implementation of the low-level API, used by the
high-level library (spring-dojo.js).
I say in theory because they have a Dojo implementation, but never bothered
to provide other implementations (
https://jira.springsource.org/browse/SWF-1288)...
Ah, one more item in the wishlist is the possibility of joining the many
js/css resources in one big file. I think it's very hard/impossible to do it
transparently (due the high granularity), but should be relatively easy if
it required fine-tunning of the app (for example, registering all js/css
resources to be joined/omitted in some application-wide setting).
Tetsuo
On Mon, Sep 19, 2011 at 4:03 PM, Martin Grigorov <mg...@apache.org>wrote:
> On Mon, Sep 19, 2011 at 8:49 PM, Igor Vaynberg <ig...@gmail.com>
> wrote:
> > here is my take on the areas that need improvement:
> >
> > * there is a potential to significantly reduce the size of our
> > wicket-ajax.js by rebuilding it on top of a js library like jquery
> > which provides all the basics such as an ajax pipeline and
> > replaceOuterHtml() function.
> I also think that JQuery will be the best to pick at the moment, but
> seeing what happened with Tapestry choice to use Prototype and their
> efforts to escape from it now. Also following Node.js trends (see
> Ender with its Jeesh (Bonzo, Bean, Qwery, ...), see CoffeeScript,
> Underscore, all these specialized CommonJS/AMD modules) I still think
> that picking any JS library will make some developers life harder. For
> example if my application is based on Dojo/ExtJS/... choosing JQuery
> will just add more some more bytes to my response ...
> That's why I think making it with adapter with default impl based on
> JQuery will be the best. This way Dojo users can implement the adapter
> and be happy. Check https://github.com/balupton/History.js to see what
> I mean.
> > * currently we use inline attributes, eg adding a behavior to a
> > component adds javascript in an onclick attribute. we need to switch
> > to using dom events for this. this will solve the long outstanding
> > problem of "cant add multiple behaviors to the same event"
> I think adding multiple behaviors will be anti-pattern.
> This way the user will be able to add several onclick handlers and
> thus do several Ajax requests and this will make the processing
> slower, especially if they are queued.
> It will be better to have one event handler and split the work on the
> server side.
> > * server-side customization of callbacks is very difficult. eg it is
> > not easy to add a callback variable that clientside js would pass to
> > the serverside callback. this essentially requires a
> > sql-injection-like attack on the callback url generated by wicket - so
> > its a big hack.
> > * ajax generates *a lot* of javascript in the source, making the
> > document bigger. we can reduce that significantly.
> > * better support for ajax channels and blocking behavior. eg right now
> > its pretty hard to write an ajax button/link that blocks multiple hits
> > or perhaps blocks all other ajax activity on the page.
> >
> > -igor
> >
> >
> > On Mon, Sep 19, 2011 at 10:20 AM, tetsuo <ro...@gmail.com>
> wrote:
> >> What is so broken about the current ajax in Wicket, that requires such
> >> rewrite?
> >>
> >>
> >>
> >> On Mon, Sep 19, 2011 at 1:11 PM, Igor Vaynberg <igor.vaynberg@gmail.com
> >wrote:
> >>
> >>> staged approach is fine, however its step 2 only that will cause
> >>> migration headaches, so this is just delaying the inevitable...
> >>>
> >>> -igor
> >>>
> >>>
> >>> On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov <mgrigorov@apache.org
> >
> >>> wrote:
> >>> > Hi,
> >>> >
> >>> > In the recent ticket changes by Igor I mentioned few comments that
> >>> > Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
> >>> > call it).
> >>> >
> >>> > I want to share my experience with trying to re-vive Matej's work at
> [1],
> >>> [2].
> >>> > The changes there are a bit drastic (maybe because the task hasn't
> >>> > been finished and the API breaks not cleaned) and knowing how Ajax
> >>> > heavy are the applications I've worked on I think it will be quite a
> >>> > work to migrate the apps from 1.5 to Wicket.next.
> >>> > I also tried to introduce wicket-ajax.jar with the new impl and keep
> >>> > the old one for transition but that wasn't easy too.
> >>> >
> >>> > So I want to propose a two step approach:
> >>> > 1) introduce some JavaScript library for Wicket.next and improve
> >>> > wicket-xyz.js files by using it
> >>> > 2) improve/reimplement Wicket Ajax for Wicket.next+1
> >>> >
> >>> >
> >>> > martin-g
> >>> >
> >>> > 1.
> >>>
> http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
> >>> > 2. https://github.com/martin-g/wicket/tree/ajax2
> >>> >
> >>>
> >>
> >
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
Re: Ajax in Wicket.next
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Sep 19, 2011 at 8:49 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> here is my take on the areas that need improvement:
>
> * there is a potential to significantly reduce the size of our
> wicket-ajax.js by rebuilding it on top of a js library like jquery
> which provides all the basics such as an ajax pipeline and
> replaceOuterHtml() function.
I also think that JQuery will be the best to pick at the moment, but
seeing what happened with Tapestry choice to use Prototype and their
efforts to escape from it now. Also following Node.js trends (see
Ender with its Jeesh (Bonzo, Bean, Qwery, ...), see CoffeeScript,
Underscore, all these specialized CommonJS/AMD modules) I still think
that picking any JS library will make some developers life harder. For
example if my application is based on Dojo/ExtJS/... choosing JQuery
will just add more some more bytes to my response ...
That's why I think making it with adapter with default impl based on
JQuery will be the best. This way Dojo users can implement the adapter
and be happy. Check https://github.com/balupton/History.js to see what
I mean.
> * currently we use inline attributes, eg adding a behavior to a
> component adds javascript in an onclick attribute. we need to switch
> to using dom events for this. this will solve the long outstanding
> problem of "cant add multiple behaviors to the same event"
I think adding multiple behaviors will be anti-pattern.
This way the user will be able to add several onclick handlers and
thus do several Ajax requests and this will make the processing
slower, especially if they are queued.
It will be better to have one event handler and split the work on the
server side.
> * server-side customization of callbacks is very difficult. eg it is
> not easy to add a callback variable that clientside js would pass to
> the serverside callback. this essentially requires a
> sql-injection-like attack on the callback url generated by wicket - so
> its a big hack.
> * ajax generates *a lot* of javascript in the source, making the
> document bigger. we can reduce that significantly.
> * better support for ajax channels and blocking behavior. eg right now
> its pretty hard to write an ajax button/link that blocks multiple hits
> or perhaps blocks all other ajax activity on the page.
>
> -igor
>
>
> On Mon, Sep 19, 2011 at 10:20 AM, tetsuo <ro...@gmail.com> wrote:
>> What is so broken about the current ajax in Wicket, that requires such
>> rewrite?
>>
>>
>>
>> On Mon, Sep 19, 2011 at 1:11 PM, Igor Vaynberg <ig...@gmail.com>wrote:
>>
>>> staged approach is fine, however its step 2 only that will cause
>>> migration headaches, so this is just delaying the inevitable...
>>>
>>> -igor
>>>
>>>
>>> On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov <mg...@apache.org>
>>> wrote:
>>> > Hi,
>>> >
>>> > In the recent ticket changes by Igor I mentioned few comments that
>>> > Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
>>> > call it).
>>> >
>>> > I want to share my experience with trying to re-vive Matej's work at [1],
>>> [2].
>>> > The changes there are a bit drastic (maybe because the task hasn't
>>> > been finished and the API breaks not cleaned) and knowing how Ajax
>>> > heavy are the applications I've worked on I think it will be quite a
>>> > work to migrate the apps from 1.5 to Wicket.next.
>>> > I also tried to introduce wicket-ajax.jar with the new impl and keep
>>> > the old one for transition but that wasn't easy too.
>>> >
>>> > So I want to propose a two step approach:
>>> > 1) introduce some JavaScript library for Wicket.next and improve
>>> > wicket-xyz.js files by using it
>>> > 2) improve/reimplement Wicket Ajax for Wicket.next+1
>>> >
>>> >
>>> > martin-g
>>> >
>>> > 1.
>>> http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
>>> > 2. https://github.com/martin-g/wicket/tree/ajax2
>>> >
>>>
>>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: Ajax in Wicket.next
Posted by Igor Vaynberg <ig...@gmail.com>.
i think server-side api changes should be minimal unless you heavily
customized the ajax behaviors with regard to what url/scripts they
use...
-igor
On Mon, Sep 19, 2011 at 11:09 AM, tetsuo <ro...@gmail.com> wrote:
> Ok. I'd add some kind of 'server-side-push/comet/websocket' support to the
> wishlist :)
>
> It certainly will break the javascript side, but do you guys think these
> improvements could be implemented without breaking (too much) the Java API?
>
>
>
> On Mon, Sep 19, 2011 at 2:49 PM, Igor Vaynberg <ig...@gmail.com>wrote:
>
>> here is my take on the areas that need improvement:
>>
>> * there is a potential to significantly reduce the size of our
>> wicket-ajax.js by rebuilding it on top of a js library like jquery
>> which provides all the basics such as an ajax pipeline and
>> replaceOuterHtml() function.
>> * currently we use inline attributes, eg adding a behavior to a
>> component adds javascript in an onclick attribute. we need to switch
>> to using dom events for this. this will solve the long outstanding
>> problem of "cant add multiple behaviors to the same event"
>> * server-side customization of callbacks is very difficult. eg it is
>> not easy to add a callback variable that clientside js would pass to
>> the serverside callback. this essentially requires a
>> sql-injection-like attack on the callback url generated by wicket - so
>> its a big hack.
>> * ajax generates *a lot* of javascript in the source, making the
>> document bigger. we can reduce that significantly.
>> * better support for ajax channels and blocking behavior. eg right now
>> its pretty hard to write an ajax button/link that blocks multiple hits
>> or perhaps blocks all other ajax activity on the page.
>>
>> -igor
>>
>>
>> On Mon, Sep 19, 2011 at 10:20 AM, tetsuo <ro...@gmail.com> wrote:
>> > What is so broken about the current ajax in Wicket, that requires such
>> > rewrite?
>> >
>> >
>> >
>> > On Mon, Sep 19, 2011 at 1:11 PM, Igor Vaynberg <igor.vaynberg@gmail.com
>> >wrote:
>> >
>> >> staged approach is fine, however its step 2 only that will cause
>> >> migration headaches, so this is just delaying the inevitable...
>> >>
>> >> -igor
>> >>
>> >>
>> >> On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov <mg...@apache.org>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > In the recent ticket changes by Igor I mentioned few comments that
>> >> > Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
>> >> > call it).
>> >> >
>> >> > I want to share my experience with trying to re-vive Matej's work at
>> [1],
>> >> [2].
>> >> > The changes there are a bit drastic (maybe because the task hasn't
>> >> > been finished and the API breaks not cleaned) and knowing how Ajax
>> >> > heavy are the applications I've worked on I think it will be quite a
>> >> > work to migrate the apps from 1.5 to Wicket.next.
>> >> > I also tried to introduce wicket-ajax.jar with the new impl and keep
>> >> > the old one for transition but that wasn't easy too.
>> >> >
>> >> > So I want to propose a two step approach:
>> >> > 1) introduce some JavaScript library for Wicket.next and improve
>> >> > wicket-xyz.js files by using it
>> >> > 2) improve/reimplement Wicket Ajax for Wicket.next+1
>> >> >
>> >> >
>> >> > martin-g
>> >> >
>> >> > 1.
>> >>
>> http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
>> >> > 2. https://github.com/martin-g/wicket/tree/ajax2
>> >> >
>> >>
>> >
>>
>
Re: Ajax in Wicket.next
Posted by tetsuo <ro...@gmail.com>.
Ok. I'd add some kind of 'server-side-push/comet/websocket' support to the
wishlist :)
It certainly will break the javascript side, but do you guys think these
improvements could be implemented without breaking (too much) the Java API?
On Mon, Sep 19, 2011 at 2:49 PM, Igor Vaynberg <ig...@gmail.com>wrote:
> here is my take on the areas that need improvement:
>
> * there is a potential to significantly reduce the size of our
> wicket-ajax.js by rebuilding it on top of a js library like jquery
> which provides all the basics such as an ajax pipeline and
> replaceOuterHtml() function.
> * currently we use inline attributes, eg adding a behavior to a
> component adds javascript in an onclick attribute. we need to switch
> to using dom events for this. this will solve the long outstanding
> problem of "cant add multiple behaviors to the same event"
> * server-side customization of callbacks is very difficult. eg it is
> not easy to add a callback variable that clientside js would pass to
> the serverside callback. this essentially requires a
> sql-injection-like attack on the callback url generated by wicket - so
> its a big hack.
> * ajax generates *a lot* of javascript in the source, making the
> document bigger. we can reduce that significantly.
> * better support for ajax channels and blocking behavior. eg right now
> its pretty hard to write an ajax button/link that blocks multiple hits
> or perhaps blocks all other ajax activity on the page.
>
> -igor
>
>
> On Mon, Sep 19, 2011 at 10:20 AM, tetsuo <ro...@gmail.com> wrote:
> > What is so broken about the current ajax in Wicket, that requires such
> > rewrite?
> >
> >
> >
> > On Mon, Sep 19, 2011 at 1:11 PM, Igor Vaynberg <igor.vaynberg@gmail.com
> >wrote:
> >
> >> staged approach is fine, however its step 2 only that will cause
> >> migration headaches, so this is just delaying the inevitable...
> >>
> >> -igor
> >>
> >>
> >> On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov <mg...@apache.org>
> >> wrote:
> >> > Hi,
> >> >
> >> > In the recent ticket changes by Igor I mentioned few comments that
> >> > Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
> >> > call it).
> >> >
> >> > I want to share my experience with trying to re-vive Matej's work at
> [1],
> >> [2].
> >> > The changes there are a bit drastic (maybe because the task hasn't
> >> > been finished and the API breaks not cleaned) and knowing how Ajax
> >> > heavy are the applications I've worked on I think it will be quite a
> >> > work to migrate the apps from 1.5 to Wicket.next.
> >> > I also tried to introduce wicket-ajax.jar with the new impl and keep
> >> > the old one for transition but that wasn't easy too.
> >> >
> >> > So I want to propose a two step approach:
> >> > 1) introduce some JavaScript library for Wicket.next and improve
> >> > wicket-xyz.js files by using it
> >> > 2) improve/reimplement Wicket Ajax for Wicket.next+1
> >> >
> >> >
> >> > martin-g
> >> >
> >> > 1.
> >>
> http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
> >> > 2. https://github.com/martin-g/wicket/tree/ajax2
> >> >
> >>
> >
>
Re: Ajax in Wicket.next
Posted by Igor Vaynberg <ig...@gmail.com>.
here is my take on the areas that need improvement:
* there is a potential to significantly reduce the size of our
wicket-ajax.js by rebuilding it on top of a js library like jquery
which provides all the basics such as an ajax pipeline and
replaceOuterHtml() function.
* currently we use inline attributes, eg adding a behavior to a
component adds javascript in an onclick attribute. we need to switch
to using dom events for this. this will solve the long outstanding
problem of "cant add multiple behaviors to the same event"
* server-side customization of callbacks is very difficult. eg it is
not easy to add a callback variable that clientside js would pass to
the serverside callback. this essentially requires a
sql-injection-like attack on the callback url generated by wicket - so
its a big hack.
* ajax generates *a lot* of javascript in the source, making the
document bigger. we can reduce that significantly.
* better support for ajax channels and blocking behavior. eg right now
its pretty hard to write an ajax button/link that blocks multiple hits
or perhaps blocks all other ajax activity on the page.
-igor
On Mon, Sep 19, 2011 at 10:20 AM, tetsuo <ro...@gmail.com> wrote:
> What is so broken about the current ajax in Wicket, that requires such
> rewrite?
>
>
>
> On Mon, Sep 19, 2011 at 1:11 PM, Igor Vaynberg <ig...@gmail.com>wrote:
>
>> staged approach is fine, however its step 2 only that will cause
>> migration headaches, so this is just delaying the inevitable...
>>
>> -igor
>>
>>
>> On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov <mg...@apache.org>
>> wrote:
>> > Hi,
>> >
>> > In the recent ticket changes by Igor I mentioned few comments that
>> > Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
>> > call it).
>> >
>> > I want to share my experience with trying to re-vive Matej's work at [1],
>> [2].
>> > The changes there are a bit drastic (maybe because the task hasn't
>> > been finished and the API breaks not cleaned) and knowing how Ajax
>> > heavy are the applications I've worked on I think it will be quite a
>> > work to migrate the apps from 1.5 to Wicket.next.
>> > I also tried to introduce wicket-ajax.jar with the new impl and keep
>> > the old one for transition but that wasn't easy too.
>> >
>> > So I want to propose a two step approach:
>> > 1) introduce some JavaScript library for Wicket.next and improve
>> > wicket-xyz.js files by using it
>> > 2) improve/reimplement Wicket Ajax for Wicket.next+1
>> >
>> >
>> > martin-g
>> >
>> > 1.
>> http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
>> > 2. https://github.com/martin-g/wicket/tree/ajax2
>> >
>>
>
Re: Ajax in Wicket.next
Posted by tetsuo <ro...@gmail.com>.
What is so broken about the current ajax in Wicket, that requires such
rewrite?
On Mon, Sep 19, 2011 at 1:11 PM, Igor Vaynberg <ig...@gmail.com>wrote:
> staged approach is fine, however its step 2 only that will cause
> migration headaches, so this is just delaying the inevitable...
>
> -igor
>
>
> On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov <mg...@apache.org>
> wrote:
> > Hi,
> >
> > In the recent ticket changes by Igor I mentioned few comments that
> > Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
> > call it).
> >
> > I want to share my experience with trying to re-vive Matej's work at [1],
> [2].
> > The changes there are a bit drastic (maybe because the task hasn't
> > been finished and the API breaks not cleaned) and knowing how Ajax
> > heavy are the applications I've worked on I think it will be quite a
> > work to migrate the apps from 1.5 to Wicket.next.
> > I also tried to introduce wicket-ajax.jar with the new impl and keep
> > the old one for transition but that wasn't easy too.
> >
> > So I want to propose a two step approach:
> > 1) introduce some JavaScript library for Wicket.next and improve
> > wicket-xyz.js files by using it
> > 2) improve/reimplement Wicket Ajax for Wicket.next+1
> >
> >
> > martin-g
> >
> > 1.
> http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
> > 2. https://github.com/martin-g/wicket/tree/ajax2
> >
>
Re: Ajax in Wicket.next
Posted by Igor Vaynberg <ig...@gmail.com>.
staged approach is fine, however its step 2 only that will cause
migration headaches, so this is just delaying the inevitable...
-igor
On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov <mg...@apache.org> wrote:
> Hi,
>
> In the recent ticket changes by Igor I mentioned few comments that
> Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
> call it).
>
> I want to share my experience with trying to re-vive Matej's work at [1], [2].
> The changes there are a bit drastic (maybe because the task hasn't
> been finished and the API breaks not cleaned) and knowing how Ajax
> heavy are the applications I've worked on I think it will be quite a
> work to migrate the apps from 1.5 to Wicket.next.
> I also tried to introduce wicket-ajax.jar with the new impl and keep
> the old one for transition but that wasn't easy too.
>
> So I want to propose a two step approach:
> 1) introduce some JavaScript library for Wicket.next and improve
> wicket-xyz.js files by using it
> 2) improve/reimplement Wicket Ajax for Wicket.next+1
>
>
> martin-g
>
> 1. http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
> 2. https://github.com/martin-g/wicket/tree/ajax2
>
Re: Ajax in Wicket.next
Posted by Pointbreak <po...@ml1.net>.
On Tuesday, September 20, 2011 2:28 PM, "Korbinian Bachl - privat"
<ko...@whiskyworld.de> wrote:
>
> Am 20.09.11 13:11, schrieb Pointbreak:
> > I'm completely agreeing with Martin on this one. The things you are
> > suggesting imho have the following consequences:
> > - Wicket implementation becomes way more complicated, because Wicket has
> > to translate between component hierarchy and browser DOM-tree, which is
> > non-trivial, and requires a lot of extra server side processing.
>
> just a rough idea and not a single implementation yet but we know how
> hard it is to compute?
Than please just try to get beyond your rough idea into a design on
paper. Start with a DOM-tree builder that computes a DOM-tree from all
the template snippets that Wicket uses to generate pages, factor in
repeaters, optional components etc. Than design models and algorithms to
map that on Wickets component hierarchy, etc. Factor in client side
changes and browser differences to the DOM-tree, and server side changes
to component hierarchy. It's really not a bad idea to try to understand
the implications of your rough idea.
> > - User implementation becomes substantially more complicated because one
> > way or another, the user has to give hints to Wicket how eventual
> > client-side javascripts not managed by wicket are manipulating the
> > DOM-tree (which by the way is easy to break between browsers, as
> > DOM-trees for the same HTML may differ substantially between browsers).
>
> thats a problem either way - ever tried to integrate third party JS with
> wicket?
Yes I have, with pretty complicated designs as well with a lot of jQuery
UI, layouts managed at the client side, etc. And this has never been a
problem for me, while your proposal would give me headaches because I
have to think about letting Wicket know how I'm changing the DOM-tree at
the client side.
My one and only gripe with the wicket-ajax stuff is the complicated way
to render callbacks in javascript to server side functions.
> > - Bugs in the user implementation are substantially harder to track than
> > a forgotten setOutputMarkupId(true) in the current API.
>
> sure?
Yes sure. A forgotten setOutputMarkupId(true) will trigger an exception
when trying to add that component to an AjaxRequestTarget. That's pretty
hard to miss, and the offending component is easy to locate from the
exception.
> > - This will break existing API functionality and code in a big way.
>
> thats the reason were talking about wicket.next and not wicket.now - and
> api breaks will at some point come else wicket can't go forward....
Of course. It's also the reason I'm responding ;-). So far all API
breaks in Wicket I've had to deal with were easy to migrate to. I can't
see how your proposal can be incorporated in an evolutionary API design
change. But feel free to prove me wrong.
> > And all that for not having a few extra setOutputMarkupId(true) calls?
> >
> > If setOutputmarkupId bothers you that much, it's easy to write a visitor
> > that just calls it for all your components...
>
> now honestly - thanks for not ready anything in the long posts before;
>
> the reason why I'd favor such a thing is that it makes wicket able to
> ajaxify *any* component. Current ajax won't work on all current core
> components - thats it. There is a reason why Martin wanted to completely
> rewrite wicket ajax a time back and it wasn't that he had too much
> leisure time....
Sorry but I did read that. My response was for your proposal to manage a
DOM-tree in wicket.
Re: Ajax in Wicket.next
Posted by Korbinian Bachl - privat <ko...@whiskyworld.de>.
Am 20.09.11 13:11, schrieb Pointbreak:
> I'm completely agreeing with Martin on this one. The things you are
> suggesting imho have the following consequences:
> - Wicket implementation becomes way more complicated, because Wicket has
> to translate between component hierarchy and browser DOM-tree, which is
> non-trivial, and requires a lot of extra server side processing.
just a rough idea and not a single implementation yet but we know how
hard it is to compute?
> - User implementation becomes substantially more complicated because one
> way or another, the user has to give hints to Wicket how eventual
> client-side javascripts not managed by wicket are manipulating the
> DOM-tree (which by the way is easy to break between browsers, as
> DOM-trees for the same HTML may differ substantially between browsers).
thats a problem either way - ever tried to integrate third party JS with
wicket?
> - Bugs in the user implementation are substantially harder to track than
> a forgotten setOutputMarkupId(true) in the current API.
sure?
> - This will break existing API functionality and code in a big way.
thats the reason were talking about wicket.next and not wicket.now - and
api breaks will at some point come else wicket can't go forward....
>
> And all that for not having a few extra setOutputMarkupId(true) calls?
>
> If setOutputmarkupId bothers you that much, it's easy to write a visitor
> that just calls it for all your components...
now honestly - thanks for not ready anything in the long posts before;
the reason why I'd favor such a thing is that it makes wicket able to
ajaxify *any* component. Current ajax won't work on all current core
components - thats it. There is a reason why Martin wanted to completely
rewrite wicket ajax a time back and it wasn't that he had too much
leisure time....
Re: Ajax in Wicket.next
Posted by Pointbreak <po...@ml1.net>.
I'm completely agreeing with Martin on this one. The things you are
suggesting imho have the following consequences:
- Wicket implementation becomes way more complicated, because Wicket has
to translate between component hierarchy and browser DOM-tree, which is
non-trivial, and requires a lot of extra server side processing.
- User implementation becomes substantially more complicated because one
way or another, the user has to give hints to Wicket how eventual
client-side javascripts not managed by wicket are manipulating the
DOM-tree (which by the way is easy to break between browsers, as
DOM-trees for the same HTML may differ substantially between browsers).
- Bugs in the user implementation are substantially harder to track than
a forgotten setOutputMarkupId(true) in the current API.
- This will break existing API functionality and code in a big way.
And all that for not having a few extra setOutputMarkupId(true) calls?
If setOutputmarkupId bothers you that much, it's easy to write a visitor
that just calls it for all your components...
On Tuesday, September 20, 2011 12:52 PM, "Korbinian Bachl - privat"
<ko...@whiskyworld.de> wrote:
>
>
> Am 20.09.11 12:30, schrieb Martin Grigorov:
> > On Tue, Sep 20, 2011 at 1:11 PM, Korbinian Bachl - privat
> > <ko...@whiskyworld.de> 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 :)
>
Re: Ajax in Wicket.next
Posted by Korbinian Bachl - privat <ko...@whiskyworld.de>.
Am 20.09.11 12:30, schrieb Martin Grigorov:
> On Tue, Sep 20, 2011 at 1:11 PM, Korbinian Bachl - privat
> <ko...@whiskyworld.de> 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 :)
Re: Ajax in Wicket.next
Posted by Martin Grigorov <mg...@apache.org>.
On Tue, Sep 20, 2011 at 1:11 PM, Korbinian Bachl - privat
<ko...@whiskyworld.de> 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
Re: Ajax in Wicket.next
Posted by Korbinian Bachl - privat <ko...@whiskyworld.de>.
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?
Re: Ajax in Wicket.next
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Tue, Sep 20, 2011 at 12:08 PM, Korbinian Bachl - privat
<ko...@whiskyworld.de> 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
Re: Ajax in Wicket.next
Posted by Martin Grigorov <mg...@apache.org>.
Hi Korbinian,
On Tue, Sep 20, 2011 at 10:48 AM, Korbinian Bachl - privat
<ko...@whiskyworld.de> wrote:
> 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.
>
> 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.
> Reasons are:
>
> - jQuery is well designed, upgrade paths are good documented
>
> - jQuery is *known* to already many many people, there are a ton of
> documentation out there - from books to DVD's!
>
> - jQuery is actively developed by quite many people, just see how many are
> taking care for just (!) a JavaScript library: http://jquery.org/team/ and
> then compare the manpower to wicket itself that has much more to be taken
> care of
>
> - jQuery *is* browser safe! I cant stop counting the times when I upgraded a
> browser and suddenly wicket Ajax stopped working, currently Opera 11.51 just
> killed one of my modal windows - at version 10.50 it worked... staying up to
> date now would only mean to make sure jQuery is up-to-date
>
> - jQuery gives you hooks to interact with and provides some sort of
> layering, but please don't go the spring way (nobody needs *another* own
> breed java-script layer that then won't be really worked on and/ or cared
> for "up-to-dateness")
>
> and final
>
> -jQuery will save the wicket dev's much work in the future!
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".
>
>
> my 2c
>
>
>
> Am 19.09.11 17:29, schrieb Martin Grigorov:
>>
>> Hi,
>>
>> In the recent ticket changes by Igor I mentioned few comments that
>> Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
>> call it).
>>
>> I want to share my experience with trying to re-vive Matej's work at [1],
>> [2].
>> The changes there are a bit drastic (maybe because the task hasn't
>> been finished and the API breaks not cleaned) and knowing how Ajax
>> heavy are the applications I've worked on I think it will be quite a
>> work to migrate the apps from 1.5 to Wicket.next.
>> I also tried to introduce wicket-ajax.jar with the new impl and keep
>> the old one for transition but that wasn't easy too.
>>
>> So I want to propose a two step approach:
>> 1) introduce some JavaScript library for Wicket.next and improve
>> wicket-xyz.js files by using it
>> 2) improve/reimplement Wicket Ajax for Wicket.next+1
>>
>>
>> martin-g
>>
>> 1.
>> http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
>> 2. https://github.com/martin-g/wicket/tree/ajax2
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: Ajax in Wicket.next
Posted by Korbinian Bachl - privat <ko...@whiskyworld.de>.
Well, I think there is consent that we can say current wicket ajax is
quite broken and a big pain in everyday usage.
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.
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. Reasons are:
- jQuery is well designed, upgrade paths are good documented
- jQuery is *known* to already many many people, there are a ton of
documentation out there - from books to DVD's!
- jQuery is actively developed by quite many people, just see how many
are taking care for just (!) a JavaScript library:
http://jquery.org/team/ and then compare the manpower to wicket itself
that has much more to be taken care of
- jQuery *is* browser safe! I cant stop counting the times when I
upgraded a browser and suddenly wicket Ajax stopped working, currently
Opera 11.51 just killed one of my modal windows - at version 10.50 it
worked... staying up to date now would only mean to make sure jQuery is
up-to-date
- jQuery gives you hooks to interact with and provides some sort of
layering, but please don't go the spring way (nobody needs *another* own
breed java-script layer that then won't be really worked on and/ or
cared for "up-to-dateness")
and final
-jQuery will save the wicket dev's much work in the future!
my 2c
Am 19.09.11 17:29, schrieb Martin Grigorov:
> Hi,
>
> In the recent ticket changes by Igor I mentioned few comments that
> Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
> call it).
>
> I want to share my experience with trying to re-vive Matej's work at [1], [2].
> The changes there are a bit drastic (maybe because the task hasn't
> been finished and the API breaks not cleaned) and knowing how Ajax
> heavy are the applications I've worked on I think it will be quite a
> work to migrate the apps from 1.5 to Wicket.next.
> I also tried to introduce wicket-ajax.jar with the new impl and keep
> the old one for transition but that wasn't easy too.
>
> So I want to propose a two step approach:
> 1) introduce some JavaScript library for Wicket.next and improve
> wicket-xyz.js files by using it
> 2) improve/reimplement Wicket Ajax for Wicket.next+1
>
>
> martin-g
>
> 1. http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
> 2. https://github.com/martin-g/wicket/tree/ajax2