Simplifying Automated Form Generation, Validation, and Output

First Praise, Then Critique

HTML_QuickForm is the standard class within PEAR for building forms programmatically. Here’s an example:


$form =& new HTML_QuickForm();
$type = 'text';
$name = 'city';
$label = 'Your City:';
$form->addElement($type, $name, $label);

(All XHTML element types are supported, including some pseudo-types such as ‘date’ and ‘time’).

When you call $form->display(), the class builds all the HTML for the form and the elements you have added. That’s just the start, though. If you have a POST variable called ‘city’, it will populate the form with that value for you. You can add validation methods to each element, and the class will check the values and print error messages inside the form if the values are not valid. You can apply special processing to the values before retrieving them as an array with $form->export().

It’s quite a neat package, but I have some quibbles with its operation. These are not design flaws; indeed, its design seems quite internally consistent. For example, each element is represented internally as an object itself, with its own methods and properties (usually descended from a base element class). For example, to set the value of an individual element, you have to call its setValue() method — but any submitted values (e.g., in POST) will override that value. There are ways around this, but none of them seem simple or straightforward.

More to the point, while I am not a strict model-view-controller devotee, I find that HTML_QuickForm not only pierces the veil between model and view (or controller and view, depending on your definition), it positively shreds that veil to pieces. Yes, it has renderers that allow you to parse through the internal objectified representatiion of the form elements, but they system seems overly complex.

While I like HTML_QuickForm, and have written code (in DB_Table) that automatically generates forms from tables using it, I don’t fully comprehend the methodologies underlying its operation. It seems to me there should be a simpler and more straightforward way of automating form generation, one that is both more comprehensible and more open to MVC separate while retaining the obvious strengths of validation and automated population of values.

Continue reading

DB_Table and Text_Wiki Release Candidates

For more information, please visit the related PEAR pages:

DB_Table

Text_Wiki

If I don’t get any new (critical) bug reports for the next week or so, I can release them as “stable” and check them off my to-do list. While Text_Wiki could still use some add-ons (more renderers, more parsing rulesets) the core is complete. These two projects are each 18-24 months old at this point, so it’s nice to be able to say “done!” to them.

Now all I have to do is finish the respective documentation. With any luck, the addition of YaWiki to the PEAR website will aid in that (then I can keep everything related to those two projects in one place; i.e., at PEAR).

Solar: Version 0.0.3 dev released

You can download, view the API docs, and join the mailing list from the official site (solarphp.com).

The change notes are:

* Converted all __hive() calls to __solar() instead.

* Added email and initial description to Solar_Cell_Bugs columns, removed reference to Solar_Cell_Talk (should be handled by the application object, not the bugs entity)

* Converted all ‘dt’ (date-time) abbreviations to ‘ts’ (timestamp) for consistency with Solar_Sql_Entity column type naming

