Object Oriented Form Creation

[ljm]

I've entered the confusing world of OOP with PHP (version 5, of course), and I've had a look around PEAR libraries and such for creating forms. After using Ruby I've grown a fair dislike for mixing HTML with the server side stuff (it's sooo messy and confusing!)

Creating and validating a form in PHP is simple in theory, but coding it all to fit into your site is an absolute pain. It's repetitive and you waste space on recreating the same thing several times to work under different circumstances (add to a database, edit, etc.). I had a look at PEAR and downloaded HTML_QuickForm, and the code it spat out used tables and wasn't standards compliant. My site is also based around GET variables in the URL, rather than separate files, so I couldn't get it to submit anyway.

Does anyone know of an alternative to this at all? I'm tempted to try and code my own classes, but since I'm new to this it's not going to be easy.

It's funny, I've not done this in a while so it's aggravating me a lot. Everything I come up with is inefficient in some way or another, or is unworkable when it comes to decent validation.

[Shadowfiend]

Well, I'd say, start with inefficient and work your way up. I'm a huge Rubyistiso I know what you're crowing, Have a food at CakePHP; even if you don't use it, it's worth looking at their implementation of the form helpers.

[ljm]

I thought I'd forget inefficient and jump right in. CakePHP's always put me off with it still being a comparitively messy framework when you look at Ruby on Rails (the clean language and lack of configuration is a real deal maker).

So, I read countless tutorials and articles on object orientation in PHP, and thought it wasn't worth it at first: it all went over my head, it was too much to take in. So I'm doing what I did when I started out with PHP - improvised with what I do know.

I've done well so far, I've got the basics working. Well, as basic as taking variables and assigning them to the class variables is. Have to start somewhere, and it's nice coding in pure PHP (until I get to the silly HTML bits).

It's summat to work on, and if all goes well and it works well enough, I'll probably put the script up here with documentation.

[smoseley]

Does anyone know of an alternative to this at all? I'm tempted to try and code my own classes, but since I'm new to this it's not going to be easy.

OOP forms are over kill...

I've done it from scratch and scratched the entire thing... it's too much overhead and complexity for what should be a simple thing...

Besides, I don't like abstracting presentation logic too much...

So with that in mind, I created this simple PHP include that generates most form HTML automatically... also included is a sweet little Javascript auto-validator that allows you to make fields required by simply setting a boolean.

Free to use... enjoy!

