Re: adding a listener to the AjaxRequestTarget

2007-01-23 Thread James McLaughlin

I ran into this issue a while back and proposed an IOnLoadContributor
interface that kind of mirrors all the good work of IHeaderContributor, but
for script that is inserted anywhere below , such as onload, or
script blocks in the actual body.
http://www.nabble.com/rfc-OnLoadContributor-tf2609406.html#a7282114

I'm getting around it now by having my Behaviors check the Target type in
onRendered, which works great for Ajax requests. For non-ajax, you need to
worry if the script block will end up in a place that isn't cool for ie.

On 1/23/07, Vincent Demay <[EMAIL PROTECTED]> wrote:


Hi all,

When I re-render a Dojo widget via an ajaxRequestTarget, I have to add
some javascript to the request depending on which widget(component) has
been added to the target. This javascript should be added in order to
re-parse new DojoWidget (from the ajax response) with dojo API. This
kind of parsing should only be done on top level Dojo component because
during parsing sub-dojo-components will be automaticaly parsed.

Actually what I need to do is  :

before sending response
1 - looking for all component added to the target
2 - for all top-level Dojo components :
   Adding its id to a map
3 - adding a js such as

djConfig.searchIds = ['id1','id2','id3'];dojo.hostenv.makeWidgets().

My problem is I can not do a such stuff in a ajaxBehavior.respond
because this should be done once by request and i do not have any access
to the component list added to the target. On the other hand I can not
extends AjaxRequestTarget because If i do that I can not use AjaxLink or
other Ajax* to re-render a Dojo Component.

So I thought to add a listener on AjaxRequestTarget that should be
called after respondComponent in respondComponents method such as a
IAjaxResponseListener with a onRender(Map/* 
*/markupIdToComponent, AjaxRequestTarget target) method.

Have you a better idea and WDYT about listener?

thanks a lot

--
Vincent



Re: adding a listener to the AjaxRequestTarget

2007-01-23 Thread Igor Vaynberg

do you really think it is necessary to call the listener for each component
rendered?
why not

IAjaxResponseListener { beforeResponse(map, target); }

the problem i see with callbacks during the render is that
target.prependjavascript will no longer have any effect and can be
confusing.

with beforeresponse listener you can still use the full facilities of the
target

so what you would do is traverse the components, build the javascript, and
use target.appendjavascript() to have it output once all the components have
been updated.

make sense or did i miss the point?

if you _do_ need it to be called _during_ the rendering then we will have to
extract an interface from the target that only has prependjavascript() and
you will only get that in the listener instead of the target itself.

-igor


On 1/23/07, Vincent Demay <[EMAIL PROTECTED]> wrote:


Hi all,

When I re-render a Dojo widget via an ajaxRequestTarget, I have to add
some javascript to the request depending on which widget(component) has
been added to the target. This javascript should be added in order to
re-parse new DojoWidget (from the ajax response) with dojo API. This
kind of parsing should only be done on top level Dojo component because
during parsing sub-dojo-components will be automaticaly parsed.

Actually what I need to do is  :

before sending response
1 - looking for all component added to the target
2 - for all top-level Dojo components :
   Adding its id to a map
3 - adding a js such as

djConfig.searchIds = ['id1','id2','id3'];dojo.hostenv.makeWidgets().

My problem is I can not do a such stuff in a ajaxBehavior.respond
because this should be done once by request and i do not have any access
to the component list added to the target. On the other hand I can not
extends AjaxRequestTarget because If i do that I can not use AjaxLink or
other Ajax* to re-render a Dojo Component.

So I thought to add a listener on AjaxRequestTarget that should be
called after respondComponent in respondComponents method such as a
IAjaxResponseListener with a onRender(Map/* 
*/markupIdToComponent, AjaxRequestTarget target) method.

Have you a better idea and WDYT about listener?

thanks a lot

--
Vincent



Re: adding a listener to the AjaxRequestTarget

2007-01-23 Thread Igor Vaynberg

i think he is talking about something a bit different

what you want can be accomplished by using a bit of javascript foo

http://ejohn.org/projects/flexible-javascript-events/

