iMo Communities

Hi Stefan,

long time no see.

I am trying to build an MVP template, but run into some designdecisions that I have to make.

if I understand the MVP and its difference to MVC correctly, then in MVC the View can talk to the model, while in MVP this needs to be wired through the Presenter/Controller.

Got some questions on the implementation of MVP in ABL though,
1. If the view cannot reach the model, how is the data transferred and refreshed in the view? I caught up on my reading on the topic but the examples on the internet all use very simple examples, like displaying a value in a textbox. But what if the view needs to display/refresh the contents of a dataset. How to make that work:

Well, the model can publish an event to which the presenter is subscribed if the data has arrived from the server. Next the dataset is retrieved by the presenter from the model and passed through to the view for display. Although this works fine for a single value to be displayed in a textbox in the view, but with datasets we are talking about larger quantities of data of which we would have 3 copies in memory now: one for each component in the MVP pattern. This doesn't seem like a good idea.

Next option is to supply the view with the same datastructure as the model, however, with the qualification "reference-only". When the presenter launches the model and the view, it binds the view to the dataset of the model. Although this is much more efficient; we now have a strict (compile-time) dependancy between the model and the view, where the view can only work with this specific data-structure. Moreover the view can also change the contents of the data in the dataset. But the agreement of course is that the view should not do that. When for example the user adds a record in the view, an event (addRecord) and pertaining parameters (tableName + foreign keyvalue) should be published by the view and received by the presenter, that instructs the model to create a new record in the temp-table, returning the records rowid to the presenter which is then set in the view, enabling it to display the initial (and foreign key) values.
The same methodology can be used for updateRecord and deleteRecord. However, because of the fixed compile time dependancy of the datastructure of the view to the model, this looks more like the MVC pattern.

Final option is the use of the Progress BindingSource (PBS) object. Suppose the PBS is defined in the model and available for the presenter to supply it to the view. The view then links its UI objects to the bindingsource reference and we're off. This way, any action taken by the model on the queries of the dataset (top-nav-query and datarelation-quries) is immediately reflected in the view: because the PBS reacts on an open query or a reposition in the results list of the pertaining query, the changes are automaticaslly propagated to the UI objects. This way the view is no longer bound to the datastructure of the model, since this view should also be able to display other datastructures. This view could serve as a mockup. I know this works with a .NET GUI; not sure on other ui's.

2. Which events are published by the view. I gather that UI issues like enabling/disabling buttons should still be handled by the view. You don't want your presenter to handle this, otherwise it would be tightly coupled to the view, because it would need a reference to the specific button on the view. Data manipulation handling however should be delegated by the view to the presenter, which then forwards the call to the model.
At least the following events should be published by the view: addRecord, deleteRecord, modifyRecord, storeRecords and perhaps undo and copy. The presenter should not be subscribing to the click event of the button instigating some data-manipulation, because this would lead to high-coupling.

your thought on this.

regards,
Will