|
This page explains the basic usage of K2BWebPanelDesigner, as well as some advanced features. It is targeted to new users of this tool who wish to learn how to use it.
As you probably know, K2BWebPanelDesigner is a GeneXus extension created to help developers build web panels in a simple and productive way. To achieve this, a new part is included in all web panels that the developer can choose to activate in each web panel.
When K2BWebPanelDesigner is activated, it generates and maintains all parts of the web panel so that it implements the specification described by the developer in the Designer part.
 |
| K2BWebPanelDesigner application |
The development cycle is shown below. The developer has to go through these steps:
- Activate K2BWebPanelDesigner in the Designer part part.
- Describe the interface desired in the Designer part.
- Save the web panel. K2BWebPanelDesigner will generate the Web Form, and initialize the Events part. In particular, all user subroutines will be generated for the elements included in the specification.
- Complete the user subroutines necessary to obtain the desired behaviour. See rule number five below.
- Continue editing both the Designer part and the Events part until the desired behaviour is obtained.
 |
| K2BWebPanelDesigner development cycle |
This video should help understand the development cycle.
|
| K2BWebPanelDesigner development cycle example |
To use this tool correctly nine simple rules must be obeyed.
The web panel's web form will be generated entirely by K2BWebPanelDesginer. The developer must describe which elements are desired inside the designer's specification, and let the tool do its work. Also, the developer will not think about low level HTML elements. Instead the developer must think in abstract terms, specifying what is desired and not how to obtain it.
This rule has one exception, but it will be explained later.
In K2BWebPanelDesigner the specification tree starts being empty, unlike patterns where the tree starts having a default specification called the "default instance".
The inference present in patterns is very useful because when the developer starts desiging the interface a large part of it has already been defined automatically in a way that suits most use cases. When creating K2BWebPanelDesigner a choice was made to include actions in this tool with logic similar to this inference, so that the developer would not have to design the entire interface manually.
For more information about the actions available to the developer see K2BWebPanelDesigner Actions.
 |
| Available actions example |
K2BWebPanelDesigner generates no rules, so the developer can edit this part in any way. For example, the developer may add parm or prompt rules.
K2BWebPanelDesigner generates variables for many purposes. Some are related to the variables placed in the interface by the developer in the Designer part. Other variables are included in the web panel because they are used in the code generated by K2BWebPanelDesigner.
It is important to note, however, that the developer may define any variables needed to implement his code. This will apply to all variables used in events coded by the user which are not present in the interface. (See rule 5).
K2BWebPanelDesigner generates code in the "Events" part, but the developer can include code there also. However, a criteria must be defined to know which pieces of code belong to the designer, and which belong to the developer.
The separation works as follows:
- All events (Start, Refresh, Load) belong to K2BWebPanelDesigner.
- All generated subroutines whose name starts with a "E" belong to the designer.
- All generated subroutines whose name starts with a "U" belong to the developer.
- All subroutines created by the developer belong to the developer.
The developer cannot modify the code owned by K2BWebPanelDesigner. If this happens, the code will be restored to its original version when the designer part is modified.
This may seem a serious limitation, but that is not true, because K2BWebPanelDesigner includes, inside each piece of code it owns, invocations to a user subroutine (whose name starts with a "U"). Inside these subroutines the developer can code the desired behaviour for specific parts (for example, determine how to load a grid, or what to do when an action is executed).
To see the benefits of this separation of which events belong to whom, see Benefits of having WPD and user subroutines separated.
It often happens that a control or variable starts having a name, and later the developer wishes to change that name. Using K2BWebPanelDesigner this is not an issue. If controls or variables present in the Designer instance are renamed, all ocurrences of the control or variable are renamed (even in user code!).
Let's see an example. Below a web panel specification is shown. The web panel's Designer part tree contains many nodes, among them an Action called "SelectCustomer", and a Filter variable called "MyCustomerId". The developer has already included code inside the user subroutine associated with the action.
 |
 |
| Initial stage |
State after changing both the action's name and the variable's name |
Later, it was determined that the action should be named differently, and that the variable should also be renamed. As the image below shows, K2BWebPanelDesigner detects this name change, and modifies the event code to match the new names. The names of the event and the subroutine associated with the action are modified, and all ocurrences of the variable are also renamed.
K2BWebPanelDesigner handles a varied set of controls and elements that can be used in an interface. Naturally some elements aren't handled by this tool, especially when using user controls, as they are created frequently and K2BWebPanelDesigner can't support all of them right away.
Does this imply a limitation on the web panels that can be generated with K2BWebPanelDesigner? Fortunately, no. When the developer finds a requirement that can't be met using the designer, the developer may add an "User Region". The developer may edit the contents of this region manually, by editing the contents of a div included in the web form. If the interface is changed in other ways, K2BWebPanelDesigner applies the changes needed respecting the content the developer placed in that region.
 |
| User regions can be included in the Designer instance |
There are scenarios where the developer may wish to stop using K2BWebPanelDesigner in a particular web panel. In this scenarios, the developer can simply execute the option "Release K2BObject Designer", and this will remove all the Designer part information from the web panel. The web panel's execution will work exactly as it worked before.
 |
| Release K2BObject Designer action |
Unlike patterns, when using K2BWebPanelDesigner all the object's specification resides inside the object itself. Because of this, it is easy to go back in the history of the object.
A common thing to do when using rule 8 is, after sending the object to the other developer, to go back in the object's history to return to the version with the Designer specification, and continue using this version.
|