[jira] [Resolved] (WICKET-3073) Apply AjaxCallDecorator just like AjaxIndicators are

["Martin Grigorov (Resolved) (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov resolved WICKET-3073.
-------------------------------------

       Resolution: Won't Fix
    Fix Version/s:     (was: 6.0.0)

This functionality is possible to do without any changes in Wicket's core.
IAjaxCallDecorator's methods receive the Component as parameter. You can check whether it implements any custom interface and extract the extra JS code from it, like in your patch and then use it in the decorator.

The same is valid in Wicket 6.0's IAjaxCallListener.
                
> Apply AjaxCallDecorator just like AjaxIndicators are
> ----------------------------------------------------
>
>                 Key: WICKET-3073
>                 URL: https://issues.apache.org/jira/browse/WICKET-3073
>             Project: Wicket
>          Issue Type: New Feature
>          Components: wicket
>    Affects Versions: 1.4.12
>            Reporter: David Shepherdson
>         Attachments: fix-WICKET-3073.patch
>
>
> AbstractDefaultAjaxBehavior has a nice feature for AJAX indicators, in that it will look up the component hierarchy for something that implements IAjaxIndicatorAware, so you can control how AJAX progress is displayed depending on where the behaviour is used.
> AbstractDefaultAjaxBehavior has another nice feature whereby you can specify an AjaxCallDecorator to add extra JavaScript to the AJAX code generated by the behaviour, so that you can control what happens whenever an AJAX request is made to the behaviour.
> These features are both nice on their own, but they have some limitations. The problem with AJAX indicators is that all you can do is show or hide an element; you can't do anything else (like call a function or change CSS styles). The problem with AjaxCallDecorators is that they have to be defined in the behaviour itself, and therefore can't change depending on where the behaviour is used.
> It would be really useful if the advantages of these two features could be combined, so that the AjaxCallDecorator could be defined by components further up in the component hierarchy. That way you can achieve more than just showing/hiding an element when AJAX request are made, and you can define it in a way that is dependent on where the behaviour is used, not on the definition of the behaviour itself.
> To that end, here is a patch that adds a new interface, called IAjaxCallDecoratorAware. This interface is based on the same principle as IAjaxIndicatorAware, but for providing an AjaxCallDecorator rather than an indicator's markup id. The patch also makes a few changes to AbstractDefaultAjaxBehavior so that it will look for an implementation of IAjaxCallDecoratorAware in the component's hierarchy, before defaulting to the decorator returned by the existing getAjaxCallDecorator() method.
> I've attempted to write the patch in such a way that existing code, which doesn't use or even know about IAjaxCallDecoratorAware, will continue to work in exactly the same way as it does now.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira