Hi Diego,

Interesting question.

Overriding Facade.notifyObservers wouldn't work in this case, as it just passes through the notification to the View.notifyObservers method. And, since the the other Mediators still need to be notified, you'd still need to send every notification. Taking this tack, you'd have to override the View.notifyObservers method, AND you'd need to give the View a list of disabled mediators to skip. AND you'd need some extra methods to manage that list AND some Commands to make it all happen.

I believe the direction I would take is:

1) Give the Mediator a Boolean 'enabled' property.
2) Whenever you need to enable or disable this Mediator, send a special Notification (i.e. DISABLE_GESTURE_RECORDER or ENABLE_GESTURE_RECORDER) that only the GestureRecorderMediator has interest in, and to which it responds by setting its own enabled property accordingly.
3) In the handleNotification method of the GestureRecorderMediator, before your switch statement, return immediately if the Mediator is disabled.

That ought to do it.

Sounds like you're doing some interesting stuff there, just from the Mediator names. Let us know what you're up to if it's not top secret.

-=Cliff>

Hey Simon,

I'd have to see the working example to be sure, but I'd suggest at this point abandoning 'trace' as a front line troubleshooting tool and opt for the debugger. Try setting a breakpoint on the line where the result comes back, and then single step through what it does with the data. Inspect all the relevant variables live on each step. That should tell you where the ball is being dropped.


-=Cliff>

Hi,

As for your mediator being notified of notifications to which it is not subscribed, no this is not normal. Could you attach a small example app that is demonstrating this behavior?

The last section of your comment, I'm not able to follow completely. I'm not really sure what your desired chain of events / notifications is, what's listening to what, etc.

-=Cliff>

Steve,

The value of a constant can be set either when it is declared, or in the constructor of the class that declares it. Therefore, while you could affect the *value* of a constant at runtime (only once), you still have to declare it in code ahead of time. So you couldn't dynamically grow the list.

The Typesafe Enum pattern became all the rage in the Java world a few years ago, though it has been implemented in many languages. It has many supporters and detractors for various reasons that I'm sure an evening's Googling should leave you weary from.

I used it in a low-key way the Architecture 101 courseware in order to demonstrate integration of other patterns into a PureMVC-based application.

My fast and loose Enum implementation was meant to associate a human-readable word with a code. And to provide a way of getting just the enumerated values as a list or that list with a '--None Selected--' entry at the top for populating a combo box in the view.

It allows code to act upon the enumerated values in a typesafe way. The view component that has a combo box populated by one of these Enums can test for the combo's selectedItem property being equal to the enum's NONE_SELECTED constant if a field is required, for instance. Or only make available, say, an hourly rate field if the combo's selectedItem is CONTRACTOR.

In short, the Typesafe Enum pattern is not really applicable if you are dynamically changing a list at runtime. It's really for use when you know the types ahead of time, but you don't want to hardcode the codes and their labels throughout the app, and if you want to have code that acts on specific type codes in a typesafe manner.

In the enterprise, middleware is often used to generate Enums for both client and server sides just like the VOs (Value Objects or Transfer Objects) that represent the Model. Database tables are defined containing all types, their labels, codes, and other info such as the order for display. A DBA may make a new entry in a type table, and the build script will create Java and Actionscript enum classes based upon the current types.

Hope this helps,
-=Cliff>

Watching the mediatorMap and observerMap while stepping through a removeMediator, the delete operator appears to remove associative elements just fine. This despite:

Programming ActionScript 3.0 > Core ActionScript 3.0 Data Types and Classes > Working with Arrays

You may come across code that uses the delete operator on an array element. The delete operator sets the value of an array element to undefined, but it does not remove the element from the array.

The manual is only referring to numeric elements in the array and not to associative ones. Tricky, tricky.

So, based on Whitechapel's originally described scenario at the top of the thread, I've amended the logic of the removeMediator method to use the delete operator to remove observerMap and mediatorMap entries. No check for null arrays is necessary, because the key doesn't hang around anymore.

In the Framework API:
http://puremvc.org/component/option,com_wrapper/Itemid,118/

Examine the method:
org.puremvc.core.view.View.removeMediator

Also, a new test has been added to the PureMVC Framework Test Suite to test that successive register and removal of the same Mediator does not cause error, and a removeMediator on the same Mediator name when it has already been removed does not cause exception.

In the Framework Test Suite API:
http://puremvc.org/component/option,com_wrapper/Itemid,122/

Examine the test method:
org.puremvc.core.view.ViewTest.testSuccessiveRegisterAndRemoveMediator

And see the test pass on the download page for the Framework Test Suite API:
http://puremvc.org/content/view/14/49/

The new version of PureMVC sporting this fix is 1.6.

-=Cliff>

Rich,

The myED example is a classic way if implementing an interface by composition rather than inheritance. Yes it is aot of typing, but it frees you to extend another class.Since we don't have multiple inheritence we may occasionally need to do this sort of thing.

-=Cliff>

Firstly, to answer the fresh question here, that of contributions. I do plan to open a contribution site. Absolutely and without question.

