Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought

Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Show Posts

* | |

  Show Posts
Pages: 1 [2]
16  PureMVC Manifold / MultiCore Version / "Fully" Encapsulated Dynamic Modules on: May 13, 2008, 08:38:10
Okay we’ll as close to ‘fully’ as one can hope for :-)

I’m fine with the modules dispatching events and the shell app picking those events up.  Likewise I have no problem implementing the modules to a common interface to facilitate shell->module communications.

I’m hoping to achieve the following…

1) Modules [swfs] dynamically loaded /unloaded during runtime. 
2) My ‘shell’ app won’t know what modules will be loaded at compile time. (Read in from config / rpc / IoC scheme / etc @ runtime).
3) Each modules ‘mediator’ code will reside w/in the module NOT the main app.

Any tips on doing this (i.e. #3)?
17  Announcements and General Discussion / General Discussion / PureMVC + Flexbuilder Project "Templates" on: May 13, 2008, 07:04:23
I'm hoping there are some flexbuilder gurus out there :)

 I'm using the standalone version of FB3 and was wondering if there's a way to 'automate' my PureMVC project creation.  That is, create the model, view, & controller folders, my ApplictionFacade.as (and contents thereof) the StatupCommand, ModelPrepCommand, etc.  Basically the PureMVC 'shell' I have to manually recreate each time I start a new PureMVC project.

Is there some type of template or plug-in I can utilize to do this??

18  Announcements and General Discussion / Architecture / Re: Mediator <=> View Component Coupling on: April 07, 2008, 10:38:57
  Thanks so much for the thorough replies.  Just wanted some re-assurance I was thinking about this correctly.

Thanks Again !!!

19  Announcements and General Discussion / Architecture / Mediator <=> View Component Coupling on: April 04, 2008, 07:08:15
In many of the demos I've seen the mediators are directly referencing components [TextInputs for example] within the view. 

Would it be better decoupling to have the view pass the corresponding VO *with* the Event as opposed to having the mediator catch the event, and then "dig into" the view component to "pull out" the desired data (i.e. construct a VO from components w/in the view component)?

Just wondering.

The mediators seem to be so tightly coupled to the view components.  Are more verbose events worth the effort or am I being too anal?
Pages: 1 [2]