Re: [PEPr] Comment on Structures::Structures_Form

Justin Patrin wrote:

Comment: Exceptions thrown should be extended from PEAR_Exception (Structures_Form_Exception and possibly sub-classes to classify types of exceptions, although codes are also good for this). This, of course, means you'll have to move the require_once of PEAR/Exception.php to the top of your code. ;-)

OK. I'll work on that.

I'm also a bit disappointed with the separation of Structures_Form and the GTK2 components and I don't really like that the elements "can't" be extended from a base class. This is going to cause a lot of extra duplicated code when it comes to elements. I understand the need for this with GTK2, but it's causing duplicate code in a few ways.

This only causes duplicate code if you want it to. If you wanted to create an HTML frontend package, where the elements can extend from a base class, just create a base class and have it implement the needed interfaces. You code is implemented in one place and the rest of your elements gain that functionality by extending your base class. With PHP-GTK 2, the repeated code is necessary to allow the elements to be cleaner. Repeating a few methods is better than having to create new methods that just call the GtkWidget methods. I know __call could be used for this but I don't think that is a clean solution either.

First of all, the elements should be independant of the rendering structure so that you can add types of elements to the form without deciding on a renderer. This would allow the same form object to render in many formats. In addition, this will pull the common code needed for dealing with elements into these classes, leaving the rendering elements leaner.

The elements are independent of the rendering. The Gtk2 elements could easily be used with an HTML renderer or a CLI renderer. The only problem is trying to use non-Gtk2 elements with a Gtk2 renderer because the renderer needs the elements to extend GtkWidget. Actually passing non-Gtk2 elements to the Gtk2 renderer will not really cause much of a problem aside from the elements not being displayed. Their values will still be submitted when the form is submitted. If you create a form and then want to render it will HTMLRendererA and/or HTMLRendererB and/or CLIRenderer it should work fine. The renderer is ultimately responsible for deciding how the elements are displayed. Of course the elements can help out, but the renderer should be able to get all of the information it needs to display the elements how ever it wants. I am planning to add a method that will translate from one element set to another. This would allow a renderer to force the elements into a set that it likes. With this method, there could be a very simple element set that only manages the data. Then the elements could be translated to some other element set as needed by the renderer or just at the developers discretion.

I'm aware that this is no easy task as it's something I've been working with for FormBuilder2. However, it's not trying to be a form package, it's just trying to generalize the way that it handles forms...

If you have any more insight please let me know. I'd love help with this. My problem is that I am only using the package for PHP-GTK 2 forms at the moment so I may not be seeing all of the little things that will cause issues with other formats.

Proposal information: http://pear.php.net/pepr/pepr-proposal-show.php?id=377

-- Scott Mattocks Author of the soon to be published: Pro PHP-GTK http://www.crisscott.com