[
https://issues.apache.org/jira/browse/WICKET-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Vaynberg updated WICKET-3073:
----------------------------------
Fix Version/s: 1.6.0
scheduling this for 1.6.0 which will contain ajax rewrite
> 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
> Fix For: 1.6.0
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
