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?

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.

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.

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?

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.