Abstract Classes

[michael_ramirez44]

Should AbstractProxy and AbstractMediator be part of the PureMVC framework? Will 99% of users end up creating the same AbstractProxy and AbstractMediator classes?

[carl]

That was the first thing that I thought when I started using the framework. I felt it was kind of tedious to have to use the boilerplate Abstract classes, but since there were only 2 of them I didn't mind so much.

I'm not certain, but it appears that the reason why it isn't part of the framework is due to the coupling to the ApplicationFacade.

If there were some nice way for Cliff to make the Abstract classes part of the framework I think it would make an already elegant and powerful framework even more so.

[puremvc]

Michael,

A good and logical question. There is only one problem with that; the framework doesn't know your Facade name or package.

The issue (for those just tuning in) is we often want our Mediators and Proxies to have a local reference to the Singleton instance of our concrete Facade. (See for instance pages 20 and 29 of Implementation Idioms: http://puremvc.org/docs/praxis/PureMVC_Best_Practices-1.0.swf)

This keeps us from having to call ApplicationFacade.getInstance() everytime our Mediator or Proxy needs to talk to the concrete Facade.

It would be nice if the Mediator or Proxy had this from birth, so to speak.

So the idiom is to create AbstractMediator and AbstractProxy classes for our application that extend the PureMVC implementations and that fetch and cache a reference to our concrete Facade in its constructor. Then we have all our Mediators and Proxies extend these abstracts rather than the framework classes.

It's also a helpful place to imbue our Mediator or Proxy instance with any other inheritable features we'd like all Mediators or Proxies to have.

Although we don't have to create an AbstractMediator or AbstractProxy, it's one of those things that makes sense at implementation time. And it can't be put into the framework because only in our application will we know the package and name of our custom concrete Facade class.

As with EJB and plenty of other technologies, sometimes this is the sort of thing is best relegated to middleware. (Code generation and notification traffic analysis tools are on the drawing boards, but I'm busy creating PureMVC Architecture 101 Courseware at the moment).

But again, it isn't necessary to create AbstractMediator and AbstractProxy classes, its just a logical implementation time decision that is easy to do and provides a lot of benefit in terms of fewer calls to get the Singleton at runtime.

[puremvc]

Hey, folks guess what?

Although I'd already been to this pass before, I took another long hard look at this problem and some testing showed an amazingly cool thing:

Turns out the Proxy and Mediator framework classes can just have facade:IFacade properties, initialized to Facade.getInstance().

As long as the concrete Facade has been instantiated first, (and certainly should be) then the Framework Facade will actually return the concrete Facade instance when Facade.getInstance is called.

The only other reason for these two abstracts was to add a sendNotification convenience method to all Mediators and Proxies to keep from having to construct new Notifications all the time. This relied upon the Facade reference being available, and it is now, so this method was given to both Mediator and Proxy.

So, I've made the first functional enhancement to the framework.Version 1.3
(1.1 and 1.2 were adding a top level folder, and including the asdoc):

Mediator and Proxy both get a facade:IFacade properties and sendNotification methods.
No need to implement AbstractMediator and AbstractProxy in your apps.

If you have already built an app using AbstractMediator and AbstractProxy, simply remove them and make all Mediators and Proxies extend the framework classes instead. And of course, download and replace the PureMVC.swc.

I really thought long and hard about this. One of the major things I want is a stable framework that isn't a moving target, with
upgrades all the time. And that is still the goal.

However this is clearly:
     A) Early enough in the lifetime of the framework, and
     B) A significant improvement in requiring less of the developer and giving them more.

So, if you download the PureMVC framework zip from the site now, or view the source code, you'll see that these changes have been implemented. The CodePeek demo has also been updated, and I'll be revisiting the CafeTownsend demo shortly.

And of course Implementation Idioms is being updated as well.

[carl]

Woohoo!

I think this will make it a lot easier for newbies (myself included), to get up to speed with the framework. I know that this was one area that caused a little friction when I was first getting started.

And it'll remove one layer of boiler plate code that I didn't enjoy having to write, but it was well worth the convenience to do so at the time.

Nice work!