other components. Then you can group related components into
packages, wrap them in higher level components to hide complexity, or
break them apart for more general reuse. You'll also see what
components are common to various states, and which are tightly coupled
to a specific state. That cohesion will generally dictate your
instantiation policy.
In practice you'll also want to look at how and when components are
presented to the user, how big they are, when they get populated with
data, and finally, how your development process distributes work
across multiple engineers. These will also influence how you package
up your app.
HTH,
-Michael
--- In [email protected], "aejaz_98" <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I have a general question about how to go about breaking a large Flex
> application in modules. If an application has a large number of
> states, what is the recommended practice to break it in modules so
> that I don't
> have a huge mxml file which will make compilation slow & code
> navigation in it complex.
>
> Thanks,
> Aejaz
>
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
| Web site design development | Computer software development | Software design and development |
| Macromedia flex | Software development best practice |
YAHOO! GROUPS LINKS
- Visit your group "flexcoders" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