you can use that func to register a bunch of window.onload events that
execute once the html has been rendered. we were discussing about
implementing that as part of wicket to have nice serverside api support for
it, but havent had the time yet. matej?

-igor


On 1/23/07, James McLaughlin <[EMAIL PROTECTED]> wrote:


I ran into this issue a while back and proposed an IOnLoadContributor
interface that kind of mirrors all the good work of IHeaderContributor,
but
for script that is inserted anywhere below , such as onload, or
script blocks in the actual body.
http://www.nabble.com/rfc-OnLoadContributor-tf2609406.html#a7282114

I'm getting around it now by having my Behaviors check the Target type in
onRendered, which works great for Ajax requests. For non-ajax, you need to
worry if the script block will end up in a place that isn't cool for ie.

On 1/23/07, Vincent Demay <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> When I re-render a Dojo widget via an ajaxRequestTarget, I have to add
> some javascript to the request depending on which widget(component) has
> been added to the target. This javascript should be added in order to
> re-parse new DojoWidget (from the ajax response) with dojo API. This
> kind of parsing should only be done on top level Dojo component because
> during parsing sub-dojo-components will be automaticaly parsed.
>
> Actually what I need to do is  :
>
> before sending response
> 1 - looking for all component added to the target
> 2 - for all top-level Dojo components :
>Adding its id to a map
> 3 - adding a js such as
>
> djConfig.searchIds = ['id1','id2','id3'];dojo.hostenv.makeWidgets().
>
> My problem is I can not do a such stuff in a ajaxBehavior.respond
> because this should be done once by request and i do not have any access
> to the component list added to the target. On the other hand I can not
> extends AjaxRequestTarget because If i do that I can not use AjaxLink or
> other Ajax* to re-render a Dojo Component.
>
> So I thought to add a listener on AjaxRequestTarget that should be
> called after respondComponent in respondComponents method such as a
> IAjaxResponseListener with a onRender(Map/* 
> */markupIdToComponent, AjaxRequestTarget target) method.
>
> Have you a better idea and WDYT about listener?
>
> thanks a lot
>
> --
> Vincent
>




Re: adding a listener to the AjaxRequestTarget

2007-01-23 Thread James McLaughlin

You're right, he is talking about something else :) Since you can add a
Behavior to multiple components, maybe Vincent can create a Behavior to do
this. If he does this, then he can share my problem :)

So back to my problem... I need something more than window.onload, I think.
Wicket already has very sophisticated script block handling in wicket-ajax
where the insertion order of script and other dom is preserved in the
evaluation order. It would be great if Behaviors could take advantage of
this, since they are the primary way of inserting script with wicket.
However, i think Behaviors were created pre wicket-ajax and are therefore
somewhat Page rendering centric in their design. window.onload is also page
rendering specific. I'm talking about having Behaviors bridge the ajax and
page rendering worlds through some form of adaptation. This way, if the
Behavior was Page rendered, it could add itself to the window.onload queue,
if ajax rendered, it can put itself in the appropriate place in the xml
envelope and wicket-ajax takes care of the rest. The rest of wicket is
really seamless in its ajax/page rendering support, but this is one place
that isn't.

thx,
jim

On 1/23/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:


i think he is talking about something a bit different

what you want can be accomplished by using a bit of javascript foo

http://ejohn.org/projects/flexible-javascript-events/

you can use that func to register a bunch of window.onload events that
execute once the html has been rendered. we were discussing about
implementing that as part of wicket to have nice serverside api support
for
it, but havent had the time yet. matej?

-igor


