Pavuk Internet Development Framework v2.0 - Part 2: Pavuk Elements - The building blocks of applications
In Part 1, we discussed the overall framework of Pavuk IDF. We learned how to quickly build a simple application by placing elements into database definitions and to link the definitions to running forms. In this part, we will discuss what Pavuk database elements are and how they facilitate all aspects of application development.
Before we can discuss Pavuk Elements, we must briefly look at the restrictions of any underlying database. Databases fall into two categories, relational (i.e. SQL) and post-relational (MultiValue, NoSQL, etc.).
In relational databases, each field is defined by a column. Each column is data-typed. It may be a string, integer, boolean, floating-point, or variant. Each column has a fixed maximum length. These are very rigid structures. Creating applications inside the purely relational model requires careful planning and does not suit itself to ad-hoc changes to definitions — especially on a running system. The lack of flexibility is a key weakness in an ever-changing business environment.
Contrasted to a purely relational database is the post-relational database. Inside the post-relational model, all records exist as delimited strings. The delimiters provide structure to the data records. Typing of data is done at run-time. Query processing is based upon the use of "data dictionaries" that describe the structure of the data to the query processor. By virtue of the fact that post-relational systems are handling strings, they do so very efficiently and tend to outperform relational databases. Field length is variable and is limited only by memory or to a bit over 1GB! This is useful when a datum exists of a length larger than had been planned.
A full comparison of relational versus post-relational systems is beyond the scope of this article. The opinion of the author is that the advantage to solving real-world database problems goes to the post-relational model. Pavuk IDF leverages the strengths of the OpenQM database as its underlying data store which, in turn, provides the foundation for Pavuk elements.
At the core of the field definition is the Pavuk element. Every field that is used must have an element. In the relational model, an element would be : string, integer, float, bool, or variant. These are not very useful by themselves and require a lot of programming to process what the application engineer wants them to really be. In short, they are simply too abstract and general.
By contrast, Pavuk elements are useful definitions of common things that designers use every day. They define what the field means on the functional level as well as create the underlying storage, data dictionaries for query processing, input fields for forms and back-end processing of input data. The application designer is now dealing with elements that have intrinsic meaning and context in the real world. This representation of real-world datum in a pre-defined element is enabling technology for non-programmers to build running applications. For the programmer/analyst, many repetitive tasks are removed thus speeding development and enabling the focus of labor on writing API routines to solve complex business needs.
Elements are specific, and they are targeted to solve a specific need for storage in a database field on the functional level. When a column is defined as "string" in SQL, it tells us nothing about what that field means or how it should act. That requires programming. When we use an element such as 'Person Last Name' in a Pavuk field definition, we now know a lot about this field. There is value in the reduction of labor to create a functioning system by having many common data items pre-defined. This keeps with the engineering maxim that "form follows function."
Pavuk v2.0 includes 65 pre-defined elements that are ready to use. Simply plug in the elements needed for a database in the Database Designer fields and the application immediately begins to take shape.
Pavuk v2.1 will include many new currency and geo-spacial information systems (GIS) elements: Currency-GBP, Currency-Euro, Latitude, Longitude, Transverse Mercator, etc. These elements meet the needs of our international users with multiple currencies and with our civil engineering and transportation users with GIS elements. New elements are defined as their need arises. Items that are single use may be represented using one of the generic elements.
In the Database Designer, every field used requires an element definition. The element assigned to the field controls the major actions of the field. Further customization of the field is available on the field's property sheet. Should a field be required, this may be set along with a number of other properties. When our database definition is saved into Pavuk, it reads the field definitions and performs the following actions:
- Creates the input fields and labels for forms (Javascript rendering)
- Links the back-end initial validation routines
- Creates all data dictionaries for the Query processor
- Creates any alternate-key indices
Figure 1 shows the field property sheet.
Fig. 1
Let's look at a few examples in detail.
'Person Last Name' is an element. It does a number of things for us. It creates a text input box on our form. This box has a default label of "Last Name". This default label is also applied to the data dictionary that is used by the Query Processor to produce output for it as well as on the standard report form. Pavuk performs preliminary field validation on input data. Last names may require special processing for names that have "Mc", "Mac", "Van der", "von", etc. This processing needs be coded only once into the main Pavuk validation library and as many times as a 'Person Last Name' element is used, the processing rules apply.
'Date' is another example of an element. It creates not only a text box for input of a date on the input form, but also populates a calendar control linked to it for easy selection. Pavuk further creates Javascript to do initial validation on the browser and final validation on form submission to the Pavuk web server.
'Person Title' is an element that has a pre-defined set of allowed values. A user may pick only one. On the form, this is displayed as a select box that has a drop-down of the values from the element definition.
'Gender' is an element that has only two allowed values: "Male" and "Female". Because a creature may have only 1 gender assigned, this is rendered as a radio control.
'TextArea' is an element that presents an editor window for entry of free-form text. It behaves as a mini-word processor. Internally, the field data is HTML. This is a very useful element when free-form notes are needed. It is used by Pavuk itself as a means to document each field in the Database Designer.
Pavuk includes a standard set of generic elements: Radio, Text, Check, Select and Combo. Designers are free to use the control that enforces the proper entry of data into their system. As discussed in Part 1, any database or form may call as many API routines as needed for additional validation and processing in the backend. APIs are simply BASIC subroutines. They will be discussed in a later article.
Pavuk IDF makes a conceptual break with the traditional methods of creating forms where the form field type is determined when the form is created using an HTML editor. The philosophy behind the use of Pavuk elements is that the database designer will decide the appropriate control for the type of data in the database. A form should merely provide a container for the control that the application designer has deemed appropriate. It is the database designer who knows if a field should be exclusive (a radio button field) or non-exclusive (checkbox field).
This is a shift in the paradigm of traditional development where the application developer must coordinate with the graphic artist to ensure that the form controls are logically consistent with the database on the backend system. This business process is eliminated entirely using Pavuk IDF. The form field javascript is generated dynamically by Pavuk. Forms are simply containers for groups of Javascript objects which are linked to the database system.
As a form is a container for fields in a database which are defined by elements, elements themselves are containers for some sort of data that we wish to assign into the field. Elements such as 'Person Last Name' are purely textual and have no pre-loadable values. Other elements like 'Person Title' are loaded from a list of values. A select, check or radio field can obtain its values from one of 5 places:
- A default list included in the element definition itself.
- A list inside the database field definition populated in the Database Designer.
- A list generated by a pivot to another database.
- A list generated by an ad hoc database query.
- A subroutine or function call.
Which method is used to populate the value list is up to the application designer and is configured in the property sheet for each field in a given database definition.
Figure 2 shows the field property sheet for field 10, which is our "Spectrum Type". The list of values is in the field definition itself in "Local Texts" as simply a comma-separated list.
Fig. 2
Because our Spectrum Type is configured as a Checkbox field, the values will load into our finished form where the user may select none or as many as they wish. Should we wish to make this field required and allow only one selection, we change the element to a Radio and set Required to Yes.
Figure 3 shows our change.
Fig. 3
In Figure 4, we see the change of the field to extract its list of values from a Pivot Validation file. This file is conveniently named U.TYPES and is a database of the types of Spectrum contacts.
Fig. 4
It really is that easy. We needed a larger number of types, so we created a database to hold them and linked that database to our People database. Pavuk will create a select box and automatically load it with all of the records that are in the U.TYPES database for the user to select when running the form. Adding another type is simply to create another record in this Spectrum Types database.
Our form has automatically changed as shown in Figure 5. The Spectrum Type is now a selection that reads from the U.TYPES database. Just for fun, it is now required.
Fig. 5
We have only touched the surface of Pavuk Elements. More complex elements such as Address perform many special operations such as supporting international address formats and languages.
As in Part 1, we have not yet written any code of any type. Pavuk has taken our database and form definitions and rendered dynamic Javascript using the ExtJS library. It is also handling our communication between the web server and the database. We have focused on using Pavuk to create our application.
In Part 3 of our series, we will discuss the Pavuk file tree structure and the focus on the use of pointing devices for application navigation. We will also cover binary attachments and audit trails. Future articles will cover API integration, Cloud Computing/SAAS deployment and international language support.
