To reuse or to redo.. that’s the question…

Redoing recreation….
When we were children we used to watch repeatedly that movie we enjoyed so much, we used to read over and over again that book that was so fun for us before sleeping. We loved to play once and then again the games… and we still do that. We still enjoy going to eat at the same restaurant, visiting the same friends, playing the same sport, listening to the same music etc.
It is very enjoyable for us to “redo” some aspects of our lives, we like it, we do it and redo it, and we feel happy about that, don’t we?






Redoing work…

Didn’t we listen or say something similar to this before? “Oh no! There is no milk in the refrigerator, I have to go again to the supermarket!” – or – “I wish I had a robot to prepare my coffee, to bake a cake every morning, to dress my children and take them to school, laundry”…

We “redo” everyday a lot of tasks that we do NOT enjoy and we would prefer them to be already done, wouldn’t we?

A solution not to redo what we don’t like to: REUSING
When developing and analyzing web applications we realized there are certain common problems for all web applications, even if the ways of solving them are different.
As a result of that, when we start to develop a new web application, we need to develop the same components we have done repeatedly before, in order to assure that the “common problems” will be solved for this new web application too. So we need to REDO; we don’t like that, and maybe we can’t do that because time is precious and it is not possible for us to spend so much time doing something we have already done so many times in the past.
So, we ask ourselves what would happen if we had “that robot” to “redo” all this solution for us? Maybe, to prepare coffee or to fry an egg it’s not affordable to have or maintain a robot; maybe we cannot buy a machine to redo for us a complex task. But, what about redoing something that can be saved and reused without effort?

The GeneXus USA CORE

GeneXus USA has developed a GeneXus core module which is used at the beginning of every web application project. It is a set of Transactions, Tables, WebPanels, Procedures, Structured Data Types; a set of basic developed functionalities very useful for all applications. It is “table driven.”
The driving forces for creating Core were SECURITY, Menus, and to save time. Core still lets developers customize their application for their particular application by simply implementing some GeneXus objects that will be explained.

A very simple example
Starting a new KB with a very important base: the Core, I have created three very simple transactions and applied to them the Work With Pattern. Now that I have my web application, I would like to make it a secure web application; so I will reuse the core security module and by implementing a very simple set of procedures my web application will be ready to be used by different users, with different roles and permissions!


What did I have to do?

1. Initialize/Create all the pages
2. Initialize/Create the application Roles
3. Add pages to Roles
4. Create Users
5. Add Users to Roles
6. Add menu/submenu
7. Set the application parms
8. Prepare and run the RoRunOnce routines





1. Initialize/Create all the pages

We call initialize a page to add a reference to the page into the system database. A page can be either a Transaction, Webpanel, Report or a WebComponent.

The core provides a “Pages” table where the system checks the security for each page. In other words, security is defined by page. In order to do this all the pages must be defined in the system using a procedure. By default the core will load its own pages in the page-table but each application will need to create their own pages in this table.


If we have a lot of different “pages” that conceptually are different modules, we should create a special procedure for each module that inserts into the Pages table (CePages) the reference for the transactions I have created. It also adds the reference for all the pages that were automatically generated for the Client, Invoice and Product by applying to them the WorkWith Pattern.


2. Initialize/Create the application Roles

Core comes with two preset roles: ADMIN and Root.
In the majority of the cases, these 2 roles are not enough for our application purposes; that’s why we could need to have a bigger set of roles. In order to easily achieve that, the core has a “Roles” table which saves for the system the different accessible roles (by default it comes with ADMIN and Root).

I have created a procedure that inserts into the Roles table (CeRoles) the reference for two new different roles.



3. Add pages to Roles
Once we have defined the pages and the roles our application will have, we need to tell the system what their relationships will be. In other words, which roles will be able to access which pages.





4. Create Users
The core already comes with pre-defined ADMIN and SYSTEM users, which are allowed to use all the pages of the system. Both are saved into the Users table (CeUsers) from where the system takes the information for the login.

If we want to add more users to the system, we can do it either at the beginning of the project, by adding the information from a procedure (like in the previous examples), or by inserting them manually with the WorkWithUsers webpage on the web application.

We recommend inserting them by a procedure in order to be able to reproduce it in a specific case.
I have created for this kb two users in order to make the first one have the first role I had added, and the same for the second user with the second role.


5. Add Users to Roles
Once users and roles are ready, it is time to tell the system which users will be configured for which roles.


6. Add menu/submenu
The core implements a User control (JSCookMenu) and it comes with a predefined menu.
The “predefined” menu is a dynamic menu that loads it titles and links from a “Menu” table (CeMenu).
If we want to add menu tittles with their submenus and links, we have to create a set of procedures that initialize that information into the CeMenu table, in order to load that information at the beginning.


7. Set the application parms
The core uses a “Parameters” table (a very often-used and known concept for applications) that already comes pre-loaded with some useful parameters.
If needed, we can add more parameters to that table and simply access them from anywhere by calling the related procedures (already developed into the core) to access, delete or update any parameter.


8. Prepare and run the RoRunOnce routines
Once we have defined all the settings that we need in order to customize the security of our web application, we need to call all the procedures that initialize the information, from a unique webpanel that will be called just once, before starting to use the system.
Therefore the name of the webpanel: RORunOnce.



The RORunOnce webpanel is the one in charge of loading all the preset information into the system. Once it has been run, the system is ready to be used with security and menus!