views:

31

answers:

1
+1  Q: 

Modularity in Flex

I'm working on a pretty big application for Flex/Air. We are using GraniteDS and Tide to interact with the model from our Java EE server.

I've been reading about modularization and Modules in Flex. The application has already been built, and I'm figuring a way out to re-design some classes and parts. From what I've read so far, I understand a Module is a different swf which can be dynamically load. Most of the tutorials/documentation are oriented to Flash "programmers" who are using Flex or Air instead of real developers, so that makes online resources harder to get.

What I can't understand - yet - is how to encapsulate ActionScript classes or MXML views under this module.

I've separated some of the code into libraries. For example, the generated code from Granite is in a "server" library. But I would like to separate parts of the logic with its Moderators, Controllers and Views. Are modules the way to go? Is there a "modules for dummies" or "head first Flex Modules for programmers" like tutorial in order to get a better perspective in order to build my architecture? When to choose libraries and when to choose modules?

I'm using Flex 3.5, and a migration to Flex 4 is way far into the future, so no Flex 4 answers please, thanks!

+1  A: 

Modules are the answer for encapsulating UI into different sections that do not depend on each other. Think of them like applications inside of applications.

If you want to encapsulate "code", meaning non-ui actionscript, then you really just want classes and packages of classes. You could also package that code into a swc, which is just a compiled version of that code that you can include in multiple projects (I think this is what you meant by libraries).

You wouldn't want to create a module just to contain non-ui code. You wouldn't want to use modules for separating out the model/view/controller in your application.

If you have part of your application, that for the most part runs completely on its own, with no real dependencies on the rest of the application except for maybe a little bit of information passed in, then it makes sense for modules.

Where we use modules mostly is for an application that has different sections to it where you are only working in one section at a time. There is no need for the other sections to be taking up resources, so we have the different sections in modules and load/unload them as necessary.

Does that help?

Edit in reply to the comment below:

By libraries I meant Flex Library Projects, where you encapsulate classses and use the swc. Can you have these libraries inside a Flex Project? (I use a separate Library Project for each new library).

Yes, you can use these swc's (Libraries of code) inside of your flex projects. Just drop the swc in the lib directory in your flex/flash builder project and the code is automatically added to your classpath. Just make sure that everything that the code inside a single swc needs is inside that swc. Don't make a swc rely on another swc to function.

Ryan Guill
Thanks for your answer! It kind of confirms my concept of modules.By libraries I meant Flex Library Projects, where you encapsulate classses and use the swc. Can you have these libraries inside a Flex Project? (I use a separate Library Project for each new library).I think I'm using a module for the chat window, which uses XIFF - a jabber client library, so it uses very few information from the rest of the project.
Fernando
I added more information to the answer above to answer your question.
Ryan Guill
Yes, I do add the swc, I was wondering if you could use that project as a subproject inside your Flex Project. Anyway, never mind, I think I am doing better than I thought with modularization. I'll just add a Module for Chat, and keep encapsulating other logic in libraries. Thanks!
Fernando
This answer makes it sounds like you can't encapsulate UI elements into classes, packages, or library projects. You didn't intended to communicate that, did you?
www.Flextras.com
No, I didn't intend it to be taken that way. You certainly can encapsulate UI into classes and library projects. But it doesn't make sense to encapsulate logic into modules. Like I said before, I like to think of modules as smaller applications inside of a larger application, a sub-application if you will. Do you think that is more clear?
Ryan Guill