0 | 380
Model View Controller (MVC) is a design pattern that advocates for separation of the presentation, actual data and business logic of an application. The benefits accrued of this division enhances collaboration and team work. Designers and frontend developers get to work on the presentation side, backend developers on the business logic and database administrators manage the data.
CRUD (Create, Read, Update, Delete) are the basic functions that enable us to create an MVC application. This article will touch on the Create and Update aspect from the "View" or presentation perspective ie the frontend. "Create" and "Update" in MVC can either be API or form driven but the latter is the primary source and largely used way of managing the model. A form is a group of HTML elements that's a representation of an underlying database schema. The form is the face on the mirror of the database. The form can be presented as a full page, a part of the page or a popup.
Regardless of the strategies employed to present the form to the user, creating the HTML form is a time consuming task. Especially, since most MVC frameworks postulate we have a separate file for both "create" and "update" functions. For instance, a form that has "first name" "last name" and "gender" would ideally have two files. The first "create" file would have the HTML elements for the three fields. The second "update" file would also be the same as the "create" file but now we pass the pre-saved data so that the user can update. If we add or remove another fields say "age", we have to update the two fields which almost violates the programming rule of three popularised by Martin Flower that suggests similar pieces of code should be refactored into a new procedure.
For this reason, we are proposing a way to make it easier to generate the forms that involves breaking down the form and saving it as a configuration file that is processed to generate the full form. This generation can be done before hand and the file cached or done on the fly.
1. Form definition
At its most elementary, a form can be just a field eg a from with only "first name". As an HTML element the field has a type (text area or drop down), placeholder, help tooltip and from a validation angle it can be required or an integer. So we create a configuration for a single field.
Then, a form can have several rows with each row having maybe 3 or 4 fields. You define several fields and then group them into rows that form the whole.
The definition can be an array or json or XML or whichever format you are comfortable with as long as it's structured and consistent.
array( 'fields' => array( array( 'name' => 'First name', 'type' => 'text', 'prepend' => 'user', 'htmlName' => 'first_name', 'displayed' => 1, 'disabled' => 0, 'placeholder' => 'Type the first name eg \'John\'', 'help' => '<strong>Description: </strong>The first name of this employee. <strong>Do: </strong>Type the first name of this employee. <strong>Star: </strong> %s <strong>Examples: </strong>\'John\'.', 'validator' => array( 'required' => 1 ) ), array( 'name' => 'Last name', 'type' => 'text', 'prepend' => 'user', 'htmlName' => 'last_name', 'displayed' => 1, 'disabled' => 0, 'placeholder' => 'Type the last name eg \'Kamau\'', 'help' => '<strong>Description: </strong>The last name of this employee. <strong>Do: </strong>Type the last name of this employee. <strong>Star: </strong> %s <strong>Examples: </strong>\'Kamau\'.', 'validator' => array( 'required' => 1 ) ),</p><p>
2. Form processor
Once the form definition is done, write a script that load the configuration file, loops through the rows and processes the individual field definition and generate the respective HTML element. For instance, for "first name" and "age" we'll generate a HTML text input and dropdown select respectively. Since the "Create" and "Update" from the "View" perspective are almost the same, we can use the same script, just that for "Update" we bind the model to enable fill in the fields.
3. Form caching:
We have the option to always generate the fly and returning it to the browser immediately. Another option is to cache the form generated in Step 2 above in an actual file that are then rendered as needed.
The benefit of auto generating the form is that it saves us time in generating "Create" and "Update" views. Another advantage is that a change to the form configuration file eg adding or removing a fields will appear automatically in the frontend after running the form processor. For large enterprise applications that have many forms, we can update the form generator enable we to change to look and feel of the forms across the application which would otherwise have been a trip to the moon and back.
In the third part, founded on the same concept of form configuration, I'll explain how we developed listing or table for presenting and showing records from the database.
Your email address will not be published. Required fields are marked *