Ajax in Wicket.next

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Ajax in Wicket.next

Martin Grigorov-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

Igor Vaynberg-2
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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

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 <[hidden email]>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 <[hidden email]>
> 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

Igor Vaynberg-2
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 <[hidden email]> 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 <[hidden email]>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 <[hidden email]>
>> 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
>> >
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

tetsuo
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 <[hidden email]>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 <[hidden email]> 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 <[hidden email]
> >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 <[hidden email]>
> >> 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
> >> >
> >>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

Martin Grigorov-4
In reply to this post by Igor Vaynberg-2
On Mon, Sep 19, 2011 at 7:11 PM, Igor Vaynberg <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

Igor Vaynberg-2
In reply to this post by tetsuo
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 <[hidden email]> 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 <[hidden email]>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 <[hidden email]> 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 <[hidden email]
>> >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 <[hidden email]>
>> >> 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
>> >> >
>> >>
>> >
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

Martin Grigorov-4
In reply to this post by Igor Vaynberg-2
On Mon, Sep 19, 2011 at 8:49 PM, Igor Vaynberg <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>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 <[hidden email]>
>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

tetsuo
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 <[hidden email]>wrote:

> On Mon, Sep 19, 2011 at 8:49 PM, Igor Vaynberg <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]
> >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 <[hidden email]
> >
> >>> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

Renaud Bruyeron-2
2011/9/19 tetsuo <[hidden email]>

> 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
Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

Juliano Viana
In reply to this post by tetsuo
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 <[hidden email]> 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 <[hidden email]
> >wrote:
>
> > On Mon, Sep 19, 2011 at 8:49 PM, Igor Vaynberg <[hidden email]>
> > 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 <[hidden email]>
> > 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 <
> [hidden email]
> > >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 <
> [hidden email]
> > >
> > >>> 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

robmcguinness
+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".
Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

Brian Topping
+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.
>

Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

Korbinian Bachl
In reply to this post by Martin Grigorov-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

Korbinian Bachl
In reply to this post by tetsuo
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<[hidden email]>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<[hidden email]>
>> 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
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

Martin Grigorov-4
In reply to this post by Korbinian Bachl
Hi Korbinian,

On Tue, Sep 20, 2011 at 10:48 AM, Korbinian Bachl - privat
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

Korbinian Bachl
In reply to this post by Martin Grigorov-4
Hi Martin,

Am 20.09.11 09:59, schrieb Martin Grigorov:
...

>> Well, I think there is consent that we can say current wicket ajax is quite
>> broken and a big pain in everyday usage.
> Really? Is that broken ?
> Neither mailing lists questions nor tickets prove that statement.
>>
>> The current ajax means loads of code in java for even trivial things.
>> Triple-checking that a component knows its ajax and so on. So even *if* it
>> will break api in future, I don't see a way around this!
>>
>> Do we want all those AjaxRequestTargets, .setOutput******(boolean) and more
>> of this even here in some years? Don't think so.
> What do you suggest ?
> The only option that I see as automatic is to set it for each and
> every component, no matter whether it will be ever updated with Ajax
> or not.


Ok, well, wicket consists of components. So basically it is making a
page full of a tree with components. Wicket now could scan the component
if it has any Ajax on it - then auto add what it needs like the
setOuput... - so we got rid of this.

Then the AjaxRequestTarget. Maybe its me but I find passing around this
thing all over more a headache then a help. Basically, what we do with
ajax is that we do it twice. Add it to page via .add and to
target.addComponent - so why? Because wicket differs between those
scopes, even they are same in the end (only question is: send the whole
page or just a part to the browser?).
So we really need to ask ourself why we need 2 things? If a page is
changed after beeing send to browser, don't we know automatically it is
Ajaxified when we get an ajax request? Can't the default request not
behave accordingly, so we can get rid of the whole AjaxRequestTarget? I
mean the whole wicket-ajax needs to be thought about.

Imagine that we could unite Link and AjaxLink and AjaxFallbackLink to
just a general Link with a simple onClick() method and if you want ajax
you just did link.actAsAjax(true);

  Wepapps are getting more and more dynamic and we need to look if we
can't make it more a breeze to work with. Currently I love wicket and
praise it when I work with traditional pages, but as soon as have more
than one Ajax component on a page I start asking myself if I shouldn't
dump it.

>>
>> The other question is now what to do (from a higher perspective):
>>
>> 1st: do it on own
>> 2nd: use somebody else's work
>>
>> I would go for 2 and most specific go for a complete jQuery based wicket.
> This is clear.

oh is it already? :)

>> Reasons are:
...
>
> Not sure whether you invested some of your time to see what is needed
> by wicket-ajax.js and what JQuery (or other major JS libs) offers but
> my investigation showed that none of them solves the problem with
> replaceOuterHtml() out of the box. So we will have to translate our
> code in JQuery parlance but still will have to keep the "hacks".

Well I tend to go from top to bottom, not vice versa. That "hacks" are
needed (would more call it an adapter) is clear, but if you have 2 solid
ends (wicket at one, jQuery at other) is quite more easy to plug them
together then to dump one end because there maybe some hack (tm) at it.
As I outlined above, I would like to ask if the current
AjaxRequestTarget way is the way to go - that of course affects the rest
like wicket-ajax.js;

best

...
Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

Martin Grigorov-4
In reply to this post by Martin Grigorov-4
Hi,

On Tue, Sep 20, 2011 at 12:08 PM, Korbinian Bachl - privat
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

Korbinian Bachl
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?


Reply | Threaded
Open this post in threaded view
|

Re: Ajax in Wicket.next

Martin Grigorov-4
On Tue, Sep 20, 2011 at 1:11 PM, Korbinian Bachl - privat
<[hidden email]> 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
12