What is the best way to pass additional data to the View?

[djam]

Think of an application that has a Model, View, Presenter and a Command.

My View has a component, which is a summary of a data set(data and summary data resides in the Model), View fires event that basically is a request to generate a detailed data for a specific case (think of a datagrid, user double clicks the cell and a cell details should come up in a popup, special region on the view, etc...). The event reaches the Command (thru Presenter), which generates this small piece of data and now the question is:

What is the best way to pass this small/temp data to the View?

#1 - Conceptually, this small piece should be a part of the summary data in the Model... If I add it to the Model, how the View should get notified about the change?
#1a - Fire an event from Presenter once Command is done?
#1b -Watch for a data change in the View?

#2 Or, don't store this too "temporary" data to the Model (also makes sense), just pass it to the View via Event from the Presenter?

[phil216]

Think of an application that has a Model, View, Presenter and a Command.

What is the best way to pass this small/temp data to the View?

#1 - Conceptually, this small piece should be a part of the summary data in the Model... If I add it to the Model, how the View should get notified about the change?
#1a - Fire an event from Presenter once Command is done?
#1b -Watch for a data change in the View?

#2 Or, don't store this too "temporary" data to the Model (also makes sense), just pass it to the View via Event from the Presenter?

As for whether this data belongs in the Model or whether it's temporary, I'd say it depends. You probably have a feel for whether this data is "application state" that other view components may reflect in the future. Or whether it's truly transient. I'd suggest picking the simplest approach that seems right, and refactoring in the future if necessary.

e.g., my application currently treats error codes (for messaging) as transient and not as application state. In some cases, the presence of one error means that we should suppress display of another error. It is possible that errors and the precedence rules can grow complicated enough that I'll need to represent them as application state in some model object. For now, the transient approach works for me but I may have to refactor it.


As for how to notify the view... my personal preference is for the view to have an API that outsiders can rely on - either a settable property or a method. The view shouldn't be listening for non-view events -- that practice just couples it to non-view components and reduces modularity, reusability and testability. I use mediator objects to decouple views from controllers.

Phil