So far, we've seen the pieces of the form in separated classes. Having available the base "formObject" class, as well as the different derived sub classes, it's time to instantiate some form objects and build a basic HTML form. Our first approximation would be implemented sticking to the following approach:
// include required class file
// instantiate derived inputText objects from super class formObject
That's our rough approximation for coding our form generator, and I must say that is really bad! Even worse, it's dramatic. But, why are we complaining so loudly about the code? After all, we've been using the base class and subclasses, applying Inheritance, and finally instantiating a few form objects, in order to build a regular HTML form. What could be so wrong? Just take a look at the section where we generate the form using an object array structure, and use a "switch" statement to determine which form object we're dealing with.
Utilizing the "get_class()" PHP built-in function, we're finding out what type of form element is contained in the array, and subsequently displaying the corresponding code for the element. Please forgive me about my vehemence, but switch statements are really poor and inefficient. Not only are we being redundant about HTML generation, but we're also accessing objects properties directly! What about encapsulation? Object properties must always be accessed by the set of objects' proper methods.
Also, the code is hiding a bigger problem. If we want to add another form element to the form generator, the updating process is really a nightmare. Definitely, this approach demonstrates how things must not be done.
So, what's our next step to fixing the above dirty implementation? The answer is Polymorphism. Yes, even in an extremely weakly typed language such as PHP, we can take advantage of it for finding a new approach to build the form generator. Do you remember that each subclass defined presents a "generateHTML()" method? So, why don't we get a bit smarter, using it to present a more decent solution? That's what we're going to put in practice in the last part of this series, demonstrating the big advantage of using polymorphic objects, and explaining its core concept definition.
In this second part of the series, we've finished defining the whole source code for each subclass corresponding to a form element. Also, hopefully we've demonstrated how poorly we could be implementing our form generator without using the advantages of Polymorphism as the previous step to fixing these major mistakes, employing its capabilities in PHP with a practical approach.
In the next part, we'll be putting Polymorphism to work for us, presenting a new version of our form generator. In the meantime, play with the code and add your own improvements to the project. After all, that's what collaborative work is about. See you in the third part!