On 1/23/07, James McLaughlin <[EMAIL PROTECTED]> wrote:
>
> I ran into this issue a while back and proposed an IOnLoadContributor
> interface that kind of mirrors all the good work of IHeaderContributor,
> but
> for script that is inserted anywhere below , such as onload, or
> script blocks in the actual body.
> http://www.nabble.com/rfc-OnLoadContributor-tf2609406.html#a7282114
>
> I'm getting around it now by having my Behaviors check the Target type
in
> onRendered, which works great for Ajax requests. For non-ajax, you need
to
> worry if the script block will end up in a place that isn't cool for ie.
>
> On 1/23/07, Vincent Demay <[EMAIL PROTECTED]> wrote:
> >
> > Hi all,
> >
> > When I re-render a Dojo widget via an ajaxRequestTarget, I have to add
> > some javascript to the request depending on which widget(component)
has
> > been added to the target. This javascript should be added in order to
> > re-parse new DojoWidget (from the ajax response) with dojo API. This
> > kind of parsing should only be done on top level Dojo component
because
> > during parsing sub-dojo-components will be automaticaly parsed.
> >
> > Actually what I need to do is  :
> >
> > before sending response
> > 1 - looking for all component added to the target
> > 2 - for all top-level Dojo components :
> >Adding its id to a map
> > 3 - adding a js such as
> >
> > djConfig.searchIds = ['id1','id2','id3'];dojo.hostenv.makeWidgets().
> >
> > My problem is I can not do a such stuff in a ajaxBehavior.respond
> > because this should be done once by request and i do not have any
access
> > to the component list added to the target. On the other hand I can not
> > extends AjaxRequestTarget because If i do that I can not use AjaxLink
or
> > other Ajax* to re-render a Dojo Component.
> >
> > So I thought to add a listener on AjaxRequestTarget that should be
> > called after respondComponent in respondComponents method such as a
> > IAjaxResponseListener with a onRender(Map/* 
> > */markupIdToComponent, AjaxRequestTarget target) method.
> >
> > Have you a better idea and WDYT about listener?
> >
> > thanks a lot
> >
> > --
> > Vincent
> >
>
>




Re: adding a listener to the AjaxRequestTarget

2007-01-23 Thread Igor Vaynberg

i agree its not seamless and can be improved on, perhaps you should open an
rfe to have ajaxrequesttarget properly handle behaviors that implement
iheadercontributor, but for now you can use the below (off the top of my
head)


class OnLoadJavasctiptBehavior extends AbstractBehavior implements
IHeaderContributor {
 private final IModel javascript;

 public OnLoadJavascriptBehavior(IModel javascript) {
this.javascript=javascript; }
 public void detachmodel() { javascript.detach(); }

private boolean isajaxrequest() {
return RequestCycle.get().getRequestTarget instanceof
AjaxRequestTarget; }

// emit javascript into  header during regular render
void renderHead(IHeaderResponse response) {
if (!isajaxrequest()) {
response.writejavascript("registereevent(window, "load",
"function() { "+javascript.getobject()+"}"));
}
}

   // emit javascript into ajax request target during ajax render
   void onRendered() {
  if (isajaxrequest()) {
   AjaxRequestTarget t=RequestCycle.get().getRequestTarget();
  t.appendjavascript(javascript.getobject());
  }
 }
}

-igor



On 1/23/07, James McLaughlin <[EMAIL PROTECTED]> wrote:


You're right, he is talking about something else :) Since you can add a
Behavior to multiple components, maybe Vincent can create a Behavior to do
this. If he does this, then he can share my problem :)

So back to my problem... I need something more than window.onload, I
think.
Wicket already has very sophisticated script block handling in wicket-ajax
where the insertion order of script and other dom is preserved in the
evaluation order. It would be great if Behaviors could take advantage of
this, since they are the primary way of inserting script with wicket.
However, i think Behaviors were created pre wicket-ajax and are therefore
somewhat Page rendering centric in their design. window.onload is also
page
rendering specific. I'm talking about having Behaviors bridge the ajax and
page rendering worlds through some form of adaptation. This way, if the
Behavior was Page rendered, it could add itself to the window.onloadqueue,
if ajax rendered, it can put itself in the appropriate place in the xml
envelope and wicket-ajax takes care of the rest. The rest of wicket is
really seamless in its ajax/page rendering support, but this is one place
that isn't.

thx,
jim