(PS - remove the .txt extension on the .js file... WDF apparently doesn't allow JS uploads!)

EDIT:

Here's a sample usage of the include:

<form action="<?=$_SERVER["PHP_SELF"]?>" method="post" onsubmit="return validate(this)">
    <?=generateSelect("Data Type", "data_type_id", DataTypeManager::getAll(), "Select One", $element->getDataTypeId(), null, 410, true)?>
    <?=generateInput("Name", "name", "text", $element->getName(), 30, 410, true)?>
    <?=generateInput("Position", "position", "text", $element->getPosition(), 30, 410, false)?>
    <?=generateInput("Length", "length", "text", $element->getLength(), 30, 410, false)?>
    <?=generateInput(null, "submit_button", "submit", "Submit")?>
</form>

[Shadowfiend]

I'm not sure you're quite getting what's meant by OOP forms, transio. It's very similar to what you're talking about. See this page for an example of a Rails form. That's with the default FormBuilder. It's relatively straightforward to add functionality to this, and here is a sample of a customized builder (from one of my own projects). Note that this is in HAML, rather than straight HTML; however, since it's all Ruby code, it doesn't matter

[smoseley]

I'm not sure you're quite getting what's meant by OOP forms, transio. It's very similar to what you're talking about.

I think I get the idea... my point is that developing a class architecture just for form generation is overkill. It's not the usage that's the problem, but the development time and presentation problems you encounter, which are intertwined.

Here's an OO form architecture I built in Java (see attached image below).

And the code to generate a form would look something like this:

<%
    // Display form
    Form form = new Form("contact", "contact.jsp", Form.ButtonSet.SUBMIT);
    Fieldset fields = new Fieldset("Contact Form");
    fields.add(new TextField("Subject", "subject", subject, "xl vertical", true));
    fields.add(new TextField("Full Name", "name", name, "lg vertical row", false));
    fields.add(new TextField("Email Address", "email", email, "lg vertical row", false));
    fields.add(new TextField("Phone Number", "phone_number", phoneNumber, "lg vertical row", false));
    TextareaField messageField = new TextareaField("Message", "message", message, true);
    messageField.setStyle("xl vertical");
    fields.add(messageField);

    form.add(fields);
    out.print(form.generateHtml());
%>

But it's all intellectual masturbation... you wind up putting presentation logic in business objects - very very bad to do in general, because it enforces the use of specific output logic. I'd rather just have a function that generates my <input> and let me make the rest of my HTML myself.

That's why I keep things simple and just have a few functions that generate single elements rather than entire forms, and never put presentation logic in an OO architecture.

[ljm]

My plan was to have separate functions for input types and labels and stuff, so the class only generated input and label tags, and none of the layout surrounding them. You could say that you may as well code a form by hand instead, but I'm going to try and focus more on the validation side (the most annoying part, I think, especially for single page documents).

That's the main problem with existing OOP solutions - the output is predefined, and you can't change any of it without finding out where the hell the developers put it all in the source. So, my main goal is to create the individual form tags, but leave the presentation to whoever uses it.

[Shadowfiend]

Well, like I said, the Rails way isn't to have a separate object for each field type. These are actually just methods on a FormBuilder class. I fail to see how creating a non-HTML form handling class (or classes) mixes view logic with business logic... Just because something is written in the business language, doesn't make it a business object. In fact, Java encourages you to leave a good bit of your code in Java, and hack it into your page with JSP tag libraries. (I call it `hacking' because I dislike the practice -- I like to insert straight code when I'm going to be inserting code there anyway.)

Anyway, for me, the benefit of doing this is that many things end up simpler. If you look at my second example, that uses the magic_fields library that I wrote which uses the types of the fields in the models to infer what kind of field to put on the page. Explicit helpers still exist if you want to force the type, but the rest of the time that greatly reduces repetition. Plus the presence of errors in a model to create an error in the field is automatically abstracted in the background. Again, less repetition.

What you said about developing a class hierarchy just for form generation is definitely true. That's why the helpers provided by Rails for these purposes tend to provide one class with the methods needed to generate the various types of fields, rather than creating a class for each field.

[smoseley]

My plan was to have separate functions for input types and labels and stuff, so the class only generated input and label tags, and none of the layout surrounding them. You could say that you may as well code a form by hand instead, but I'm going to try and focus more on the validation side (the most annoying part, I think, especially for single page documents).

That's the main problem with existing OOP solutions - the output is predefined, and you can't change any of it without finding out where the hell the developers put it all in the source. So, my main goal is to create the individual form tags, but leave the presentation to whoever uses it.

If all you're gonna do is have static functions, why use a class architecture at all?

Just use the solution II posted above - it does everything you want. Try it out. ;-)

[smoseley]

I fail to see how creating a non-HTML form handling class (or classes) mixes view logic with business logic... Just because something is written in the business language, doesn't make it a business object.

It forces your presentation to behave in a certain way. For example, your form class may output a form like so:

<div class="form">
    <form action="action.php" method="post">
        <fieldset>
            <legend>My Form</legend>
            <div class="input">
                <label for="input1">Input 1</label>
                <input type="text" name="input1" />
            </div>
            <div class="input">
                <label for="input2">Input 2</label>
                <input type="text" name="input2" />
            </div>
            <div class="input">
                <label for="input3">Input 3</label>
                <input type="text" name="input2" />
            </div>
            <div class="input">
                <label for="input3">Input 3</label>
                <input type="text" name="input3" />
            </div>
        </fieldset>
    </form>
</div>

Well that's all fine and good.... nice little package.... but what if I wanna just generate an input element without the whole form container? Or what if I want to create a form with non-form elements inside the container? We do that a lot in the real world, you know. Explanations of stuff, "Forgot Password?" links, etc. In the end, if you want to make an OO solution fully functional, you have to fully model it and give every element an output method (as I did in my Java solution) and then allow the creation of straight HTML as a field type (as I did in my Java solution) and even then, you're still forcing hte form to output in divs every time...