number of states vs more .mxml files

[pr1440]

I am trying th figure out the best approach.  After login I change states and have a menu that can do is 7 different direction based on selection.

What is the advantage/disadvantage of changing the state of the current .mxml file verses having 7 different mxml files?

Thanks,

Pete

[FrankBHill]

Right now I am developing an application and I have my main application with the following components.

AppHeader

AppFooter

AppContent

Then the AppContent MXML file contains many states for the different menus, around 7.

These states show one at a time using a TabNavigator to display the content is the one section of the screen.

One of the states has another set of nested components

Right now I am having a VERY difficult time getting information into my database. I think it is because of the number of states and components. I am coming to believe that you have to be at the application mxml file to send information but I could be wrong. The only problem with components and state nesting is that it can get out of control quickly. It might better to refactor the application. I plan on doing this after the initial assessment from my managers.

[Anirudh Sasikumar]

Hi,

You don't have to be in the main MXML application file to send data.

You may want to look at architectural patterns in Flex like PureMVC, Cairngorm, Mate, Swiz. They address the exact problem you describe: how best to organize code taking into account MXML, states, server calls, binding, etc.

P.S: You'll get better responses for this question in the Flex general discussion forum.

-Anirudh