Hi -

I'm planning to use a single proxy that can be used to invoke one of several different delegates. The single proxy will employ a value object that acts as the schema for data supplied from various delegates. Thus, a single notification will request some data by providing a type value and the proxy will choose the appropriate delegate based on that value. The requesting application will then receive more or less the same data without having to worry about how it was acquired.

Does this sound right? Are there drawbacks to this approach? Is there another best-practice approach? Thanks.

Peter

Ya me too - I'm looking forward to it. Thanks Cliff.

Peter

Ha! Fortunately for me the PE teacher subbed History, but for an entire term - and he wore the same track suit every day! (Not so fortunate) Mr. Putnam - the Sex Ed teacher was also a PE teacher and he kept his removed cancerous testicle in formaldehyde in a jar on his desk. I'm am not making this up. They called him "one nut put". 

Yes it seems to be the natural order that simplicity in one area leads to complexity in others. I think it's good to keep it simple on the architectural framework side at the expense of complexity in the application. On the other hand - it's just one little method. Tempting no?

I'm not actually using much of the Flex framework on my current project. Just a few classes here and there, but not the UI stuff. I've implemented a classic state machine much like the one you describe that passes control around via a context class or state interface methods. The current Pure MVC sample seems to be a bit different from what I can tell - more reliant on data binding. Then there is also the official Flex states and transitions which I tried, but found too proprietary and a bit awkward. The advantage of sticking with AS3 is that I can easily work with C# examples or pair with Java developers.

One thing that I often struggle with is the decision of when to create a new state and when to simply use a state flag. It seems that there are pros and cons here - with preparing a state architecture to scale well on one side and class bloating on the other. My current MO is to let a few flags creep in until it starts to smell bad and then refactor with new states. This works OK as long a I'm not lazy and let it go too far - kind of like doing the laundry or going to the gym.

It sounds like your design doesn't give you the flexibility to slack off - which may not be a bad thing. Thanks.

Peter

Thanks for the feedback guys. I am already using a boolean flag without problems.  In my particular case I can simply set the flag directly in my mediator without the need to send a notification, but I think this idea could be useful in certain circumstances. This just feels a little awkward since the unnecessary interest is still there.

For this reason could this possibly lead to memory issues? Perhaps in a game or some application where many notifications are sent? I suppose one solution would be design mediators with this in mind and to remove them altogether instead of unlisting specific interests. This approach would leave you with both short term and long term mediators. Still, it would be nice to have a way to remove them so I'll double back and follow up on your subclassing solution at some point. Thanks.

Peter

Hi Cliff -

In my case I've divided my application logic into two primary mediators - ApplicationMediator and CanvasMediator. The ApplicationMediator handles start up, security, configuration, etc. It also instantiates the CanvasMediator and manages loading module based views into it. At some point I intend to refactor some of this logic into additional mediators that are coupled with each module view class, but for now the views have no mediators. I suppose CanvasMediator is a sort of shell class only it also serves as a layout manager.

This particular application utilizes data feeds that are housed in an RSS based schema called Media RSS. A PlaylistProxy class manages the loading and memory cache retrieval of playlist collections from another proxy that manages multiple playlists and a few other bits of application state data.

In most cases playlists are loaded at the CanvasMediator level, but due to the flow of my application execution it is practical to handle the first loaded default playlist logic at the ApplicationMediator level. But, once the application has been initialized I no longer want to listen for playlist command events here.

One option for me is to refactor my application such that all playlist loaded events are handled at either the CanvasMediator or ApplicationMediator level, but not both. This would eliminate the need for a flag in the ApplicationMediator. At this point I can't justify doing this as it means changing a lot of code and the flag is working just fine.

In summary, I can't say that my application architecture is perfect except for the lack of the ability to remove notification interests in mediators. I'm sure I could work around this in a better way. But on the other hand it seems like the framework might be more complete with this facility?  The ability to attach and detach observers or add or remove listeners comes to mind, but perhaps the notifications in Pure MVC are not parallel concepts. Thanks.

Peter

Is there a best practice way to remove a notification interest from a mediator? I'm using a flag in handleNotification at the moment... LAME! Got to be a better way than this? Thanks!

Peter

Thanks Cliff - yes I am going to check out the Pipes as I've encountered another important flaw in my approach. I've realized that my approach was bad because it meant that the compiler is importing all the view classes into the parent/shell app instead of my ModuleBase derived class.

