Work Spec: SC.TransitionView or SC.ContainerView addition #868

Closed
publickeating opened this Issue Nov 20, 2012 · 10 comments

Projects

None yet

3 participants

@publickeating
Owner

Rationale

A large number of web applications at some point want to animate between views, which means developers spend a lot of time re-creating the same effects with sometimes mixed results. SC.ContainerView simply swaps views and SC.SceneView does allow a basic animated swap, but it is very limited and not optimized for HW acceleration (see Issue #20).

Description

A replacement for SC.SceneView, should support multiple types of animated swaps, such as push, move in, reveal and dissolve. It should be very easy to change the transition type by setting a single property on the view and it should be very easy to modify the transition animation by passing appropriate options to the view.

As well, developers should be able to plug in their own transition animations for more advanced transitions. For example, I could create a transition engine that fades as it pushes and then supply that to the view to use.

Acceptance Criteria

  • may be an addition to SC.ContainerView or a subclass of it (SC.TransitionView)
  • must support multiple transitions
  • must include multiple built-in transitions: push, move in, reveal, dissolve, fade through color
  • must have a pluggable transition architecture
  • must include SC.Transition protocol that transition engines will be based on
  • must use SC.View:animate
  • must include full suite of unit tests
  • must include a demo on http://showcase.sproutcore.com
  • must include a guide on http://guides.sproutcore.com
Owner

I'm nearly done this, but the question is: build it into SC.ContainerView or use a subclass, SC.TransitionView?

Owner

I vote subclass for clarity's sake – in the class hierarchy, documentation, and presumably the code itself.

Owner

As per the code change, because the transition plugins do all the setup, animation and teardown, the change to SC.ContainerView is very minor. Essentially, look for transition property, if none, then do as normal, but if found call 3 methods on the transition object: setup, run, teardown.

I originally thought subclass, but now I'm less inclined. I'm starting to lean towards fewer views/controls that can do more, because it's less for the new developer to search through.

Owner

Okay nice architecture work on the code then.

Regarding the documentation and newbie brainspace question, I think it's not a matter of how many things you have, but making sure that the concepts are very clearly separated. For example, I would have split the editable label into a subclass of LabelView rather than building it into the class. "Thing that displays text" and "thing that the user puts text into" feel different enough to me that a new developer might come at them from two different-enough directions to warrant a subclass.

From that perspective I think there's a small difference between "view which shows one of a couple of views" and "view which animates gracefully between views" ... but the more I think about it (dangerous, since newbie developers won't have thought about it at all), the less difference I see there. So I'm all for building the transition plugins directly into ContainerView.

Owner

On one side of spectrum, SC.ContainerView could be configured to do a lot of different transition types. On the other far side, you could have multiple subclasses: SC.PushContainerView, SC.DissolveContainerView, etc. Obviously having to subclass all the time to do something becomes a nuisance.

Although I originally coded up an SC.TransitionView subclass of SC.ContainerView, I've figured out why my gut was feeling that it was wrong. SC.ContainerView already does a transition (albeit a simple swap) and if you set SC.TransitionView's transition to the null transition the two become the same. So it doesn't make sense to have a class that does a simple swap and another class that does a simple swap plus can accept plugins.

ebow commented Nov 21, 2012

+1 for part of SC.ContainerView.

On 21/11/2012, at 4:33 AM, Public Keating notifications@github.com wrote:

As per the code change, because the transition plugins do all the setup, animation and teardown, the change to SC.ContainerView is very minor. Essentially, look for transition property, if none, then do as normal, but if found call 3 methods on the transition object: setup, run, teardown.

I originally thought subclass, but now I'm less inclined. I'm starting to lean towards fewer views/controls that can do more, because it's less for the new developer to search through.


Reply to this email directly or view it on GitHub.

Owner

Pushed to master.

Had to refactor animate() and invokeNext() to do things properly and totally rewrote the new transition API from scratch, but it's really good now. Examples at: http://showcase.sproutcore.com/#ui/SC.ContainerView. See SC.TransitionProtocol to write custom transitions to use other than the defaults.

ebow commented Jan 3, 2013

Brilliant!!

Showcase looks fantastic however – "show code" seems broken for that page.

Uncaught SC.ContainerView:sc1455.removeChild(SC.LabelView:sc1456) must belong to parent

-tc

On 03/01/2013, at 1:36 PM, Public Keating notifications@github.com wrote:

Pushed to master.

Had to refactor animate() and invokeNext() to do things properly and totally rewrote the new transition API from scratch, but it's really good now. Examples at: http://showcase.sproutcore.com/#ui/SC.ContainerView. See SC.TransitionProtocol to write custom transitions to use other than the defaults.


Reply to this email directly or view it on GitHub.

Owner

Thanks, I believe it's all fixed now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment