One of my apps stores some configuration information in an XML file on the local disk.

On startup, a proxy reads in the XML via a delegate and sets it's data property equal to a new configuration dto.

Should it then send a notification with the XML/Dto as the body for a command to load the DTO from the XML, or should the proxy load the dto from the xml as a private method?

What is the best way to go vise versa?

The user is ready to save their information and the proxy is notified that it needs to save the configuration. Should the proxy load the XML from the Dto and have the delegate save it to the local disk, or should there be a command that is passed the Dto/Delegate and the command invokes the save method on the delegate after doing the Dto to XML conversion?

I like the idea of some generic commands with generic Dtos and Generic delegates that are then extended for more specific use cases, and that way the proxies truly are just a way to persist the data and fire commands without really knowing much about the data. Am I on the right track?

I have a composite component with a data grid in it with a few columns.

There is a new requirement for the user to be able to save the sort and order of the columns through logins. Classic user preferences.

What is the best way of going about persisting the state of the view?

More specifically, would there be anything wrong with storing some objects with the datafield/headertext in the appropriate order, and then in a command, build the columns dynamically from this list, which is then fed to the view via mediator?

Is there a better way?

What about multiple "tables" who need to be grouped together?

Do you have some sort of intermediate step in the model that formats (e.g. groups into a hierarchy), but still left in the raw format before passing off to another actor?

What is grouping/data structuring classified as?

Should there be a proxy for each table, and then another proxy that does the management of each grouping or structure for the data?

Where should things like number formatters happen?

I would assume the proxy, but what about the case of an item renderer formatting an epoch number into a date?

Or maybe you have a total price label and the proxy has the variable stored as a string. Should the proxy format the string, or store it as a number and let whoever cares deal with it? (in this view's case: $123,456,789).

Thanks.

Awesome,

I'd be interestd in seeing your design when you're finished if you are still willing to share when that time comes [:

What reasoning do you use for keeping the parameters in a different proxy as opposed to the one who will actually use it?

In this simple scenario at least...

Lets say that view comp 1 with mediator 1 has a text field for searching.

View component 2 with mediator 2 has two date fields for start and end times for the search.

Lets also say that view component one dispatches an event to initiate the search, the mediator translates that to a notification/command pair. The command then retrieves a proxy and invokes a method that requires all 3 parameters.

How would you handle this?

The options as I see it:

1. View Comp 1 grabs the time params from View 2 and exposes the API to the mediator.
2. View Comp 1 Mediator 1 grabs the time params from View 2 Mediator 2, and then sends the notification with all 3 parameters
3.View Comp 2, when initialized and interaction with the time controls occur, sends a notification that maps to a command that sets the time parameters on the proxy. View Comp 1 then sends it's normal notification with its parameter, the command invokes the search method on the proxy with the search text, and uses the already stored time values from the other notification.
4. Some sort of AsyncCommand magic, where each mediator is polled (via notification I presume) for it's parameters and then launches the search command.
5. Other?

Thanks.

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.

I haven't seen the demo you are talking about, but:

1. You are right in my opinion, where it would be cleaner to just pass in a the class rather than an integer that corresponds to a class.

2. The only thing I can think of is that the component would load multiple times at runtime and therefore potentially fire the events multiple times. That is also of course assuming that cleaning up of the mediators via removeMediator() from the facade was not called. (even though I thought I remember a thread explaining why we might not want to remove mediators due to efficiencies sake. *shrug*

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?

Well, the attachment was too big. Perhaps email me and I can send you the example?

I wanted to do a little test to see if the name constants for all types were unique per singleton instance.

For example, I have two application facades with different keys. I then have an application mediator for each, but with the same name. It appears as though somewhere along the line, the same names are conflicting when I would expect them to be partitioned off by the facade key.

Is this assumption not correct?

I've attached my demo project showing the problem, but let me describe:

I created a hello google project which requests html from www.google.com and loads it into a text area. I then copied all of the files and placed them in a different package structure and appended "2" to the NAME constant of the second ApplicationFacade class. I also changed the URL from www.google.com to www.yahoo.com

When I click the first load message button, google HTML is loaded into the text area, but when I click the second, it fires and event in the first ApplicationFacade's domain or instance.

Are the facade keys not a partition sort of like application domains? If not, we have to make sure all classes in all projects have unique names? It seems like 2 separate projects using common names would need to keep notifications separate for obvious reasons.