In Getting started with K2BWebPanelDesigner the separation between user events and WPD is explained. In this page the benefits of this separation are shown. There are many ways in which user and generated code can be separated in GeneXus. The most common are using comments and using subroutines.
When designing K2BWebPanelDesigner, a choice was made to perform this separation using subroutines instead of comments. The reason behind this choice is that subroutines have a strong semantic meaning inside GeneXus that comments do not have. This leads to the following:
- The limit between user and generated code is clear and not ambiguous.
- The developer can take advantage of the GeneXus parser to locate the locations where code can be inserted, by simply looking for subroutines starting with a "U". If comments were used, the developer would have to scan the entire code to get an idea of where code can be inserted, and also to reach specific parts of the code he has inserted before. In conclusion, the subroutine solution gives the developer significantly better usability.
 |
| GeneXus's parser can be used to find user subroutines |
- Using comments, a frequent problem is that the developer accidentally deletes one of the comments limiting the user code, leading to errors and confusion. This is far less common using subroutines, because the developer immediately identifies that there is a semantic value associated to the subroutine, and also because GeneXus' parser will give an error when trying to save the object.
Some of the things that can be specified in the Designer instance affect the events code, and not only the web form. The simplest example is the definition of conditional confirm in actions. In the image below, the effects of activating the conditional confirm property in actions is described.
 |
 |
| Before activating conditional confirm |
After activating conditional confirm |
Note that because of having the user code in a separate subroutine, the only portion of code modified belongs to WPD. This is important, because it means that the developer must not think about whether the action will have conditional confirmation or not when programming its action. Moreover, if an action has already been developed, it is safe to activate confirmation for the action, knowing that the previous code will not be affected.
|