30 October 2006
Fortitude Forms II: The Form Comes Around
I got an interesting bit of code started in Fortitude this weekend. To understand it, let’s start first with the usual dev-cycle of a Fortitude app:
- Create a Model class
- Create a Form class
- Create a form handling action
- Create a View/FormView file
What’s annoying while doing this is that so many fields are seemingly replicated on each step. I say seemingly because they all seem to be the same, but there is a subtle difference between a Name field in the model, a Name textbox on a Form, the Name synchronization code in the action and the Name rendering code in the View. They’re all the same data, but have to be different enough for each to do its job.
The eventual goal to ending this redundancy is a Form designer front end like Microsoft’s Visual Studio. But that’s a big job all by itself. It’s an eventual goal. But small projects like this lose all momentum and die in the time it takes to develop something like Visual Studio. So there are smaller milestones first.
In the past, I’ve postulated about using HTML as a template. This means that instead of learning yet another framework/language/syntax, Fortitude’s framework would take care of making an HTML file intelligible. This turned out to be easy to do. The base Form class in Fortitude now takes a normal HTML file, and maps each form element to the Form object. To put it more simply, before, you had
Login.Form.php
class LoginForm {
var $tbxName;
var $tbxPassword;
// …
}
Login.FormView.php
<form ...>
<fort:form />
Username: <fort:tbxName />
Password: <fort:tbxPassword />
</form>
Now, the FormView file could look more like:
Login.FormView.php
<form ...>
<input name=”form” type=”hidden” />
Username: <input name=”tbxName” type=”text” />
Password: <input name=”tbxPassword” type=”password” />
</form>
The immediate advantage is that DreamWeaver users can see exactly how the form will look. A less obvious benefit is that behind the scenes, there is a managed file with all the recognized tags stripped out and replaced with <?php echo …; ?> lines so there is actually less parsing going on then under the old system. That managed file is updated every time there is a change in the FormView file. But there is potential for a third benefit, too.
Since the output file now has information on what kind of field each Form Field is intended to be, there is enough information to generate the Form object. This would obviously not be part of the Framework, but part of the development platform. Imagine a designer whips out a Form in DreamWeaver. He/She then runs it through the Fortitude Forms generator, which makes entities for every field on the Form. Assuming there is a template form handler Action, the designer has now generated a working, persistant form.
We’re not at that point yet. But this should give you some idea of the direction things are heading in.