Hi, it's similar but not the same. Yes in PureMVC you register your objects as well, but you register them by a name defined in the class being registered (and you have to define this name). This causes references to a concrete class everytime you retrieve your registry item and you cannot easily switch implementations at runtime without doing something 'extra'. Besides that you register your object with a different registry based on whether its a view, model, proxy etc. All I'm really interested in is an objects interface, so I rolled those registries into one and access them by interface only, not by public constants.
Whether you hijack events and create commands that can be triggered from anywhere is a separate issue I think. greetz JC On Thu, Nov 20, 2008 at 4:16 PM, Joel Stransky <[EMAIL PROTECTED]> wrote: > While I have no authority to defend why, I'm leaning toward PureMVC. From > what I remember it's very similar to whats being described here. Events are > hijacked and all commands are registered in one place which can be triggered > from anywhere. Of course I'll have to put my money where my mouth is before > I can truly judge it. > > You guys don't have to post links but could you describe some of the > projects you've worked on where Flex was an easy choice over Flash? > > On Thu, Nov 20, 2008 at 6:18 AM, Hans Wichman < > [EMAIL PROTECTED]> wrote: > >> Hi Jason, >> >> i only saw this post now, not sure if it was directed at me or at the >> list in general or both, but anyway: >> >> i agree the naming conventions could be better, but I don't mind using >> some kind of locator object. I posted previously about my approach I >> think. I use an ApplicationRegistry where I register my objects: >> >> _appReg.register (new ...Model()); >> _appReg.register (new ...View()); >> >> etc and I do that for all key application objects such as services, models >> etc >> >> when I need them I do: >> _appReg.getRegistree (IFooBarModel); >> >> in other words, I locate my objects by interface (or concrete classes >> depending on how abstract we need to get). >> >> Usually I even wrap that using an objectbroker so the previous line >> becomes: >> >> _ob.getFooBarModel():IFooBarModel >> >> It separates creation from usage, I don't have to import anything >> except the broker and works wonders while refactoring. >> >> I've used in on several projects and have to run into downsides yet. >> It has not harmed reusability, managability etc etc, it has helped >> improve my coding speed by far. >> >> greetz >> JC >> >> >> >> >> On Tue, Nov 18, 2008 at 4:11 PM, Merrill, Jason >> <[EMAIL PROTECTED]> wrote: >> >>> Read the article, some good, some bad. >> > >> > What are your thoughts on the article's baching of Cairngorm's >> ModelLocator? The he says its really a global var in disguise, and I >> understand that, but I still find it very handy - maybe it makes it somewhat >> tighter coupled to the model, but I use the same implementation of it in >> non-Cairgorm projects just because it's so handy. I can see where it >> wouldn't be good in a coding environment where you have to loosely couple >> everything, but it also seems to have its uses. Any thoughts on that? >> > >> > >> > Jason Merrill >> > Bank of America Instructional Technology & Media ยท GCIB & Staff >> Support L&LD >> > >> > Interested in Flash Platform technologies? Join the Bank of America >> Flash Platform Developer Community >> > Interested in innovative ideas in Learning? Check out the Innovative >> Learning Blog and subscribe. >> > >> > >> > >> > _______________________________________________ >> > Flashcoders mailing list >> > [email protected] >> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >> > >> >> _______________________________________________ >> Flashcoders mailing list >> [email protected] >> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >> > > > > -- > --Joel Stransky > stranskydesign.com > _______________________________________________ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
