your custom ajaxbehavior can implement iheadercontributor where you
can do response.appendjavascript to output a script that will be
processed in both regular requests and ajax requests alike.
-igor
On Sun, Jun 14, 2009 at 8:44 AM, Stefan Lindner<lind...@visionet.de> wrote:
> Just playing around with current wicket 1.4 trunk.
> Having a a page with HTML like
>
> <div wicket:id="someContainer">.......</div>
> <a wicket:id="trigger">Test</a>
>
> and java like
>
> final WebMarkupContainer container = new
> WebMarkupContainer("someContainer ");
> container.addMarkupID true;
> add(container);
>
> add(new AjaxLink<Void>(" trigger ") {
> �...@override
> public void onClick(AjaxRequestTarget target) {
> container.testAjaxRefresh(target);
> }
> });
>
> Now deploying this in an application with AjaxDebugging set to true shows
> that the markup id does NOT change when the link is clicked.
>
> BUT
>
> Having a custom AjaxBehavior added to "container" depending on some free
> javscript libraries (e.g. Dojo, jQuery), the triggers get lost after the
> original HTML contet was replaced in DOM. In other words: the Ajax response
> replaces the original element and the functionality gets lost.
>
> If the custom AjaxBehavior coud re-act in seponse tot he Ajax call and
> reinstall the behavior, the custom AjaxBehavior could take care of this. But
> I can't see where this can bedone.
>
> This happens when the behavior is configured in the head section by calling
> somthing like this (jquery)
>
> jQuery(function(){jquery('#markupID').doSomnething();});
>
> which means "after DOM has built, bind 'doSomething()' to Wicket Component
> 'markupID').
>
> If the behavior is configured in the body with a <script> section following
> the Wicket Component, this script eection is re-rendered in response to to
> the AjaxCall (in the on onComponentRendered() method) and the custom behavior
> is re-activated.
>
> Conclusion:
> If a javascript action is bound to some component and some trigger, a DOM
> replacement of this component (e.g. through an Ajax call with ing wicket via
> AjaxRequestTarget.addComponent()) diables the action and needs to be
> re-activated in the Ajax response.
>
> I don't know if this is the case in DOJO menu items (I think so when I'm
> looking at the old DOJO 0.4 implementation of drag and drop) but I see that I
> need to modify my impelmantation of jQuery integration into wicket (currently
> working on this, testet a seolution and proved it working).
>
> -----Ursprüngliche Nachricht-----
> Von: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
> Gesendet: Sonntag, 14. Juni 2009 16:43
> An: users@wicket.apache.org
> Betreff: Re: DOJO Menu Items and AJAX-Target-Components
>
> new markup id means you created new component instances. wicket does
> its best to try to preserver markup id - eg when you use replace or
> replacewith wicket will transfer new markupid of the component being
> replaced into the component it is being replaced with.
>
> if you need stable ids call setmarkupid() and propagate it to whatever
> hieararchy changes you are making. although for a menu it may help to
> use a non-volatile hierarchy since menus are usually static.
>
> -igor
>
> On Sun, Jun 14, 2009 at 7:09 AM, Stefan Lindner<lind...@visionet.de> wrote:
>> Yes! "the markup-id of wicket-component changed after ajax-refresh" as you
>> wrote.
>> I' looking for a solution for another javaxript library. Any hints from the
>> Wicket gurus?
>>
>> -----Ursprüngliche Nachricht-----
>> Von: news [mailto:n...@ger.gmane.org] Im Auftrag von Alexander Elsholz
>> Gesendet: Sonntag, 14. Juni 2009 13:44
>> An: users@wicket.apache.org
>> Betreff: DOJO Menu Items and AJAX-Target-Components
>>
>> Hi,
>>
>> i use dojo menues in my application and mostly it works fine. but when an
>> other
>> ajax-call refreshed menu's target component the menu will not be displayed.
>> it
>> seams, that the markup-id of wicket-component changed after ajax-refresh and
>> so
>> the dojo-js cannot find the menu item for this wicket-component.
>>
>> had anybody the same problem?
>>
>> when not what could be the problem?
>>
>> thanks alex
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
