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 </head>, 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/* <String,Component> > > > > */markupIdToComponent, AjaxRequestTarget target) method. > > > > > > > > Have you a better idea and WDYT about listener? > > > > > > > > thanks a lot > > > > > > > > -- > > > > Vincent > > > > > > > > > > > > > > > >