On 1/23/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>
> i think he is talking about something a bit different
>
> what you want can be accomplished by using a bit of javascript foo
>
> http://ejohn.org/projects/flexible-javascript-events/
>
> you can use that func to register a bunch of window.onload events that
> execute once the html has been rendered. we were discussing about
> implementing that as part of wicket to have nice serverside api support
> for
> it, but havent had the time yet. matej?
>
> -igor
>
>
> On 1/23/07, James McLaughlin <[EMAIL PROTECTED]> wrote:
> >
> > I ran into this issue a while back and proposed an IOnLoadContributor
> > interface that kind of mirrors all the good work of
IHeaderContributor,
> > but
> > for script that is inserted anywhere below , such as onload, or
> > script blocks in the actual body.
> > http://www.nabble.com/rfc-OnLoadContributor-tf2609406.html#a7282114
> >
> > I'm getting around it now by having my Behaviors check the Target type
> in
> > onRendered, which works great for Ajax requests. For non-ajax, you
need
> to
> > worry if the script block will end up in a place that isn't cool for
ie.
> >
> > On 1/23/07, Vincent Demay <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi all,
> > >
> > > When I re-render a Dojo widget via an ajaxRequestTarget, I have to
add
> > > some javascript to the request depending on which widget(component)
> has
> > > been added to the target. This javascript should be added in order
to
> > > re-parse new DojoWidget (from the ajax response) with dojo API. This
> > > kind of parsing should only be done on top level Dojo component
> because
> > > during parsing sub-dojo-components will be automaticaly parsed.
> > >
> > > Actually what I need to do is  :
> > >
> > > before sending response
> > > 1 - looking for all component added to the target
> > > 2 - for all top-level Dojo components :
> > >Adding its id to a map
> > > 3 - adding a js such as
> > >
> > > djConfig.searchIds = ['id1','id2','id3'];dojo.hostenv.makeWidgets().
> > >
> > > My problem is I can not do a such stuff in a ajaxBehavior.respond
> > > because this should be done once by request and i do not have any
> access
> > > to the component list added to the target. On the other hand I can
not
> > > extends AjaxRequestTarget because If i do that I can not use
AjaxLink
> or
> > > other Ajax* to re-render a Dojo Component.
> > >
> > > So I thought to add a listener on AjaxRequestTarget that should be
> > > called after respondComponent in respondComponents method such as a
> > > IAjaxResponseListener with a onRender(Map

Re: adding a listener to the AjaxRequestTarget

2007-01-23 Thread James McLaughlin

Will do. Looks good, but I think it needs to be baked in further up the
hierarchy, so that any behavior can make its contribution without regard as
to whether it is rendered in a ajax request or page request.

thanks,
jim

On 1/23/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:


i agree its not seamless and can be improved on, perhaps you should open
an
rfe to have ajaxrequesttarget properly handle behaviors that implement
iheadercontributor, but for now you can use the below (off the top of my
head)


class OnLoadJavasctiptBehavior extends AbstractBehavior implements
IHeaderContributor {
  private final IModel javascript;

  public OnLoadJavascriptBehavior(IModel javascript) {
this.javascript=javascript; }
  public void detachmodel() { javascript.detach(); }

 private boolean isajaxrequest() {
 return RequestCycle.get().getRequestTarget instanceof
AjaxRequestTarget; }

 // emit javascript into  header during regular render
 void renderHead(IHeaderResponse response) {
 if (!isajaxrequest()) {
 response.writejavascript("registereevent(window, "load",
"function() { "+javascript.getobject()+"}"));
 }
 }

// emit javascript into ajax request target during ajax render
void onRendered() {
   if (isajaxrequest()) {
AjaxRequestTarget t=RequestCycle.get().getRequestTarget();
   t.appendjavascript(javascript.getobject());
   }
  }
}

-igor