There are good things being done by people and the intention was to create a framework around which people would create useful classes and packages. How cool would it be to have a user contributed set of Proxies to talk to all kinds of major services out there ala Kiwi? Or how about an InterceptingFacade, that takes the notifyObservers arguments and pipes them off to a InterceptFilter before passing it on to the View? This would allow you to do tracking of a user's actions within the app, as well as just help you debug the notification traffic.

This kind of thing is absolutely part of the plan. In fact you might even want to license particularly useful PureMVC apps or utilities you make. I implemented the framework and now work with it daily, but can only do so much so fast. But the community is already coming up with the solutions that help the rubber hit the road, and their own takes on how things should work.

As to maintaining control of the idea space surrounding the core framework, I believe that this is an essential role of the architect. Design by committee has not been something I've seen work often in the past.

However a site with more opportunity for the community to engage, interact and contribute is on its way. Literally, my whiteboard is covered with it at the moment. As you said how do you control the 'quality' of what is going out there? Guidelines and tools to help you get your contributions into a normalized form so that everyone doesn't have to figure out how to publish and document their PureMVC thingy will help. Also communities seem to get on well with this rating thing. So a way of having a localized peer review of, for instance, an alternate mediator, is what's needed. That way your contribution, be it a single class, a utility, an app or whatever takes on a life of its own. In a way that allows people looking to use it really educate themselves about what they're doing. The forum will work for now, but believe me, a better plan is on the way.

Now from the 'Beating a Dead Medator to Death' department:

The fact that you can't do much inside the switch statement is intentional. The Mediator should not be doing that much work and because of its design, it is not intended to bolt onto the rest of the system in the manner that we use it to adapt components.

The automatic way it is hooked up to the system at view registration time and the use of a single method for handling notifications helps to support this in the same way that a 3/4" faucet stem encourages, specifically, a 3/4" hose.

The Mediator in PureMVC is not the same sort of beast as a ViewHelper in Cairngorm or 'code behind' in dotNet. In those characters their primary role is a way of taking all the code from the view component and putting it in a class, so you get good separation of what is code and what is view definition.

That's not the balance here. Here, the View Component accepts a little internal wiring code as a way of encapsulating itself and being portable (see footnote 1). As a way of creating a course grained interface to whatever uses it. Therefore a Mediator does not micromanage the fields of a View Component that it is adapting.

So a Mediator should not be setting and getting scads of properties. A Value Object is the right way to transport a big collection of properties into a view component and keep the Mediator's hands clean.

If transformation needs to be done to the data before it can be set or it needs to come from many places, that is business logic and should be carried out in a Command.

Also, by design, a Mediator's should not expose functions. This gives us the opportunity to CALL them. And that is a collaboration anti-pattern in this system.

All these design pressures lead to a Mediator implementation that adheres to the intended responsibility set and collaboration patterns.

-=Cliff>

Footnote 1: If you want code-behind on your MXML so its really clean just extend your MXML class with an AS class and add functions.

Nate,

I will check this out. You'd mentioned the modules thing earlier, and its been on my queue of things to address. Glad you posted your findings for us to get a start with.

I've got some ideas about the coordination issues surrounding the ApplicationFacade, but I'll look at what you've got here first.

Thanks,
-=Cliff>

array.length

-=Cliff>

Go for it!

The only real thing that I am asking you to do is if you distribute the source code for PureMVC, in its original or a modified form, then you must leave in the attribution that you see in each class:

/*
 PureMVC - Copyright(c) 2006, 2007 FutureScale, Inc., Some rights reserved.
 Your reuse is governed by the Creative Commons Attribution 3.0 United States License
*/

You may add your own statements, but that's it; nothing more to be concerned about.

If you're making a commercial application based on the framework and the source code itself is not part of the package, (which is most likely the case), then you need not include any attribution at all.

This is an open-source framework. The fact that there aren't a bunch of people working on it and that the development phase of the project is over with no future expansion plans doesn't matter. It's open source, do with it what you will.

-=Cliff>

I've stated above as clearly as possible the reasoning for the use of switch  inside handleNotification. I also realize that some people have a predisposition about the use of the switch keyword. If it were truly that vile, I doubt it would still live in so many OOP languages, AS3 included. That is an issue/witchhunt to take up with ECMA and Adobe, I suppose. As with all things, it has its place. A SIMPLE place.

As for why the implementation is the way it is; because I wanted a SIMPLE way of hooking these Mediators up. I didn't want all the extra lines of code necessary to explicitly subscribe, nor did I want to have to write lots of separate methods, when the role of the Mediator in responding is necessarily SIMPLE. If you find yourself with lots of stuff to be done in response to a given Notification in a Mediator, then you are looking at a clear symptom of responsibility misplacement.

Why? Think about what you might be doing in a Mediator in response to a Notification.

