- How to proceed?
- The steps for generating the window
- The elements generated by RAD
- Managing the errors in the classes generated by the MVP RAD
- WLanguage: Specific features used to simplify the MVP architecture
- "Mapping" attribute
- MyMappedFile and MyUniqueMappedKey keywords
- "Associated" attribute
- "Presenter" attribute: managing the refresh of views
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.
The generated code is free and it can be adapted according to the requirements: it is the generation of the basic application skeleton.
Caution: This development mode is using the OOP: it requires a good knowledge of these concepts. This development mode is an advanced development mode.
The steps for generating the window
To generate a window in "MVP RAD" mode:
- Click among the quick access buttons:
- The element creation window appears: click "Window" then "Window".
- The window creation wizard starts.
- In the wizard:
- Click the "RAD" tab.
- Select the "MVP RAD" pattern.
- Select the type of window to generate (Form or Table).
- Validate the wizard for window creation.
- The wizard for MVP RAD generation starts.
- 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.
- Validate 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 of all the Model classes (M for Model). It contains the basic features of the business code (that will be shared with the other model classes via the inheritance).
- CError: class for managing the errors. 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 the 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: manages the display of data in the view or table window.
- PFormMyExampleFile: manages the display of data in the view or form 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
IF NOT gclPresenter.bOK(clError) THEN
Indeed, only the view displays the possible errors (and not the model or the presenter).
This management mode of errors (procedure expecting the CError parameter) brings more rigor when developing the application.
WLanguage: Specific features used to simplify the MVP architecture
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,
- RequestRefreshUI and the process for updating the window (or the report).RequestRefreshUI and RequestRefreshUIParent and the process for updating the window (or the report).
The MVP RAD is using these new features but they can be freely used in any type of architecture.
The mapping attribute is used to create a "direct link" between the class and the data file.
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.
- 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 that differ from the analysis ones. To do so, re-use the mapping keyword on the members of the class to re-create the link between the member and its analysis item.
m_sEstateTitle is ANSI string <mapping=EstateTitle>
MyMappedFile and MyUniqueMappedKey keywords
In the MBase class generated by the MVP RAD, two keywords are used to simplify the management of mapping: MyMappedFile and MyUniqueMappedKey. These keywords are used to identify, for the MBase base class, the file and the unique key of 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:
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.
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".
PFormMyExampleFile is Class
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 re-create 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!
All you have to do is create the requested methods and properties in the "Presenter" class to overload the behaviors 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: managing the refresh of views
The presenter attribute is used during the global declaration of the generated windows. It is used to associate a class of the presenter layer with a view (window or report).
gclPresenter is PTableMyExampleFile dynamic<presenter>=Null)
Via this attribute, the call to the process for updating the display of the window will be triggered by:
, when deleting an element from a Table window generated by the MVP RAD, a request for updating the GUI 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 process for updating the "WIN_Table_MyExampleFile" window will be automatically called when deleting an element.
The process for updating the GUI is used to group all the processes for updating the window display instead of distributing them in several processes (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 requests for update performed in MMyExampleFile "impact" the form window.
Caution: The process for updating the GUI must not be run "anywhere".
Important: RequestRefreshUI is asynchronous: the process for updating the GUI is run at the end of current process and the calls to RequestRefreshUI are not stacked. This function and this mechanism can even be used outside an MVP architecture. This operating mode offers a huge benefit: if a process loop in the model performs 50 calls to RequestRefreshUI, a single and unique call will be performed when exiting from the process (in order for the GUI not to "blink").
Remark: to perform a request for updating the GUI in synchronous mode, all you have to do is call ExecuteRefreshUI.Important: RequestRefreshUI and RequestRefreshUIParent are asynchronous: the process for updating the GUI is run at the end of current process and the calls to RequestRefreshUI or RequestRefreshUIParent are not stacked. These functions and this mechanism can even be used outside an MVP architecture. This operating mode offers a huge benefit: if a process loop in the model performs 50 calls to RequestRefreshUI, a single and unique call will be performed when exiting from the process (in order for the GUI not to "blink").
Remark: to perform a request for updating the GUI in synchronous mode, all you have to do is call ExecuteRefreshUI (or ExecuteRefreshUIParent).
Click [Add] to post a comment