[
https://issues.apache.org/jira/browse/WICKET-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798774#comment-13798774
]
Igor Vaynberg commented on WICKET-5297:
---------------------------------------
what we need to do is bake this into core, the idea is that we can specify a
javascript function that handles component replacement when we add it to the
target. this function has a callback that when called performs the replacement.
so the default impl of this function is to just call the callback immediately -
which is a noop. the animation then can look like this:
function animateComponent(tag, replaceInDom) {
var t=$("#"+tag);
t.fadeOut({complete: function() { replaceInDom(); t.fadeIn(); }});
}
then we can run all prepended-javascript
run all replacements asynchronously
wait for them all to finish
run all header contributions
run all appended-javascript
the downside is that its possible the flicker of markup that needs to be
enhanced will be longer because it wont happen until the last animation. to
solve this we can track which header contribution comes with which component,
and run it after the component animated.
in fact, we can have variants of append and prepend javascript that are also
tied to component which can become part of its async pipeline...
> Animate ajax DOM manipulation smoothly
> --------------------------------------
>
> Key: WICKET-5297
> URL: https://issues.apache.org/jira/browse/WICKET-5297
> Project: Wicket
> Issue Type: Improvement
> Reporter: Antti Lankila
> Assignee: Martin Grigorov
> Priority: Minor
> Labels: ajax
> Attachments: wicket6-replace-with-effect.tgz,
> wicket6-replace-with-effect.tgz, wicket6-replace-with-effect.tgz
>
>
> Wicket should have an easy hands-off way to animate most changes which occur
> when ajax requests get new HTML data to visualize in the markup. For
> instance, the content within the element (if any) could fade or shrink away,
> and new content would replace it, taking its place.
> The animations should be as minimal as possible, but noticeable enough that
> the user can see them occurring. I'd suggest at least two types of
> animations: fade-ins and resizes.
> - In fade animation, the old panel would have its opacity decrease until it
> becomes invisible, and the new content would then take its place. In case the
> old panel was just a placeholder, only the fade-in of the new content occurs.
> This type of animation would be suitable for alert box like elements which
> occur in the middle of the screen or otherwise are detached from the page
> flow.
> - In resize animation, JavaScript code should measure the dimensions of the
> old panel (about to go away) and the new panel (about to replace it). During
> animation, the old panel would be kept in its place, but its dimensions would
> be adjusted from the old values to the new values through manipulating its
> width and height using linear interpolation, and then an instantenous switch
> would replace the old content with the new content when the new dimensions
> have been reached. If the old panel was just a placeholder, the animation
> would resize the content of the new panel instead. This type of animation
> would be most suitable for elements in the page flow.
> User should be able to control the duration and type of the animation, and
> whether animation is applied by default via settings. In addition to that,
> the animation parameters should be controllable per ajax request.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
