Layouts and States for complex Views
1 view
Skip to first unread message
viatropos
Nov 30, 2008, 1:59:50 AM11/30/08
to OpenFlux
Hey,
I've recently been trying to figure out how change a layout/list
item's state when it's in a specific place in the layout, such as the
selected and forward-facing item in the CoverFlowLayout. Here's the
situation:
Imagine all the components in the CoverFlowLayout are
CustomTileView.mxml's. In this CustomTileView class, there are three
states: 1) unselected (or "partOfLayout"), 2) selected, and 3)
focused. In the "unselected" state, all you see is an image. In the
"selected" state, when it is the forward-facing listitem in the
CoverFlowLayout, after tweening to the right spot, it scales a bit,
and a popup comes out, as well as a button to flip it around or
something, and maybe a title appears over the image. Finally, in the
"focused" state, it flips forward, scales up, and a bunch of text
fields that make up a simple profile or caption about the image
appear. All of this is in the CustomTileView.mxml component,
visualized from the SetProperty tags inside State tags.
If you wanted to do this normally, most people would just start adding
methods to handle the whole thing all in that mxml component. That's
definitely doable, but it's not scalable or reusable at all, and the
goal of OpenFlux is to make things scalable and reusable it seems. So
I was thinking, if Layouts in OpenFlux had a way for you to map your
component's states to specific Layout states, that would be perfect.
This would allow you to modify the animations of a layout through your
Component, which would be pretty hardcore. But this would mean the
OpenFlux layouts would have to include in the Layout classes state
variables, and these would have to be used in the update() method
somehow.
Not quite sure how to do this yet, but I was thinking something like
this would make life easy:
<views:layout>
<openflux:CoverFlowLayout
mapViewStates="{selectedIndexState:"myTileViewSelectedState",
unselectedIndexState:"myTileViewSelectedState"}"/>
</views:layout>
And you might need some way to change the way the layout works. For
example, when you select an item, maybe you want to click it again and
have it flip forward. This would mean it somehow changes the way the
layout handles events.
Anyways, just thought something like this would be really powerful
because you could put custom animations on your CustomTileView without
modifying the layout, and without having to hack together stuff in a
<mx:Script> block, which defeats the modularity purpose.
Any thoughts?
Another example is the FlexStore application's product tile list
layout component. In there, they all this complex logic in the
ProductCatalogPanel.mxml class (which is basically an advanced
TileList) to change the state of the list items (ProductThumnails).
When there are only two thumbnails, they change the state of the
ProductThumbnail to display some extra text and scale up some of the
fields, and there are two columns. When there are about 6 thumbnails,
there are three columns, and ProductThumbnail's state changes to
remove some text and add some other thing. When there are lots of
items, there are four columns and very little data is shown.
If one made an OpenFlux AdvancedTileListLayout class, and basically
made this ProductCatalog layout, you might have variables for
twoColumnState, threeColumnState, fourColumnState, selectedItemState,
and maybe a singleColumnState, and in the AdvancedTileListLayout.update
() method, set those variables throughout the animation. Then, you'd
simply do:
<views:layout>
<openflux:AdvancedTileListLayout
mapViewStates="{twoColumnState:"myTileViewTwoColumnState",
threeColumnState:"myTileViewThreeColumnState", etc......}"/>
</views:layout>
That's it for now. If this was in there, that would be very helpful.
I'll try to work on this but writing Layout classes is not my forte.
Best,
Lance
I've recently been trying to figure out how change a layout/list
item's state when it's in a specific place in the layout, such as the
selected and forward-facing item in the CoverFlowLayout. Here's the
situation:
Imagine all the components in the CoverFlowLayout are
CustomTileView.mxml's. In this CustomTileView class, there are three
states: 1) unselected (or "partOfLayout"), 2) selected, and 3)
focused. In the "unselected" state, all you see is an image. In the
"selected" state, when it is the forward-facing listitem in the
CoverFlowLayout, after tweening to the right spot, it scales a bit,
and a popup comes out, as well as a button to flip it around or
something, and maybe a title appears over the image. Finally, in the
"focused" state, it flips forward, scales up, and a bunch of text
fields that make up a simple profile or caption about the image
appear. All of this is in the CustomTileView.mxml component,
visualized from the SetProperty tags inside State tags.
If you wanted to do this normally, most people would just start adding
methods to handle the whole thing all in that mxml component. That's
definitely doable, but it's not scalable or reusable at all, and the
goal of OpenFlux is to make things scalable and reusable it seems. So
I was thinking, if Layouts in OpenFlux had a way for you to map your
component's states to specific Layout states, that would be perfect.
This would allow you to modify the animations of a layout through your
Component, which would be pretty hardcore. But this would mean the
OpenFlux layouts would have to include in the Layout classes state
variables, and these would have to be used in the update() method
somehow.
Not quite sure how to do this yet, but I was thinking something like
this would make life easy:
<views:layout>
<openflux:CoverFlowLayout
mapViewStates="{selectedIndexState:"myTileViewSelectedState",
unselectedIndexState:"myTileViewSelectedState"}"/>
</views:layout>
And you might need some way to change the way the layout works. For
example, when you select an item, maybe you want to click it again and
have it flip forward. This would mean it somehow changes the way the
layout handles events.
Anyways, just thought something like this would be really powerful
because you could put custom animations on your CustomTileView without
modifying the layout, and without having to hack together stuff in a
<mx:Script> block, which defeats the modularity purpose.
Any thoughts?
Another example is the FlexStore application's product tile list
layout component. In there, they all this complex logic in the
ProductCatalogPanel.mxml class (which is basically an advanced
TileList) to change the state of the list items (ProductThumnails).
When there are only two thumbnails, they change the state of the
ProductThumbnail to display some extra text and scale up some of the
fields, and there are two columns. When there are about 6 thumbnails,
there are three columns, and ProductThumbnail's state changes to
remove some text and add some other thing. When there are lots of
items, there are four columns and very little data is shown.
If one made an OpenFlux AdvancedTileListLayout class, and basically
made this ProductCatalog layout, you might have variables for
twoColumnState, threeColumnState, fourColumnState, selectedItemState,
and maybe a singleColumnState, and in the AdvancedTileListLayout.update
() method, set those variables throughout the animation. Then, you'd
simply do:
<views:layout>
<openflux:AdvancedTileListLayout
mapViewStates="{twoColumnState:"myTileViewTwoColumnState",
threeColumnState:"myTileViewThreeColumnState", etc......}"/>
</views:layout>
That's it for now. If this was in there, that would be very helpful.
I'll try to work on this but writing Layout classes is not my forte.
Best,
Lance
Patrick Lemiuex
Nov 30, 2008, 9:45:09 AM11/30/08
to open...@googlegroups.com
Man, I am on the road sorry about the misspellings...
On Sun, Nov 30, 2008 at 6:44 AM, Patrick Lemiuex
<patrick...@gmail.com> wrote:
> Lance,
>
> I am using a type of stateMachine pattern that I call a
> viewStateMachine, I set the layout from inside a switch insisde each
> state object. The state is set by my application, and it propagets
> to the system with events. I prefer more simple type objects, state
> objects, when my app changes state, i just set the style on my
> layouts. I am using a bunch of different layouts like you.. I like
> your idea, i think the layout classes need a little more to be fully
> baked... like the ability to know when a whole list has been rendered
> etc.
>
> Sounds like you are doing a lot with products, do you have any need
> for scrolling a virtualized collecton with these? I do. If you want i
> can send you an example of what I have done. it's pretty easily
> actually.
>
> Thanks,
> Patrick
On Sun, Nov 30, 2008 at 6:44 AM, Patrick Lemiuex
<patrick...@gmail.com> wrote:
> Lance,
>
> I am using a type of stateMachine pattern that I call a
> viewStateMachine, I set the layout from inside a switch insisde each
> state object. The state is set by my application, and it propagets
> to the system with events. I prefer more simple type objects, state
> objects, when my app changes state, i just set the style on my
> layouts. I am using a bunch of different layouts like you.. I like
> your idea, i think the layout classes need a little more to be fully
> baked... like the ability to know when a whole list has been rendered
> etc.
>
> Sounds like you are doing a lot with products, do you have any need
> for scrolling a virtualized collecton with these? I do. If you want i
> can send you an example of what I have done. it's pretty easily
> actually.
>
> Thanks,
> Patrick
Patrick Lemiuex
Nov 30, 2008, 9:44:34 AM11/30/08
to open...@googlegroups.com
Lance,
I am using a type of stateMachine pattern that I call a
viewStateMachine, I set the layout from inside a switch insisde each
state object. The state is set by my application, and it propagets
to the system with events. I prefer more simple type objects, state
objects, when my app changes state, i just set the style on my
layouts. I am using a bunch of different layouts like you.. I like
your idea, i think the layout classes need a little more to be fully
baked... like the ability to know when a whole list has been rendered
etc.
Sounds like you are doing a lot with products, do you have any need
for scrolling a virtualized collecton with these? I do. If you want i
can send you an example of what I have done. it's pretty easily
actually.
Thanks,
Patrick
On Sat, Nov 29, 2008 at 10:59 PM, viatropos <lancej...@gmail.com> wrote:
>
I am using a type of stateMachine pattern that I call a
viewStateMachine, I set the layout from inside a switch insisde each
state object. The state is set by my application, and it propagets
to the system with events. I prefer more simple type objects, state
objects, when my app changes state, i just set the style on my
layouts. I am using a bunch of different layouts like you.. I like
your idea, i think the layout classes need a little more to be fully
baked... like the ability to know when a whole list has been rendered
etc.
Sounds like you are doing a lot with products, do you have any need
for scrolling a virtualized collecton with these? I do. If you want i
can send you an example of what I have done. it's pretty easily
actually.
Thanks,
Patrick
On Sat, Nov 29, 2008 at 10:59 PM, viatropos <lancej...@gmail.com> wrote:
>
viatropos
Nov 30, 2008, 5:25:30 AM11/30/08
to OpenFlux
mmmm... what I meant by views was the traditional flex mxml component
class. i tried swapping out the <mx:Object>'s from Example1 in the
download with <mx:Button> or <mx:Panel> and it doesn't work. If it
did that would make life super easy, but I guess those things need to
be placed in view files that extend FluxView, yeah?
how do you swap out the ListItemView with your own? I can't seem to
find it in the source code.
class. i tried swapping out the <mx:Object>'s from Example1 in the
download with <mx:Button> or <mx:Panel> and it doesn't work. If it
did that would make life super easy, but I guess those things need to
be placed in view files that extend FluxView, yeah?
how do you swap out the ListItemView with your own? I can't seem to
find it in the source code.
viatropos
Nov 30, 2008, 11:38:49 PM11/30/08
to OpenFlux
Definitely, I'd love to see what you've done! It helps to see how
other people design for sure.
I thought about using something like that viewStateMachine, and I was
also thinking maybe you could make a StateController, like the
ButtonController or whatever in OpenFlux, where you'd place all your
state logic. But then I started using URLKit and I sometimes put the
state name in the URL, so that made things a bit tricky.
I checked out Flex 4's code and it seems that they did something like
this layout pattern for changing the state of Skins on their
FxComponents. Check out my comment on the Adobe site:
http://opensource.adobe.com/wiki/display/flexsdk/Enhanced+States+Syntax
I think having the layouts take care of the state changing for you
would be really neat. Then there's also the whole issue of navigation
in Flex, which requires a lot of state changing. I've been thinking
about "navigation" as basically a series of nested layouts, so maybe
sometime down the road it would be possible to incorporate navigation
state changes into "navigation layouts". Then integrating this into
URLKit... And then you'd have a pretty powerful starting point for
building really complex applications it seems....
Best,
Lance
On Nov 30, 7:44 am, "Patrick Lemiuex" <patricklemi...@gmail.com>
wrote:
other people design for sure.
I thought about using something like that viewStateMachine, and I was
also thinking maybe you could make a StateController, like the
ButtonController or whatever in OpenFlux, where you'd place all your
state logic. But then I started using URLKit and I sometimes put the
state name in the URL, so that made things a bit tricky.
I checked out Flex 4's code and it seems that they did something like
this layout pattern for changing the state of Skins on their
FxComponents. Check out my comment on the Adobe site:
http://opensource.adobe.com/wiki/display/flexsdk/Enhanced+States+Syntax
I think having the layouts take care of the state changing for you
would be really neat. Then there's also the whole issue of navigation
in Flex, which requires a lot of state changing. I've been thinking
about "navigation" as basically a series of nested layouts, so maybe
sometime down the road it would be possible to incorporate navigation
state changes into "navigation layouts". Then integrating this into
URLKit... And then you'd have a pretty powerful starting point for
building really complex applications it seems....
Best,
Lance
On Nov 30, 7:44 am, "Patrick Lemiuex" <patricklemi...@gmail.com>
wrote:
> Lance,
>
> I am using a type of stateMachine pattern that I call a
> viewStateMachine, I set the layout from inside a switch insisde each
> state object. The state is set by my application, and it propagets
> to the system with events. I prefer more simple type objects, state
> objects, when my app changes state, i just set the style on my
> layouts. I am using a bunch of different layouts like you.. I like
> your idea, i think the layout classes need a little more to be fully
> baked... like the ability to know when a whole list has been rendered
> etc.
>
> Sounds like you are doing a lot with products, do you have any need
> for scrolling a virtualized collecton with these? I do. If you want i
> can send you an example of what I have done. it's pretty easily
> actually.
>
> Thanks,
> Patrick
>
>
> I am using a type of stateMachine pattern that I call a
> viewStateMachine, I set the layout from inside a switch insisde each
> state object. The state is set by my application, and it propagets
> to the system with events. I prefer more simple type objects, state
> objects, when my app changes state, i just set the style on my
> layouts. I am using a bunch of different layouts like you.. I like
> your idea, i think the layout classes need a little more to be fully
> baked... like the ability to know when a whole list has been rendered
> etc.
>
> Sounds like you are doing a lot with products, do you have any need
> for scrolling a virtualized collecton with these? I do. If you want i
> can send you an example of what I have done. it's pretty easily
> actually.
>
> Thanks,
> Patrick
>
Patrick Lemiuex
Dec 10, 2008, 9:29:53 AM12/10/08
to open...@googlegroups.com
Lance:
Sorry about the delay in getting back to you...
Here's an example of using different views, just bind a custom value
object to each list:
AssetVO
{
view: ClassReference("com.arc90.openflux.views.items.AssetItemView");
}
This is a hackish way, using the uid property to change out the view
in ListItem createChildren method...
switch ((this.parent.parent.parent as UIComponent).id)
{
case ListManager.NOTIFICATIONS_LIST:
if(!view) {
view = new NotificationsItemView();
}
break;
Sorry about the delay in getting back to you...
Here's an example of using different views, just bind a custom value
object to each list:
AssetVO
{
view: ClassReference("com.arc90.openflux.views.items.AssetItemView");
}
This is a hackish way, using the uid property to change out the view
in ListItem createChildren method...
switch ((this.parent.parent.parent as UIComponent).id)
{
case ListManager.NOTIFICATIONS_LIST:
if(!view) {
view = new NotificationsItemView();
}
break;
viatropos
Dec 10, 2008, 11:54:53 PM12/10/08
to OpenFlux
thanks man, I'll have to try that out soon.
On Dec 10, 7:29 am, "Patrick Lemiuex" <patricklemi...@gmail.com>
wrote:
On Dec 10, 7:29 am, "Patrick Lemiuex" <patricklemi...@gmail.com>
wrote:
Reply all
Reply to author
Forward
0 new messages