[/caption]A while back I saw a post in the Flourish discussion boards requesting a Form Generation system, see here. The short discussion that follows basically argues that form generation is too subjective and although it may at some point be added to Flourish it won't be anytime soon. I work in Flourish all day, everyday, and I love every minute of it. I'm probably beating a dead horse at this point, but Flourish really is just a tremendously solid core to build off of. Working with Flourish so much and finding myself performing the same form mark-up again and again, I've given some serious thought to building a Form Generation system and have been using a prototype system for a week or two. Having built a working Form Generation system and used it for a while I want to talk about the good, the bad, and the ugly.
The Good
As a programmer there is nothing more frustrating than finding a library or an API you want to use and having it just be an absolute nightmare to integrate with. I spend a lot of time, ever since Prosper, thinking very hard about how to provide great APIs that make people want to use my software. After a lot of thought about how to go about building a Form Generator library, I've come to what I think is the right balance. The ideal API should fit well with the Flourish way of doing things, be flexible, powerful, expressive, and extensible. So without any further bloviating, here is my proposed syntax, in this example I will use a simple sign-in form.
[php]
echo fForm::post()
->add(fForm::text('Username'))
->add(fForm::password('Password'))
->add(fForm::submit('Sign In'));
[/php]
This would produce the following output
[html]
<form action="http://the/current/url/" method="post">
<label for="username">Username</label>
<input type="text" id="username" name="username" />
<br>
<label for="password">Password</label>
<input type="password" id="password" name="password" />
<br>
<input type="submit" id="sign_in" name="sign_in" value="Sign In" />
</form>
[/html]
The API is fluid, simple, and concise. It follows the Flourish style and uses fGrammar::underscorize() to turn labels into ids. It produces clean simple markup and doesn't mangle any ids, allowing for JavaScript to be easily attached. As far as the API goes, I'm really quite happy. The other powerful thing this allows you to do is tightly integrate your Form Generation with value repopulation, for automatically refilling in values when an error occurs. With this tight integration I've been able to create a prototype system that automatically repopulates across posts when an error occurs, can use an existing fActiveRecord instance as a seed to make editing amazingly easy, and display beautiful inline errors on the form.
The Bad
Having used the prototype for a while I can say it's not all great. Simple CRUD style forms are incredibly easy to mock up, having error values persist automatically is really nice, and having inline error message (especially those from fActiveRecord::validate()) work with little fuss has been a huge speed boost. I can knock out simple pages in a fraction of the time. The problem comes when I want to do some edge case, PHP's greatest strength is easily outputting whatever markup you want, by introducing this layer of indirection you give up this inherent strength for whiz-bang features. It's still incredibly easy to output whatever markup you like, but the disparity between the automatic features the fForm library gives you and your own simple markup is stark and will bewilder a normal user. The problem here isn't that fForm lacks power, it's that it imbues certain elements with too many features and makes creating a one off element prohibitively expensive.
The Ugly
The architecture that worked best for implementing the prototype was a tangled mess of inheritance, and no matter how much I tried to refactor I still haven't found an inheritance graph that I find acceptable. Using my prototype has considerably cut down on development time, but the amount of memory used holding a object graph in memory to represent complex forms is a trade-off. The API has several inconsistencies that bother me, but don't really impact the performance or usability of the library.
The Future
So where to go from here? That's the question I keep coming back to. I want to introduce a layer between object graph and view, this way a plugin system can be used to change the rendering of elements and the form itself in a fundamental way. As soon as possible I plan on releasing a clean room open source version of the fForm library for use with Flourish on GitHub. I believe I've come up with a way to make an easily extensible widget system, now I just need to get something out the door. I will release it with my alpha framework, Rigby, in the coming weeks. Comments, and of course forks, are welcome. I will release some screencasts about how to use Rigby once I get it into a stable state. Stay Tuned!
