Hi.

I've struck a problem today, which I suspect is indicitive of a problem in my design....but I'm not sure how to proceed....

I have a mediator which does something invokes a method on an object.  The object does it's business asyncronously, and dispatches an event once it's complete.

The mediator listens for this event, and -- when appropriate, sends a notification out to the rest of the application.

I want to write a test which invokes the behaviour on the object (via the mediator) and waits for the notification being dispatched from the mediator.  At this point we can interrogate the mediator to make sure that the operation has completed as expected, and the mediator is correctly consuming my object.

But, I don't see how to write this test.  The main problem is that a mediator doesn't expose it's notifier as a property through composition, instead it's coupled to using the facade.

I really don't want my tests relying on a facade, primarily because it's a singleton, and therefore is likely to generate dependancies between tests.

A potential solution I see is to modfiy the Mediator take a Notifier, rather than extend Notifier.  (composition).  However, this seems like a big change, and ... the very fact that I'm looking at having to modfiy the source of PureMVC probably means that I've missed something somewhere along the line.  (Ie., it's probably a fault with my design, rather than PureMVC).

Can someone please offer some suggestions here?

cheers

Marty

Thanks Cliff

Hi

I have a fairly simple question.... Across my application, various components need to know about who the user is.

How do I expose this type of singleton style data?  Do I expose a :

public function get userProxy():UserProxy

on the ApplicationFacade?

then when I need to know who the user is, I target ApplicationFacade.getInstance.userProxy.userName()?

Or is there a more appropriate approach?

Thanks


Marty

Great!

Thanks for the advice, and the link.

Much appreciated.

Marty

Hi all.

I've selected PureMVC as the framework to port a large scale commercial across to -- which is currently quite a mess on the flex side.

I've read all the docs, and have my first (surely of many) question --

this application has several hundred commands and notifications.  Is it really best practice to list the constants for all of these within the ApplicationFacade class?

I'm not questioning the practice of the constants -- that makes perfect sense.  However, I wonder if this creates a maintanence issue.  Should this instead be split over seperate files?

As an alternative, does it violate any of the best practices if these are split over several static classes, all in the same namespace / package as the application facade, but broken into more logical subgroups?

These classes can then be declared as public properties within ApplicationFacade.

So, instead of referring to ApplicationFacade.ADD_EMPLOYEE, I'd use ApplicationFacade.EmployeeCommands.ADD_EMPLOYEE.

Thoughts?