When a transitional animation is used, it should have a lasting effect on the component. So, say we have the appear animation. We'll need some way of specifying that initially the component should not be appearing, and then after the transition, some way of specifying that it should remain appearing. And most importantly, if some server interaction causes that part of the page to update, and the component's markup to be updated, the state should be consistent, and not have been lost, and supplanted with some other server state that is not in sync.

If, with the appear example, we were to manually style the component to render, but not be shown, then after the appear does happen, any server update would cause the non-showing component state to again be depicted in the browser, which would be incorrect.

If we added a server notification upon appearing, then the application could then stop rendering itself as non-showing. But this would have the overhead of a server round-trip, and could make the component flicker as it redundantly renders itself as showing, since it was already showing after the animation occurred. This might be necessary if the application is doing server pushes, but would not be desirable if there were no server pushes. Since the animation has a duration, then the server pushes that occur during the duration would be either reverting the component to not being shown, or to being fully shown, depending on whether the animation server notification happened at the end of the animation or the beginning of the animation. As well, this would involve manual application code, to know about which CSS styling is the opposite of appear, and when the apply it or not.

Firstly, we should solve the manual problem. Instead of the application being involved, it should merely set a property on the ace:animation tag to say that it would like the component's initial rendering to be the opposite of the effect. That is, for appear, it should initially not be shown, and for hide, it should initially be shown. Then, before the animation has been triggered, the animation tag itself should affect the component's rendering, so that it uses the proper styling specific to the animation type. Potentially this would be done by setting the style class to the appear_from style class. This would allow for the skinning and skin overriding to work properly. Then, when the animation has triggered, it would setup some hidden input field, which it would decode, to tell itself to now render the style class to be the appear_to style class. The reason why this happens on the server, and not just in the client, is that there's a latency involved for the javascript to execute, so if the showing and hiding was done only in the client, you would have the component be shown for a second or so, then be hidden. The flickering would be kludgey. The next time there's a server interaction, the hidden form field would be submitted, and the next rendering would be in sync with the new client state.

If there are server pushes, or even if there are multiple forms (if another form, that does not contain the animation's hidden input field, is submitted, that lifecycle can cause the whole page, or any part of the page to update, even outside of that form), then we could have the component's markup updated without the hidden input field having updated things. So, we might want to have a singleSubmit (execute just the animation tag, and render the component) on the animation tag, so that it will update the server state right away. This won't address the duration issue, so we'll have to put some though into that. It might be advantageous, in the animation singleSubmit, to have some means for the dom to be updated wit the new markup, so that future dom differences will take it into account, but somehow not send that update to the client, for that one lifecycle.