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: Employee Admin  (Read 6693 times)
Roustalski
Jr. Member
**
Posts: 13


View Profile Email
« on: January 07, 2009, 10:11:40 »

In the Employee Admin example, the role panel and the user form are both driven by a selection from the user list.

Why would you send a notification through the framework for a selection from the list, which the two sub-components have interest in, when you could just load the user vo into the subcomponents themselves based on "select" event? I guess technically they aren't sub-components because they are at the same hierarchical level in the application, but I consider them to be sub-components because they have no use until driven by the list. Is that a fair assessment?

I understand you want to keep everything as decoupled as possible, but for what gain? I can't re-use those components elsewhere unless I get the select notification from some other component. Sure, that other component could live anywhere else in the application, but at that point, the context is gone, and so why should I drive those two forms without the user list component?

If I launch that "select" event from a different type of list (even with the same type of data, just used for a different purpose, or the same component, but a different instance used in a different context) and I have the role panel, and/or the user form open, but not really the focus, those components will change.

So I guess my real question is:

At what point do you consider decoupling views? Shouldn't the views have some sort of dependency on each other, especially in the case of the EmployeeAdmin demo?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: January 10, 2009, 08:18:24 »

At what point do you consider decoupling views? Shouldn't the views have some sort of dependency on each other, especially in the case of the EmployeeAdmin demo?

The point of routing of notifications to the views was to show that although those components might be arranged in a hierarchy in the view, to the application they need not be hierarchical at all. It illustrates that you do not need to have the components be dependent upon each other. Decoupling actors wherever possible is the general path to reusability in OO software.

Why would someone do it the way I have as opposed to just having the subcomponents rely on intimate knowledge of each other? When you work on a large app where a number of people are developing or modifying the code, you can make progress with the 'divide and conquer' approach.

If all these components were simply in the same MXML file, only one person could edit them at a time. And if you need to reuse one of the components in another setting, you can't really, without copy/paste coding and then modifying it to work in its new surroundings.

The solution is to make separate custom components, as the demo does. Now three developers can work on the code not just one. Next, the components need data and will raise events when they need to alert the system of user interaction. Beyond that they have no need to be aware of each other. This is why mediators take the role of feeding the components their data, and listening to their events, and notifying the rest of the system on their behalf.

Hope this helps,
-=Cliff>

Logged
Roustalski
Jr. Member
**
Posts: 13


View Profile Email
« Reply #2 on: January 12, 2009, 07:16:00 »

Got it.

Now, I need to know if I'm misusing the mediators.

Beyond that they have no need to be aware of each other. This is why mediators take the role of feeding the components their data, and listening to their events, and notifying the rest of the system on their behalf.

Do you recommend doing things like setting dataproviders on grids directly - or - be as rigid as giving the view component an interface that the mediator uses to communicate with the view, or something in between?

I ask because of this:

In Cairngorm, the best practices is to bind the Model directly to the view (which I think is horrible anyway) and that goes against any MVC architecture IMO. So, lets say I have a button who's enabled property needs to be driven by a field in the model, which is driven by whatever circumstances it needs.

So, in cairncrap, we would say something like <mx:Button id="btnMyButton" text="My Button" enabled="{Model.getInstance().buttonEnabledProp}"/>

In pure mvc, the mediator would receive a notification, check the value on the model, and either set the enabled property by saying myButton.enabled = true/false or do some sort of communication through an API (aka interface aka setter).

It seems to me that since the logic of the button's enabled property is driven by the mediator, that the component becomes useless without it's mediator master, and therefore can't be re-used without some re-factoring.

So, with this example (and with some of the pureMVC examples), it seems that it would be better to use an interface to enforce the correct behavior of the mediator/view interaction. No?

Additionally, this leads me to my original question. Since it is easy to fall into the trap of the view becoming slave to the mediator, with a composite component that is made up of a lot of sub-components, and their sub-components, and etc, how do we manage this and all of the notifications in the pure mvc manner?

Is there a better way to handle constants? I know the app facade is a convenient place to put them, but is there another best practice way?

Thanks Cliff.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: January 13, 2009, 06:30:18 »

Ok, what you are describing is the code-behind approach often found in the .NET world.

You still need to encapsulate your view component's implementation. You are correct that binding the view to the model as cairngorm does is not the right approach. It makes that view component dependent on the framework and therefore less portable.

However making the mediator listen for and update fields inside the view component breaks the component's encapsulation. True, within the scope of your app that mediator has no reason to exist except to mediate communications with that component, but letting it know too much about the component means when the component changes, often the mediator must change.

You don't have to go to the extent of makint your components implement an interface, but you could and it wouldn't be bad.

Take a look at the EmployeeAdmin demo again. It has lots of ui bits that enable and disable themselves locally as you interact with it, based on the data in the component. Internally within the components is the place for Flex Binding. Its perfect for causing a button to conditionally enable itself based on its neighbors or data local to the component.

-=Cliff>
Logged
Pages: [1]
Print