• Sending more notifications. Simple.
• Setting/getting properties on the View Component. If this isn't simple, then the API you're exposing in the View Component isn't 'BlackBoxy' enough. Though the Mediator has a somewhat intimate relationship with the View Component, the View Component still needs to encapsulate its implementation.
• Setting some data on a Proxy. Simple, but if not (i.e. transforming it first or updating lots of Proxies in a transactional manner), probably should be handed to a Command. Business logic belongs in Commands.
• Fetching some data from one or more Proxies. Simple, but if not,(i.e massaging it 20 ways to Sunday first), then it that probably goes in a Command, OR the Proxy itself. (In a Command if the massaging is specific to this View implementation, in the Proxy if it is a transformation you might perform again in a different application that uses the same Model and Proxies.)

So, again the action happening inside the cases of that switch statement in the handleNotification should be dirt simple. They shouldn't require any pre/post processing, and I've never advocated such, though I'll be sure to ward people away from it in the next rev of the IIBP document.

PureMVC was created to make it as easy on the developer as possible. I knew very well what the Mediator's role was and I made the decisions I felt supported that role best.

If after this, you still feel the need to abandon the built-in way of doing things, then by all means feel free to do so. I went out of my way at every turn to ensure that any decision I made was something that you could override/reimplement if you didn't care for the way I did it. That's why every single class has an associated interface and the framework handles interfaces and not classes where ever possible.

See my notes above for how you might go about overriding this behavior.

-=Cliff>

I think a good way is actually to externalize these color and font constants into an XML file as well. Then use the same approach you're using to set the text labels to set the colors and fonts.

In addition to employing the same pattern, a nice upside is that this would also make these values configurable from the xml without recompiling the swf.

-=Cliff>

J,

Well, it's not really written on a tablet or anything, but removeMediator isn't really that often used. But when you need to use it, you need to use it.

So, I'm having a look at your suggestion. The following:

:

//
// !!!! remove the key from the map
//
delete observerMap[ notificationName ];

is really not doing anything beyond the

:

observerMap[ notificationName ] = null;

that precedes it.

From Programming ActionScript 3.0 > Core ActionScript 3.0 Data Types and Classes > Working with Arrays

You may come across code that uses the delete operator on an array element. The delete operator sets the value of an array element to undefined, but it does not remove the element from the array.

The problem boils down to there being no proper way to remove a key from an associative array, you can only set its value to null. Short of copying the array element by element, leaving out the keys with null values, and replacing it. I'm still not sure I want to do that here. Primarily because I don't think it would be performant in those use cases which do drive us to use removeMediator a lot.

It is a trade off between a squeeky clean memory profile (where we remove every key in every map leading to zero build up) AND performance when we are adding and removingMediators a lot. Those keys are tiny and shouldn't ever really cause a problem it's the objects they point to that we're really worried about tossing to the GC.

I believe that that we will likely find that adding the

:

if(observers != null)
check will suffice, but I don't want to do it hastily. A soon as I can, I'll pound on this and arrive at a conclusion and likely a 1.6 maintenance release.

Thanks much for your input on this, I really appreciate it.
-=Cliff>

Hi, Malo.

So, the swf runs by itself, just not when being loaded by a Loader?

From your stack trace, it appears everything has gone perfectly up until the actual StartupCommand's execute method.

In that method you instantiate and register your DataProxy. I have no reason to believe this is causing a problem in this circumstance.

I also see no reason why the loaded app should not be able to access the stage  in order to create and register the StageMediator.

So here are my thoughts for further investigation:

I think it could have to do with the LoaderContext or ApplicationDomain.

If your loading application is ALSO a PureMVC app, it's just possible that the default behavior for the Loader is getting in the way. It wants the loaded swf to be allowed to access the classes of the parent swf. If the loaded swf tries to define a class that's already been defined in the parent, then it is ignored. This may not be what you are wanting.

From the live doc:

# Child of loader's ApplicationDomain. The default. You can explicitly represent this choice with the syntax new ApplicationDomain(ApplicationDomain.currentDomain). This allows the loaded SWF file to use the parent's classes directly, for example by writing new MyClassDefinedInParent(). The parent, however, cannot use this syntax; if the parent wishes to use the child's classes, it must call ApplicationDomain.getDefinition() to retrieve them. The advantage of this choice is that, if the child defines a class with the same name as a class already defined by the parent, no error results; the child simply inherits the parent's definition of that class, and the child's conflicting definition goes unused unless either child or parent calls the ApplicationDomain.getDefinition() method to retrieve it.

http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/system/LoaderContext.html
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/system/ApplicationDomain.html

This is just a direction for your research. Please let me know what you find - if this is or isn't the answer.

-=Cliff>

Just so, Steve.

You only get to inherit (extend) once, and so if you want to inherit from somewhere that doesn't have (in this case) the methods called for by the IEventDispatcher interface, then you can implement those methods yourself, and say 'implements IEventDispatcher'. Then you can extend something else if you'd like.

The excerpt you were looking at was further saying that the easiest way to implement the IEventDispatcher is to make a property of some type that does implement the interface, and then your implementation methods just pass the calls along to that dispatcher you're holding.

-=Cliff>