Phoenix ?s

[viatropos]

Hey Ben,

I am wondering when the Phoenix framework will be ready for
experimentation. It looks like it's going to replace Flex which is
awesome, there's lots in Flex that needs to be redone, and I'm stoked
to start messing around with your project.

Some things I thought I might throw out there to include in your piece
are handling hierarchical states, customizing the drag/drop animations
by removing the animation logic out of the DragProxy, and adding a
"tweens" property to the core component and an animate() method so you
could, in MXML, pass in array of tween tokens and run them by saying
"click='{component.animate()}'".

For the hierarchical states, there's this project which looks fairly
interesting:

http://code.google.com/p/troyworks/
http://code.google.com/p/troyworks/source/browse/trunk/AS3/dev/src/com/troyworks/core/cogs/Hsm.as

Something that I'm finding is never talked about in the actionscript
world at all is synchronizing animations from disparate parts of the
applicaiton. In order to do this, components need to know what
animations (from parent or child components or components outside of
its own hierarchy) should be run first, which should be run during,
and which should be run after, without having to hardcode delays and
such. Having logic built into the core component saying "only animate
this component after it's received its 8 required
OtherComponentAnimationEvent.COMPLETE events" (these events being
wired in as needed in MXML) would allow you to build applications that
interact with the user like something living would. The application
would feel more alive.

Also, it seems like the Layout classes could have more included. I've
modified the ILayout implementation so the "update()" method wasn't so
hardwired to a specific animation: instead the layout algorithm in the
update method should be extracted out and be the grounding/anchoring
point of the layout that you can modify or animate into/out of easily
at runtime. You could have something like a "layoutAlgorithm()"
method that provided the base algorithm to lay the items out in a
Carousel or Coverflow or whatever, maybe even only doing it to one
item at a time (i.e "layoutAlgorithm(layoutItem)". Then you could
have a for loop run through that.

Finally, there is a way to construct UI interactions with the layout
like a state machine, providing the developer with a space for running
INTRO, AMBIENT, SELECTED, and OUTRO animations on the layout without
having to hardcode those things into individual implementations
(because that is the point in extracting out the layout in the first
place). By encapsulating the transitions between these discrete
layout phases (and having the ability to dynamically add more if
needed), you can create some really cool layout effects very easily.
And that "layoutAlgorithm()" method would be the grounding point from
which you could animate items in and out and do some great enter frame
effects, but you wouldn't be tied to hacking around the "update()"
method to accomplish that which I'm finding myself do a ton.

Just some ideas.

Cheers,
Lance

[Ryan Campbell]

Hey Lance,

The goal is to have the Phoenix branch (along with the rest of the framework) stable and documented for May. We've made some great progress so far and I've even been able to compile a basic application as small as 94kb (including the framework, not using RSLs). You'll be able to use OpenFlux components with or without Flex.

Those are some great ideas. We'd love if you'd be able to contribute to the project. It sounds like you have some code you could possibly contribute already. If so, let Ben know and he can add you to the project.

Thanks,

Ryan

[Patrick Lemiuex]

Looking forward...  Will virtualized collections be there?

Sent from my iPhone