On 1/23/07, James McLaughlin <[EMAIL PROTECTED]> wrote:
>
> You're right, he is talking about something else :) Since you can add a
> Behavior to multiple components, maybe Vincent can create a Behavior to
do
> this. If he does this, then he can share my problem :)
>
> So back to my problem... I need something more than window.onload, I
> think.
> Wicket already has very sophisticated script block handling in
wicket-ajax
> where the insertion order of script and other dom is preserved in the
> evaluation order. It would be great if Behaviors could take advantage of
> this, since they are the primary way of inserting script with wicket.
> However, i think Behaviors were created pre wicket-ajax and are
therefore
> somewhat Page rendering centric in their design. window.onload is also
> page
> rendering specific. I'm talking about having Behaviors bridge the ajax
and
> page rendering worlds through some form of adaptation. This way, if the
> Behavior was Page rendered, it could add itself to the
window.onloadqueue,
> if ajax rendered, it can put itself in the appropriate place in the xml
> envelope and wicket-ajax takes care of the rest. The rest of wicket is
> really seamless in its ajax/page rendering support, but this is one
place
> that isn't.
>
> thx,
> jim
>
> On 1/23/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> >
> > i think he is talking about something a bit different
> >
> > what you want can be accomplished by using a bit of javascript foo
> >
> > http://ejohn.org/projects/flexible-javascript-events/
> >
> > you can use that func to register a bunch of window.onload events that
> > execute once the html has been rendered. we were discussing about
> > implementing that as part of wicket to have nice serverside api
support
> > for
> > it, but havent had the time yet. matej?
> >
> > -igor
> >
> >
> > On 1/23/07, James McLaughlin <[EMAIL PROTECTED]> wrote:
> > >
> > > I ran into this issue a while back and proposed an
IOnLoadContributor
> > > interface that kind of mirrors all the good work of
> IHeaderContributor,
> > > but
> > > for script that is inserted anywhere below , such as onload,
or
> > > script blocks in the actual body.
> > > http://www.nabble.com/rfc-OnLoadContributor-tf2609406.html#a7282114
> > >
> > > I'm getting around it now by having my Behaviors check the Target
type
> > in
> > > onRendered, which works great for Ajax requests. For non-ajax, you
> need
> > to
> > > worry if the script block will end up in a place that isn't cool for
> ie.
> > >
> > > On 1/23/07, Vincent Demay <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > When I re-render a Dojo widget via an ajaxRequestTarget, I have to
> add
> > > > some javascript to the request depending on which
widget(component)
> > has
> > > > been added to the target. This javascript should be added in order
> to
> > > > re-parse new DojoWidget (from the ajax response) with dojo API.
This
> > > > kind of parsing should only be done on top level Dojo component
> > because
> > > > during parsing sub-dojo-components will be automaticaly parsed.
> > > >
> > > > Actually what I need to do is  :
> > > >
> > > > before sending response
> > > > 1 - looking for all component added to the target
> > > > 2 - for all top-level Dojo components :
> > > >Adding its id to a map
> > > > 3 - adding a js such as
> > > >
> > > > djConfig.searchIds =
['id1','id2','id3'];dojo.hostenv.makeWidgets().
> > > >
> > > > My problem is I can not do a such stuff in a ajaxBehavior.respond
> > > > because this shou

Re: adding a listener to the AjaxRequestTarget

2007-01-24 Thread Vincent Demay

Igor Vaynberg a écrit :
do you really think it is necessary to call the listener for each 
component

rendered?
why not

IAjaxResponseListener { beforeResponse(map, target); } 


the problem i see with callbacks during the render is that
target.prependjavascript will no longer have any effect and can be
confusing.

with beforeresponse listener you can still use the full facilities of the
target

Yes, you're this kind of listener is exactly what I need


so what you would do is traverse the components, build the javascript, 
and
use target.appendjavascript() to have it output once all the 
components have

been updated.

make sense or did i miss the point?

Yes, exactly


if you _do_ need it to be called _during_ the rendering then we will 
have to
extract an interface from the target that only has prependjavascript() 
and

you will only get that in the listener instead of the target itself.

you means appendJavascript ?


If we make a listener such as

IAjaxResponseListener {
  
   /**

* Triggered at the very beggining of respond method
*/
   beforeResponse(map, target);
   // here we can use all target method

   //and why not
   /**
* Triggered before
* it = appendJavascripts.iterator();
* while
*
* reduicing the scope will be done with an Interface giving only 
appendJavascript

*/
afterResponse(map, targetWithReduceScope);
}

I do not need the second method but it could be usefull for others

WDYT?

Thanks



-igor


On 1/23/07, Vincent Demay <[EMAIL PROTECTED]> wrote:


Hi all,

When I re-render a Dojo widget via an ajaxRequestTarget, I have to add
some javascript to the request depending on which widget(component) has
been added to the target. This javascript should be added in order to
re-parse new DojoWidget (from the ajax response) with dojo API. This
kind of parsing should only be done on top level Dojo component because
during parsing sub-dojo-components will be automaticaly parsed.

Actually what I need to do is  :

before sending response
1 - looking for all component added to the target
2 - for all top-level Dojo components :
   Adding its id to a map
3 - adding a js such as

djConfig.searchIds = ['id1','id2','id3'];dojo.hostenv.makeWidgets().

My problem is I can not do a such stuff in a ajaxBehavior.respond
because this should be done once by request and i do not have any access
to the component list added to the target. On the other hand I can not
extends AjaxRequestTarget because If i do that I can not use AjaxLink or
other Ajax* to re-render a Dojo Component.

So I thought to add a listener on AjaxRequestTarget that should be
called after respondComponent in respondComponents method such as a
IAjaxResponseListener with a onRender(Map/* 
*/markupIdToComponent, AjaxRequestTarget target) method.

Have you a better idea and WDYT about listener?

thanks a lot

--
Vincent







Re: adding a listener to the AjaxRequestTarget

2007-01-24 Thread Igor Vaynberg

On 1/24/07, Vincent Demay <[EMAIL PROTECTED]> wrote:


> if you _do_ need it to be called _during_ the rendering then we will
> have to
> extract an interface from the target that only has prependjavascript()
> and
> you will only get that in the listener instead of the target itself.
you means appendJavascript ?


yes, my bad :)


If we make a listener such as

IAjaxResponseListener {


[..]

sounds fine, do you need this in 2.0 only or 1.3 as well?

-igor


Re: adding a listener to the AjaxRequestTarget

2007-01-24 Thread Vincent Demay

Igor Vaynberg a écrit :

On 1/24/07, Vincent Demay <[EMAIL PROTECTED]> wrote:


> if you _do_ need it to be called _during_ the rendering then we will
> have to
> extract an interface from the target that only has prependjavascript()
> and
> you will only get that in the listener instead of the target itself.
you means appendJavascript ?


yes, my bad :)


If we make a listener such as

IAjaxResponseListener {


[..]

sounds fine, do you need this in 2.0 only or 1.3 as well?

-igor

I need that in 2.0 and in 1.3 as weel, I'm currently writing this
I give you a patch as soon as I finish

Thanks

--
Vincent



Re: adding a listener to the AjaxRequestTarget

2007-01-24 Thread Igor Vaynberg

wonderful :)

-igor


On 1/24/07, Vincent Demay <[EMAIL PROTECTED]> wrote:


Igor Vaynberg a écrit :
> On 1/24/07, Vincent Demay <[EMAIL PROTECTED]> wrote:
>
>> > if you _do_ need it to be called _during_ the rendering then we will
>> > have to
>> > extract an interface from the target that only has
prependjavascript()
>> > and
>> > you will only get that in the listener instead of the target itself.
>> you means appendJavascript ?
>
> yes, my bad :)
>
>> If we make a listener such as
>>
>> IAjaxResponseListener {
>>
> [..]
>
> sounds fine, do you need this in 2.0 only or 1.3 as well?
>
> -igor
I need that in 2.0 and in 1.3 as weel, I'm currently writing this
I give you a patch as soon as I finish

Thanks

--
Vincent




Re: adding a listener to the AjaxRequestTarget

2007-01-24 Thread Vincent Demay


Ok it is done you could find a patch on jira : 
http://issues.apache.org/jira/browse/WICKET-234


Thanks for your help Igor


Igor Vaynberg a écrit :

wonderful :)

-igor


On 1/24/07, Vincent Demay <[EMAIL PROTECTED]> wrote:


Igor Vaynberg a écrit :
> On 1/24/07, Vincent Demay <[EMAIL PROTECTED]> wrote:
>
>> > if you _do_ need it to be called _during_ the rendering then we 
will

>> > have to
>> > extract an interface from the target that only has
prependjavascript()
>> > and
>> > you will only get that in the listener instead of the target 
itself.

>> you means appendJavascript ?
>
> yes, my bad :)
>
>> If we make a listener such as
>>
>> IAjaxResponseListener {
>>
> [..]
>
> sounds fine, do you need this in 2.0 only or 1.3 as well?
>
> -igor
I need that in 2.0 and in 1.3 as weel, I'm currently writing this
I give you a patch as soon as I finish

Thanks

--
Vincent