MVP RAD

ONLINE HELP
WINDEV, WEBDEV AND WINDEV MOBILE

Version:

Home | Sign in | English

Help / Developing an application or website / MVP (Model, View, Presenter)

Overview
How to?
The steps for generating the window
The elements generated by RAD
Managing the errors in the classes generated by the MVP RAD
Specific WLanguage features to simplify MVP architecture
Overview
"Mapping" attribute
MyMappedFile and MyUniqueMappedKey keywords
"Associated" attribute
"Presenter" attribute: Refreshing views

WINDEV

WEBDEV

WINDEV Mobile

Others

See also

MVP RAD

Overview

WINDEV proposes an MVP RAD that generates the "table" and "form" windows as well as the necessary Presenter and Model classes.

The windows correspond to the Views of MVP.

You can freely adapt the generated code to suit your needs. This mode generates a basic application skeleton.

Note: This development mode uses OOP. It requires a good knowledge of these concepts. This is an advanced development mode.

How to?

The steps for generating the window

To generate a window in "MVP RAD" mode:

Click in the quick access buttons:
- In the window that appears, click "Window" then "Window".
- The window creation wizard opens.
In the wizard:
- Click the "RAD" tab.
- Select the "MVP RAD" pattern.
- Select the type of window to generate (Form or Table).
- Finish the window creation wizard.
- The MVP RAD generation wizard opens.
In the wizard:
- Specify whether RAD must create a new Presenter class (option required if the MVP RAD was not already used).
- Specify whether RAD must create a new Model class (option required if the MVP RAD was not already used).
- Select the data file to use.
- Select the items to use.
- Specify whether RAD must create a new class for error management (option required if the MVP RAD was not already used).
- Customize (if necessary) the name of the classes that will be generated.
- Select the members of the model class that will be displayed in the window (the view).
- Specify the title and name of the window that will be generated.
Finish the wizard.

The elements generated by RAD

When generating a Form window and a Table window on a data file named "MyExampleFile", the MVP RAD generates 6 classes and 2 windows.

The MVP RAD generates 2 "base" classes:

MBase: Base class for all Model classes (M stands for "Model"). It contains the basic functionalities of the business code (which will be shared with the other model classes through inheritance).
CError: Error handling class. This class centralizes the code for managing the errors that may be signaled by the different classes (business errors or database errors).

The MVP RAD also generates 2 classes of the "Model" layer, specific to the project:

MMyExampleFile: Class reflecting business data. In this example, this class directly "maps" the structure of database "MyExampleFile" file (via the "mapping" attribute).
MArrayMyExampleFile: Model class for the table window. It contains an array of MMyExampleFile objects.

The MVP RAD also generates 2 classes of the "Presenter" layer, specific to the project.

PTableMyExampleFile: Handles data display in the table view/window.
PFormMyExampleFile: Handles data display in the form view/window.

Managing the errors in the classes generated by the MVP RAD

In the MVP RAD, the errors are supported via a CError class. Each procedure of the presenter expects a CError parameter. Therefore, the views can retrieve the possible errors generated by the presenter.

clError is CError
// Validation
IF NOT gclPresenter.bOK(clError) THEN
	Error(clError.FormatMessage())
	RETURN
END

Indeed, only the view displays the possible errors (and not the model or the presenter).

This error management mode (procedure that expects the CError parameter) allows for a more rigorous application development.

Specific WLanguage features to simplify MVP architecture

Overview

To simplify the implementation of an MVP architecture, it is important to identify and understand the specific WLanguage elements:

the mapping attribute (as well as the MyMappedFile and MyUniqueMappedKey keywords),
the associated attribute,
the "Presenter" attribute,
the RequestRefreshUI and RequestRefreshUIParent functions, and the window (or report) refresh event.

The MVP RAD uses these features but they can be used in any type of architecture.

"Mapping" attribute

The mapping attribute is used to create a "direct link" between the class and the data file.

Example:

MMyExampleFile is Class,mapping = MyExampleFile

Via this attribute:

