[ 
https://issues.apache.org/jira/browse/WICKET-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13789229#comment-13789229
 ] 

Sven Meier commented on WICKET-5297:
------------------------------------

@Martin Thanks for the update.

There are still some nitpicks I have though:
- reordering of effects is now baked into AjaxRequestHandler and depends on 
Effect implementing CharSequence (kudos for this trick)
- CSS animations don't have a configurable duration, so sorting of effects on 
the server is not sufficient (you've tricked this with minute durations in 
AnimateCssEffects)
- if multiple effect-outs with different durations are used, the shortest one 
will have to wait for the longest one to finish. This might result in possibly 
layout errors, because the removed element is not immediately substituted with 
the new element and its effect-in.

If we really want to offer more than just convenience for #prependJavascript() 
and #appendJavascript() *and* we change AjaxRequestHandler anyway, couldn't we 
support asynchronous component replacement?
Each component's effect-out, replace and effect-in should be done as a single 
unit of work, with loadedCallback() waiting for all components to be processed
BTW a configurable default replace animation for AjaxRequestHandler would be 
nice too.

I'll try to put my ideas into code.

> 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)

Reply via email to