This content has been marked as final. Show 8 replies
Using one or the other will depend of what you need. If the project is big and not everyone will access everything, for instance a site with an administration, then I would recommend modules. I have a couple of projects here, but just one of them is based on modules.
Yes, our app is fairly extensive, and prone to further growth.
At what granularity did you implement modules? I.e. did you create modules for entire sections of the app, having many views in a single module, or did you create a module for each view?
I am considering the later for the following reasons:
- Load times will be consistently shorter, making every view almost immediately available.
- Once cached on the client, each module should have virtually no load times.
The drawbacks to making large modules with multiple views (as I see it at this time) is that could will take a long time to load the module initially, which will interrupt the work flow of the user.
Thoughts? I'd love to hear criticisms as to faults in my logic, as I'm still new with Flex.
I understand modules in this way:
They are tools. So, user administration is one module, independent if it consists of one or more views. But remember they need to relate to each other. Here for instance when have a complex user administration, so add/remove users id one module and relate users to companies is another module. Does this make sense? The load time will be improved but when comparing with a "standalone" application, more bytes are loaded. The project over here grew from 3MB to 17MB, but as a told before, not everyone will access everything, so for 90% of our users it shrink from 3MB to more or less 2MB.
While developing I had a couple of problems, because there are still lots of bugs with modules.
I recommend using a design pattern, so it will be much easier to work with this modules. I'm used to Cairngorm, but use it with Domain Models, Presentation Models and Dependence injections.
I hope my post may help you.
Peter, thanks for your inforative reply. I believe the information in your last post will get me in the direction I need to be going. I'm not yet familiar with Cairngorm, and will look into that.
"Miggl" <firstname.lastname@example.org> wrote in message
> Peter, thanks for your inforative reply. I believe the information in your
> post will get me in the direction I need to be going. I'm not yet familiar
> Cairngorm, and will look into that.
There was a discussion recently on the flexCoders yahoo group that suggested
it's nearly impossible to use Cairngorm with modules. In part, this is
because Cairngorm depends on singletons and Modules don't play well with
For more on this, see
Using the "pure" Cairngorm makes the modules concept almost useless, but when refactoring your ModelLocator and introducing Domain Modules, Presentation Modules and Dependence Injections Cairngorm will support modules.
Check those links:
"Peter Hahmann" <email@example.com> wrote in message
> Using the "pure" Cairngorm makes the modules concept almost useless, but
> refactoring your ModelLocator and introducing Domain Modules, Presentation
> Modules and Dependence Injections Cairngorm will support modules.
> Check those links:
> Steven Webster
This says that Adobe does "something" when it uses Cairngorm with Modules,
but not what.
> Martin Fowler
This is not actually about Flex, but I suspect the Flex engineers read
something like it before creating the Flex Framework, because many of the
problems it is talking about and tries to solved are taken care of by data
binding in Flex.
> Paul Williams
This is more of a treatise of how the above would play out in Flex, with no
specifics on how you'd solve the problems caused by using Modules and
The consensus by people who have tried it on flexcoders is that Modules are
difficult to impossible to use with Cairngorm. I have to wonder, do you
have specific suggestions on how to make Modules workable with Cairngorm
that come out of your own experience in doing so? I don't see that the
links that you've posted provide any practical guidance in the subject at
I've seen some posts explaining how refactoring it and applied it here. But this posts are in Portuguese and where based on this 3 links. But whats happens is more or less this.
Each module will has a DomainModel, which remembers the original ModelLocator. Each view has a PresentationModel which is responsible to manage the views data access. For instance: your view calls its PM to retrieve the data located at the DomainModel. With the dependence injection your components are not responsible to retrieve the Models, Presentations, etc instances, but they'll get it from the components that want to use them.
The comments are in Portuguese, but the diagram might enlighten what I'm trying to explain: http://blog.dclick.com.br/wp-content/uploads/diagrama.png