I understand that ModuleBase is in the Flex framework, but I was explictly using it because I don't have the luxury of importing the Flex UI framework into this particular app as I need to keep the file size down. Compiling my view classes into the shell caused it to be the more file heavy class, which is not what I wanted. Looking back at your Modularity example I think I am now seeing the benefit of using interfaces at the shell level.

I've run out of refactor time for this iteration, but hopefully I can make this work better next time around. Unfortunately, the technical debt here is going to mean my shell swf gets larger as my module view gets larger. The problem with my design is that I am setting view properties on state instances in a shell swf mediator. Hopefully creating some interfaces with solve this problem for me.

Peter

OH crap - it just occurred to me. Is this what this Pipes utility is for?

Another related point - I think it would also be handy to retrieve proxies from a parent core. Any thoughts on this? Thanks.

Peter

I'm looking at whether to try to use the multicore version for my AS3 only project. So far I've successfully created a module with ModuleBase. This gives me the ability to optimize linking for the containing application and best of all I get the little blue icon in FlexBuilder. Sweet! (Strangely the compiler initially places the .swf in the class directory rather than the Output directory, but then it started updating on compile once I moved it. A bit confused about this.)

Unfortunately, there is very little documentation for non-Flex framework modules, but I would like to try to make it work with multicore. My first problem is that ModuleBase does not apparently extend a DisplayObject class and so I was unsuccessful in trying to add my module to the stage. I tried to cast the module but no luck. Anyone know what I'm doing wrong with that? I thought .swfs were intrinsically display objects?

Anyways, as a work around I've winded up making the ModuleBase derived class a display object factory of sorts and pass the objects to my main application to be added to the stage when appropriate. This gives me the benefit of smaller downloads, but leaves something to be desired on the application scalability side.

At this point I'm thinking of abandoning multicore to just use a single core that loads modules that are simply view libraries, but of course this does not give me the benefit of scaling my control logic with multicore. Another idea is to have the ModuleBase derived class create an application runner class that extends Sprite and in turn sets the facade instance as normal. I think this probably makes the most sense if I can make it work?

On this last point - it seems like it would be practical for modules to have a way to send notifications via their own facades and the parent facade. Not sure if this makes sense. Perhaps this should be avoided as it breaks encapsulation? Thanks.

Peter

Hay this sounds great. I'm going to try it out. Thanks and happy new year!

Peter

Doh! Turns out that while a response was coming back from the ad server - it was lacking some specific data and so the component was dispatching the event. So there is now no problem with listening for a generic event from the scope of a non display object.

However, my actual problem did arise from a design issue from an earlier thread. It turns out that I was overwriting some configuration values required to make the ad call properly. This was because I am using the same proxy for multiple commands and was forgetting to use facade.retrieveProxy for the second rather than instantiating.

It seems to me that a singleton proxy or model object would help out here. What are your thoughts on this? Any problems with this?

Peter

Oh hay wait - suppose the AsyncCommand would be good since I can remove listeners in onComplete. Any other reason? Thanks.

Hmm. Well the event handler is not executing so I don't see how this will solve my problem but thanks. Interestingly, the component dispatches another custom event that appears to forward Loader events (e.g. HttpStatusEvent) and this is firing. But the plain Event type is not firing.

I think this has to do with the Flash DOM and bubbling display events somehow. This is of course not the concern of Pure MVC so I'll have to find some kind of work around. Maybe best to just dump the component since I can write my own code based on the request/response headers. Thanks.

Peter

Hi -

Not exactly sure if this is the problem. It's only a hunch at this point, but here are the clues and context.

I need to use a third party component in my application and I have no access to the source code. The component makes requests to an ad server and returns xml. The basic API for the component is to instantiate the component, call methods on it and listen for callbacks. The listeners are created IEventDispatcher style so I'm assuming the component to be a Sprite or some kind of displayObject.

I am currently refactoring my app from a basic Sprite based design over to Pure MVC. In the earlier version I instantiated the ad component object and did not need to add it to the stage to handle the xml load event. However, it was hosted in a Sprite that existed within the Flash dom. It works fine this way.

In my new Pure MVC based version I am trying to house this logic in a command called LoadAdCommand. This command listens for the ad response and I was intending to either update a model object via proxy or simply send a notification containing the ad xml back to the mediator to execute further ad display logic.

At present the xml loaded event is not firing in my command, however I can see the response coming back correctly in Firebug.

Anyone have any ideas? Thanks!

Peter