* Multiple changes to Solar_Sql_Entity array keys (‘ent’ ==> ‘tbl’, ‘seqname’ ==> ‘sequence’, ‘valid’ ==> ‘validate’, ‘message’ ==> ‘feedback’

* Added Solar_Form class (aggregates element-building instructions and validation)

* Added "None.php" drivers for Solar_User_Auth and Solar_User_Role (to facilitate having no backend for those services)

—-

There were some internal changes to the Solar_Cell classes for Bugs and Talk (the bug and comment table entities, respectively). The biggest addition is the Solar_Form class, which is kind of like HTML_QuickForm, except it’s not. πŸ˜‰

I really do have to start on at least some outline documentation; YaWiki will be perfect for it when I find the time between my MBA projects and my day job.

Write For Persons, Not Groups

Ryan King links to this great essay.

Anyway, I babbled at Nat along these lines for a while, predicting that, while I was sure that anyone he talked to in a corporation would tell him, “free groupware, yes, awesome!”, there was really no reason to even bother releasing something like that as open source, because there was going to be absolutely no buy-in from the “itch-scratching” crowd. With a product like that, there was going to be no teenager in his basement hacking on it just because it was cool, or because it doing so made his life easier. Maybe IBM would throw some bucks at a developer or two to help out with it, because it might be cheaper to pay someone to write software than to just buy it off the shelf. But with a groupware product, nobody would ever work on it unless they were getting paid to, because it’s just fundamentally not interesting to individuals.

And there you have it in a nutshell. No **organization** ever wrote or used a program. **Individuals** write and use programs. If you want people to love your software, it has to appeal to individuals.

As a corollary, if your program sucks for individuals, it will suck for the organization. This goes along with the complex adaptive systems and emergent behavior issues I rant about from time to time.

Good idea for a project at the end of the article, too: server-less calendar sharing. Cool.

Solar 0.0.2 released

It used to be called Hive; now it’s Solar, the “Simple Object Library and Application Repository” for PHP5. This is only a development release. You can pick up the PEAR tarball here:

http://solarphp.com/Solar-0.0.2.tgz

No real documentation yet, but you can read the auto-generated API reference here:

http://solarphp.com/api/

Next set of tasks is to get the Solar_Cell_Bugs component working properly, and I can write up a quick app to do bug tracking. Also need a mailing list, and need to set up YaWiki installation for real documentation (although Solar will have a wiki component of its own, and at that point it can be self-hosted / autonomous / internally-dependent / eat its own dog food / whatever).

Revision control is going through Subversion now instead of CVS, provided by the kind folks at TextDrive, who are the web hosts for solarphp.com as well. For $12/month, it’s a sweet deal; my thanks to Ryan King for pointing them out.

Shared Hosts with Subversion?

I want to use Subversion for the Solar project, not CVS, but I can’t find a shared host that has it. I use pair.com for absolutely everything, but they won’t let me run svnserve on a shared host (which is reasonable) and the Apache2 track is not an option for me.

Anybody know of a reliable web host that has Subversion installed for remote use?

(UPDATE 2005-02-17) I ended up going with TextDrive.

The Hive is dead. Long live Solar!

Inspiration struck this morning. I wanted to get across the idea that this library is essentially a collection of simple, straightforward objects that are all related to each other and share common development principles; in addition, it would come with common application pieces pre-built. An ant hive seemed a good metaphor to use in that case. But as we have learned, the name Hive is already taken, so that’s out.

However, I think I have a good replacement name: the Simple Object Library and Application Repository for PHP, or Solar. It is short, highly descriptive, lends itself to a logo and a catchphrase, and is sufficiently specific that you know what it is without being so generic that it has no meaning by itself. And nobody else is using it. πŸ™‚

So the domains are registered, all that remains is to rename the class structures and re-commit to CVS.

UPDATE (2005-02-21): You can visit http://solarphp.com/ for more information; and, of course, check back on this blog periodically.

More Than One Hive

Robert Janeczek notes that his project, also called Hive, won an award in the Zend PHP5 coding contest last year. It’s obvious he has first dibs on the name; it’s also obvious that I didn’t search hard enough for other PHP5 projects using that name.

So what to do now, seeing as I already went and bought the domain name “phphive.com”? πŸ™

Introducing: the Hive

The world may not feel the need for yet another class library, but after two years with PEAR, I sure do. My attempt to unify PEAR packages with a wrapper package (which I attempted with Yawp) is essentially a dead-end. While I like the mode of operation I have developed with Yawp and DB_Table and Savant, I do not think the PEAR project is open to incorporating such a mode.

With that in mind, I am introducing a new class library for PHP5: the Hive. You can download a PEAR package of it. While this is a 0.0.1 development release, I think you will find the work well fleshed out, with a current PhpDocumentor-generated API reference. End-user documentation will be forthcoming in the next few weeks.

A Bit About My Pear Background

What is it that developers love about PEAR? Look no further than this page, which was the result of a call-for-replies on the PEAR-DEV mailing list last year. Let me add to that list my own reasons why I started using PEAR classes.

In the beginning, there was only one thing that mattered to me: unified error handling. That was it, really. If a foreign object reported an error, I knew exactly how to check for it and what format it would be in; if I needed to report an error, I knew exactly how to format it. Thus, for all its flaws, PEAR_Error was the main reason I started using PEAR classes. Add to that the PEAR DB abstraction package, which was a great labor-saver. Finally, and I have come to love this more than anything else, the PEAR installer has turned into a work of genius under the stewardship of Greg Beaver.

But I have come to believe that PEAR is too much a mishmash; even with coding style standards, the class packages operate according to widely varying styles. In addition, it is far too difficult to add a new package that I find useful but is similar in purpose to an existing package (even if the principles of their operation are widely different). For example, see the acceptance of DB_Table in the face of serious opposition and only after patient months of lobbying, as well the rejection of Savant after a knock-down drag-out (to which rejection I contributed my own fair share).

In short, I find it much too hard to do anything new or different within PEAR that is not already part of PEAR doctrine; while this brings stability, it also brings a certain morbidity. (This is not to say I’m leaving PEAR; I’m not. I am just going to concentrate my new development efforts outside PEAR, not inside it.)

Foundational Principles Of The Hive

There is one essential principle behind the Hive: comprehensibility. Developers exploring the Hive should be able to comprehend the code quickly and easily, so they can see exactly what’s going on and why. In short, I am tired of slogging through uncommented, undocumented, complex, obtuse code and packages, whether mine or someone else’s.

The principle of comprehensibility gives rise to two corollaries:

  • Simplicity of code
  • Obsessive dedication to comments and documentation

These in turn mean that it should be easy to extend and customize code in the Hive, but that has yet to be borne out.

Some Technical Notes

The Hive adheres to PEAR coding style standards and its directory structure is similar to PEAR’s.

Hive can exist with any other library set, including standalone libraries, PEAR, Horde, and so on; using the Hive does not mean you are limited to the Hive.

Hive comes with a shared-object aggregator and convenience method central class and some basic functional classes:

  • Hive_Cache for caching; both file and memcached are currently supported
  • Hive_Error for unified error handling
  • Hive_Sql for identical-operation database abstraction (will migrate to a PDO backend as PDO comes on-line)
  • Hive_Sql_Entity for representing data-type abstracted tables with automated validation and form-hints generation
  • Hive_User for user authentication and roles/groups (preferences and permissions will arrive later)
  • Hive_Valid for data validation

One major goal of the Hive is to provide shared application component backends that are not tied to any particular display mechanism. This is accomplished through Hive_Sql_Entity (the successor to DB_Table) and the Hive.conf.php configuration mechanism, along with the shared object instantiator Hive::shared (which is a successor to the Yawp::getObject technique). The initial set of application component objects will include a comment/trackback tool, a wiki page storage interface, and a blog entry storage interface.

Cliffhanger

(Not a conclusion. πŸ˜‰ I’ll be writing more about the Hive in weeks to come; with any luck, this will be in the form of documentation, as well as blogging about feedback, issues, ideas, and to-do items.

As always, I’m happy to hear feedback and see trackbacks.

Update (2005-03-08)

Somebody else is using the name “Hive” for a PHP5 project. I have adopted a new name for the project: Solar. You can search this blog for other Solar entries to learn more, or visit the Solar home page.