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

Pages: [1]
Print
Author Topic: newbie question--scope of facade?  (Read 13960 times)
kimba
Newbie
*
Posts: 5


View Profile Email
« on: September 11, 2008, 12:52:29 »

Getting started with PureMVC/AS3 and confused about the scope and declaration of facade. Where is there a global instance named facade declared?  Couldn't find it in PureMVC.

Specifically I would like to add utility methods to the concrete app-specific subclass of Facade and have the facade instance (global scope? package scope?) be of type MyAppFacade rather than the base Facade.

I see the static instance: Facade declaration in Facade.as, and that makes sense. But I don't see any global/static declaration of facade: Facade. How is everything able to refer to facade.registerProxy(...) etc? Don't tell me it's all one giant closure?!

Thanks,
k.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: September 11, 2008, 04:57:05 »

Facade.getInstance() is the factory method for retrieving the Singleton instance.

If you follow the inheritance of the classes, you'll notice that SimpleCommand, MacroCommand, Mediator and Proxy all extend Notifier, which gets a reference to the Facade Singleton at construction (in MultiCore, the facade property is not available until slightly later,  initializeNotifier). In either case you should wait until onRegister to do any Facade access, so as not to start any conversations you can't participate in. The Standard version demos haven't all caught up with this best practice, so be aware.

Also note that while you can add methods to your Facade, you'll have to cast the singleton instance to your type to use it. And its not really a best practice to do so. There is almost always a better way to handle things.

-=Cliff>
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #2 on: September 11, 2008, 04:57:41 »

Facade.getInstance() is the factory method for retrieving the Singleton instance.

If you follow the inheritance of the classes, you'll notice that SimpleCommand, MacroCommand, Mediator and Proxy all extend Notifier, which gets a reference to the Facade Singleton at construction (in MultiCore, the facade property is not available until slightly later,  initializeNotifier). In either case you should wait until onRegister to do any Facade access, so as not to start any conversations you can't participate in. The Standard version demos haven't all caught up with this best practice, so be aware.

Also note that while you can add methods to your Facade, you'll have to cast the singleton instance to your type to use it. And its not really a best practice to do so. There is almost always a better way to handle things.

-=Cliff>
Logged
kimba
Newbie
*
Posts: 5


View Profile Email
« Reply #3 on: September 11, 2008, 02:52:11 »

Ah, thanks, why didn't I see that (and my regexp search for facade\s*: didn't find it either.) My bad.

Well, we are resorting to MyAppFacade.getInstance()... but I'm from the wudang school of emptiness, so even that is rather bulky for my style. I suppose we could create a layer of subclasses, MyProxy, MySimpleCommand etc., yuck, or simply expose MyApp.facade as a public static variable or accessor. It would be nice to be able to extend Facade in a non-app-specific way without modifying the base sources.

If not through subclassing Facade, how would you suggest mixing in a global set of pMVC-related utility methods to the scope of commands, mediators, proxies, and views generally?

Thx,
k.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #4 on: September 11, 2008, 03:54:34 »

What would those utility methods be?

-=Cliff>
Logged
kimba
Newbie
*
Posts: 5


View Profile Email
« Reply #5 on: September 11, 2008, 06:31:17 »

Oh, geeze, at the moment just things like caching access to proxies, notification-based logging wrapper, etc. Common one liners. Things like:

facade.startupMonitor.addResource()
facade.logger.info( componentName, notification )
facade.getParameter( paramName )  etc.

instead of:

(facade.retrieveProxy( StartupMonitorProxy.NAME ) as StartupMonitorProxy).addResource()
Logger.getLogger( name ).info( name + ": " + note.getName() + ": " + note.getBody() )
(facade.retrieveProxy( ConfigProxy.NAME ) as ConfigProxy).getParameter( paramName )

Again from the school of less is more OOD. I suppose we could have a parallel pMVC utility static singleton, but facade is already if we could extend it cleanly.

Thx,
k.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #6 on: September 11, 2008, 07:22:34 »

Commands are usually sufficient. If you want to clutter your facade with such things you certainly may, but that's a route to spaghetti code and a monolithic actor which is what gives singltons a bad rap.

-=Cliff>
Logged
kimba
Newbie
*
Posts: 5


View Profile Email
« Reply #7 on: September 13, 2008, 01:23:31 »

Well, then how would you organize these kinds of wrappers? These are naturally mixed into a pMVC-global context. Facade seems a natural place to hang them rather than a proliferation of static utility classes.

I'm not understanding what you're saying about commands being sufficient. SimpleCommand also extends Notifier, so we would have the same situation trying to add global scope utility methods to SimpleCommand.

Granted I'm just trying to address code legibility and brevity for common phrases, not architectural patterns. But those are dual aspects of design. Without a macro (#define...) type of facility, how do you avoid all the inline casting?

Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #8 on: September 14, 2008, 05:26:18 »

I generally don't find the need for making globally accessable utility methods. Perhaps its just me, but I find that sort of thing just a little defeating of the purpose really. It is similar to the ModelLocator in Cairngorm where basically all your data, validation and utility methods all seem to collect like a closet that needs cleaning.

Again that's just my take.

As for casting, it happens. But I don't mind it so much that I make shortcut methods on a Singleton to retrieve things in order to get around doing it in more than one place.

-=Cliff>
Logged
kimba
Newbie
*
Posts: 5


View Profile Email
« Reply #9 on: September 14, 2008, 11:48:49 »

No, actually I think you're absolutely right Cliff. I mean, I have no problem with all of my implementation being littered with repitious beauty like:

(facade.retrieveProxy( StartupMonitorProxy.NAME ) as StartupMonitorProxy).addResource()
(facade.retrieveProxy( ConfigProxy.NAME ) as ConfigProxy).getParameter( paramName )

All of that inline casting indicates that the design is congruent with the actual use, rather than just with a concept. And you are right, it does prevent all of those wrapper-accessors from gumming up your facade. I just can't think of a better way to do it. Could you?

k,thx.
Logged
shauno


Email
« Reply #10 on: September 15, 2008, 01:52:51 »

If a Mediator needs access to a particular Proxy: define that Proxy as a typed property of the Mediator, and "retrieve" the Proxy once (in the constructor or onRegister hook). By looking at the top of your Mediator you can then easily see what Proxies it uses, and use them later without all the casting.

If you need access to a Proxy inside of a Command: retrieve it, cast it, and store it in a local variable.
Logged
Joel Hooks
Courseware Beta
Sr. Member
***
Posts: 146


baby steps

 - 46288188  - passport@provinsal.com  - joeltuff
View Profile WWW Email
« Reply #11 on: September 15, 2008, 07:10:26 »

I define an AbstractProxy, AbstractCommand, and AbstractMediator (thanks Daniele). These three all have the common global proxies, LocaleProxy and ConfigProxy as well as my app specific core proxy objects. They also carry the utility methods for logging. After the initial load, all of my proxies/mediators/commands simply extend their abstract class and they are kept nice and clean.
Logged

http://joelhooks.com - my ramblings about developing with actionscript and python using pureMVC and django respectively.
Pages: [1]
Print