Flex 4 and OpenFlux

[viatropos]

Hey,

I've been really learning a lot from OpenFlux's code, thanks so much
for open sourcing it. There's a lot of gems in there and it's really
great to see how good frameworks are built. Looking into Flex 3's
code, it's insane compared to this, thankfully this is changing.

My question is, are you guys who wrote OpenFlux involved in
architecting Flex 4? I'm asking because these two projects are a lot
alike but it looks like you guys could help each other, and maybe it
can all be combined and reshaped into one project.

The thing I really like about Flex 4 are the skins and how the
graphics are separated from the component. It is extremely clear and
I think will be really easy for people to learn. In OpenFlux, with
the FluxView, it seems like this is somewhat happening, but the
distinction between View and Component is kind of blurry to me at this
point. The FluxView is a FluxContainer that's applied to a
FluxComponent, but the FluxComponent then becomes wrapped by that
FluxView/FluxContainer, and the Container calls the Layout things to
happen. It's kind of confusing and if you really wanted to leverage
OpenFlux you'd have to rewrite all your components as extending
FluxView it seems, because I haven't got it to work yet using regular
old Flex components. Flex 4, on the other hand, has Skins and
Components. So that makes it easy.

The thing I really like about OpenFlux are the layouts and how the
layouts and animations are separate from the Container component.
This is extremely clear and very well architected in my opinion. In
Flex 4, the Layouts handle a lot of the animation, but some of their
logic is also handled in the FxContainer class, tying them too closely
to the Component, which isn't a good idea for future modularity. In
OpenFlux, on the other hand, all the FluxContainer does is call
"layout.update", that's really awesome, and the Layout handles how to
move the components/layout items. OpenFlux really separates out the
Layout functionality from the containers, so things like Lists can
have any of an infinite number of layouts.

I also like how States are handled in Flex 4, only in terms of how the
FxComponent assigns the skin's state, not necessarily in the inline
state syntax (which I think will get crazy). On a side note, if both
OpenFlux and Flex 4 integrated states into their layouts (mimicking
the way FxComponent changes skin states), that would be amazing.

So I'm wondering what the plan is. These projects are so alike that
they can basically be merged. That is to say, "rock on" OpenFlux
developers for building what a team of Flex developers are doing
before them. But I'm also saying, both of these projects have certain
parts that are better implemented than others, so maybe they can be
merged. I understand some of the philosophies are different between
the two, such as how the Model/Component, View, and Controller
functionality is separated out, but it seems like a hybrid approach
between OpenFlux and Flex 4 would be powerful.

What do you think?

Best,
Lance

[Ben Stucki]

Hi Lance,

Thanks for the kind words. We aren't involved with architecting Flex 4 at all, but I feel like we do have a pretty open line of communication if we need it and I know that some Flex team members are keeping an eye on the project. A lot of the work that we've done in OpenFlux was directly inspired by the ideas going into Flex4, but because we're a community based project I think we get to take the purist approach a lot further. Like you've already mentioned, this is something that's pretty apparent when you compare the two approaches to layout. Ours is much more separated from the container and even the animation, but as others have mentioned it isn't entirely complete yet either. I think that speaks to what we're doing differently. Although there's certainly something to be said for stuff not getting done because we're only working on OpenFlux in our spare time, it's also because we're not just coding to feature specs. We're agonizing over compromises in separation and simplicity, and we're able to leave some pieces missing until we come up with the right solution for it architecturally. So, although I don't expect OpenFlux to be rolled into Flex4 or anything, I do hope that we are able to contribute back to Adobe by sparking discussions about the architecture both internally and in the community.

- Ben Stucki

http://blog.benstucki.net

http://www.audiospike.com

[Michael Schmalle]

Hi Lance,

> On a side note, if both
OpenFlux and Flex 4 integrated states into their layouts (mimicking
the way FxComponent changes skin states), that would be amazing.

I have already created an adapter to FluxComponent that does this (changes states based on subclass (model) override).

> invalidateViewState() basically

What do you mean if the layouts changed state? Can you give an example?

Mike

PS Ben, I getting close to showing you some really kewl stuff I have done. BTW I proted BasicLayout to the ConstraintLayout, now works with percentages and left right stretches etc. Works like it should now. :)

--
Teoti Graphix, LLC
http://www.teotigraphix.com

Teoti Graphix Blog
http://www.blog.teotigraphix.com

You can find more by solving the problem then by 'asking the question'.

[viatropos]

Hi Mike,

I was thinking that when designing a custom layout class, you could do
the following that would allow you to tie layout states to custom view
states in a custom component:

1) What are "layout states"? When you first outline/design your
layout (all the math and how things are position, etc.), you'd start
by saying "what are the different states the objects in this layout
might have?"
- In the CoverFlowLayout, just thinking off the top of my head,
an item in the coverflow can be "selected", "unselected", and maybe
you could even add "hidden" or "last" if you wanted to change the way
coverflow items looked x many items past the selected one.

2) Now that you have the "layout states", you create simple variables
for them in the CoverFlowLayout class:
selectedState:String; // (haven't thought of the best way to do this
yet, maybe just strings, maybe booleans, maybe the binding tag?

3) In your CustomComponent.mxml class, say you have
"myImageDetailsState" and "myImageThumbState". You could, in the
CoverFlowLayout tag of an OpenFlux List, do something like this to
assign your state names to the layout state names:

<CoverFlowLayout mapToStates="{selectedState:"myImageDetailsState",
unselectedState:"myImageThumbState"}"/>

4) Then in the update() or adjust() method (wherever the animation
logic goes), you could set the "child" component to that whatever
state it is in in the layout, which would automatically be tied into
your component's state.
- This would make it so that when a coverflow item was selected,
the "selectedState" variable would be assigned to the selectedIndex
component. Flex 4 does something like this with skins, in the
commitProperties method of FxComponent:

if (skinStateIsDirty)
(
skin.currentState = getCurrentSkinState();
skinStateIsDirty = false;
)

I was thinking you could do a similar thing for layouts. This if-loop
in the adjust() method for CoverFlowLayout might look like this:

if(i < selectedIndex) {
token.x *= -1;
token.rotationY *= -1;
child.currentState = unselectedState; // change the state of all non-
selected layout items to display a small image...
} else if(i == selectedIndex) {
token.x = 0;
token.z = -200 / 2;
token.rotationY = 0;
offset = 0;
child.currentState = selectedState; // selected item shows extra text
fields and some buttons...
}

4) So you have these generic "states for the layout" variables that
can be assigned to any state in your component. This is nice so you
don't have to call your component's state "selectedState", you can
call it "myImageDetailsState" or whatever and assign it to the
"selectedState" variable of the CoverFlowLayout.

For other layouts, like the ProductCatalogPanel and its hardwired
layout in FlexStore for instance, they switch between 1, 2, 3, and 4
columns, making the Thumbnail view display different elements in
each. So in a DynamicColumnLayout, you could have the
"oneColumnState", "twoColumnState", etc. Then you just assign your
component's states to those and it takes care of everything for you!

It just seems like it would give you some more control over the layout
which would be nice.

Hope that helps!

Best,
Lance

> Teoti Graphix Bloghttp://www.blog.teotigraphix.com
>
> You can find more by solving the problem then by 'asking the question'.- Hide quoted text -
>
> - Show quoted text -