MemoryToFile will automatically copy the value of class members into the items of current file record.
FileToMemory will automatically copy the items of current file record into the class members.

Important:

In order for this mechanism to operate, the names of class members must be identical to the names of items in the data file.
If necessary, the mapping attribute allows you to use prefixes or names other than those used in the analysis. To do so, reuse the mapping keyword on the members of the class to recreate the link between the member and its analysis item.
Example:
```
m_sEstateTitle is ANSI string <MAPPING=EstateTitle>
```

MyMappedFile and MyUniqueMappedKey keywords

In the MBase class generated by the MVP RAD model, the MyMappedFile and MyMappedUniqueKey keywords are used to simplify mapping. At the level of the MBase class, these keywords are used to identify the file and the unique key of the model:

MyMappedFile references the data file defined by the mapping keyword in the "Model" class.
For example, the following code is used in the bSave method of the MBase class:
```
HReset(MyMappedFile)
```
This code will perform a call to HReset on the data file for which the RAD was generated.
MyUniqueMappedKey references the item defined by the "unique key" mapping in the "Model" class.
For example, in the MMyExampleFile class, MyUniqueMappedKey is equivalent to the MyExampleFileID item:
```
m_nMyExampleFileID is int<MAPPING=MyExampleFileID, unique key>
```

These keywords allow you to use generic code in this base class.

"Associated" attribute

The associated attribute is used to access the members, the methods and the properties of a Model class from its Presenter class without having to perform any "rebounds".
Example:

PFormMyExampleFile is Class
 PROTECTED
m_clCurrentModel is MMyExampleFile <associated>

In the above example, the PFormMyExampleFile objects have an "associated" member whose type is MMyExampleFile.

The PFormMyExampleFile objects directly expose the methods, properties and members of the associated class, without having to redefine them.

Via the associated attribute, there is no need to systematically recreate all the properties in the presenter class to expose the members of the model.

The MVP architecture generated by RAD contains generic classes and classes specific to the project. It can be entirely customized!

Simply create the desired methods and properties in the "Presenter" class to override the behavior of the model.

You have the ability to link a control to a member or to a property of the "Presenter" class. Therefore, this link can be performed on all the member or properties of the "Model", exposed by the "Presenter" class with this mechanism.

"Presenter" attribute: Refreshing views

The presenter attribute is used in the global declaration of the generated windows. It is used to associate a class of the presenter layer with a view (window or report).

For example:

PROCEDURE WIN_Table_MyExampleFile(...
	gclPresenter is PTableMyExampleFile dynamic<presenter>=Null)

When this attribute is used, the call to the window refresh event will be triggered by:

any call to RequestRefreshUI or RequestRefreshUIParent from a class declared as <presenter>,
any call from any class associated with the <presenter> class.

For example, when deleting an element from a Table window generated by the MVP RAD, a request for updating the UI is performed by the call to RequestRefreshUI:

MArrayMyExampleFile is associated member of PTableMyExampleFile,
PTableMyExampleFile is defined as "presenter" of the "WIN_Table_MyExampleFile" window.

Then, the refresh event of "WIN_Table_MyExampleFile" will be automatically called when an element is deleted.

The UI refresh event allows grouping all the window refresh processes together, rather than distributing them into several events (click, etc.).

This mechanism is also found in the form window. The form window is linked to the presenter class PFormMyExampleFile containing an associated member MMyExampleFile. Therefore, the refresh requests performed in MMyExampleFile affect the form window.

Note: Choose carefully where to execute the UI refresh event.

Important: RequestRefreshUI and RequestRefreshUIParent are asynchronous. The UI refresh event is executed at the end of the current process, and calls to RequestRefreshUI or RequestRefreshUIParent are not stacked. These functions and this mechanism can even be used outside an MVP architecture. This method has one major advantage: if a process loop in the model calls RequestRefreshUI 50 times, WLanguage will perform one single call at the end of the process (prevents the UI from flickering).
Note: To request a synchronous UI refresh, simply use ExecuteRefreshUI (or ExecuteRefreshUIParent).