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: Location of custom managers in MVC package structure...  (Read 9184 times)
mattb
Newbie
*
Posts: 7


View Profile Email
« on: February 22, 2010, 06:25:31 »

If you had some custom implementations of flex managers in your application, where would you store them....

Outside the mcv strucutre....
:
com.mydomain.myapp.managers.MyCustomManagerImplementation
As this manager updates external data - would it live in the model..
:
com.mydomain.myapp.model.managers.MyCustomManagerImplementation
It's multicore as well, and could be used by any core so would it be in ...
:
com.mydomain.myapp.common.model.manager.MyCustomManagerImplementation

Any thoughts would be appreciated

m.


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



View Profile WWW Email
« Reply #1 on: February 22, 2010, 07:56:35 »

I believe I'd go with the first one (even for multicore)

:
com.mydomain.myapp.managers.MyCustomManagerImplementation
-=Cliff>
Logged
mattb
Newbie
*
Posts: 7


View Profile Email
« Reply #2 on: February 22, 2010, 08:27:13 »

Thanks for the quick response- just one more thing...

What if that manager needed to get a value from a proxy ?

Simply retrieve the facade via the Facade.getInstance() property and get the proxy that way, still in the managers package - or now that its tied into mvc should we place the class elsewhere ?

cheers

m.
« Last Edit: February 22, 2010, 08:34:46 by mattb » Logged
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW Email
« Reply #3 on: February 25, 2010, 06:59:47 »

I don't know about your case, but when I interface with managers, utilities, etc, I put a command between them and any Proxies.  So the command will touch the proxy and then set whatever data is needed on the Manager. 

This assumes that the event driving the process originates from a Mediator, Proxy, or other Command in the first place.  I try to write my logic so that it always does.  In fact, I consider there to a problem with my design if that is not the case.  I mean, that is the raison d'etre of PureMVC, right?  (not being sarcastic)

Anyway, I don't know what the best practice rule is, but I try to avoid calling Facade.getInstance() like the plague.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #4 on: February 26, 2010, 11:01:51 »

What if that manager needed to get a value from a proxy ?
Then it is probably better written as a Mediator who communicates with the system manager rather than a normal component. The system manager can be thought of as a view component, even though it's not part of the view hierarchy.

'Managers' and 'helpers' tend to be amorphous classes without clear responsibilities. It's better if the actors in your system have clear roles, responsibilities and collaborations.

-=Cliff>
« Last Edit: February 27, 2010, 08:46:08 by puremvc » Logged
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW Email
« Reply #5 on: February 28, 2010, 06:51:55 »

What if that manager needed to get a value from a proxy ?
Then it is probably better written as a Mediator who communicates with the system manager rather than a normal component. The system manager can be thought of as a view component, even though it's not part of the view hierarchy.

(emphasis mine.)

I find this interesting and confusing at the same time.

I've always approached Mediators as requiring a viewComponent instance to mediate.  But reading the above, it seems the Mediator class can be thought of as a sort of catch-all class for doing anything the Proxy or Command isn't clearly supposed to.

So for example, in my case, where I use a Command to access the PopUpManager and have it .addPopUp() a view component passed via the notification.getBody(), I should really have a PopUpManagerMediator class???  (even though the PopUpManagerMediator would not be shepherding any specific view component)

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



View Profile WWW Email
« Reply #6 on: March 01, 2010, 07:50:47 »

I've always approached Mediators as requiring a viewComponent instance to mediate.  But reading the above, it seems the Mediator class can be thought of as a sort of catch-all class for doing anything the Proxy or Command isn't clearly supposed to.

I wouldn't call them 'catch-all' classes; they have clear responsibilities. The thing that is variable is what the Mediator actually mediates. 90% of the time this is actual components in the view hierarchy. But system 'manager' classes are equally applicable to mediation. The effect is the same. All knowledge of that manager is relegated to this one Mediator class, who communicates with the manager on behalf of the application.

-=Cliff>

Logged
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW Email
« Reply #7 on: March 01, 2010, 08:54:20 »

Thanks, that clears things up a bit.  I'll stop using Commands to tell my manager classes what to do.
Logged
Pages: [1]
Print