HTML Form Classes
Robert Impey
This allows classes that represent tags to be created, manipulated and
then rendered as HTML.t
One coding approach that has been used extensively for making HTML
forms in much of the Haddock CMS Admin back end and for writing the
front-end part of several projects has been to extend the
HTMLTags_Form class. Then instances of these classes can be created in
code using the constructor.
I would like to suggest an alternative approach. Instead of focussing
on writing new sub-classes of the form class, programmers should start
of by writing static functions in helper classes that return form
objects that are composed within the function. Common features might
be refactored into a new subclass of HTMLTags_Form later.
This has the advantage that it is less restrictive than the coding
complex constructors.
Saul Howard
specific kind of form, it was convenient to extend HTMLTags_Form. Were
you talking about this kind of behaviour?
eg:
http://code.google.com/p/oedipus-decision-maker/source/browse/sites/main/trunk/classes/html-tags/Oedipus_OedipusOptionEditorHTMLForm.inc.php
Robert Impey
>
> True, although in Oedipus when I was making many instances of a very
> specific kind of form, it was convenient to extend HTMLTags_Form. Were
> you talking about this kind of behaviour?
>
The point that I wanted to make was more to do with the order in which
things get coded rather than what things end up like.
e.g.
You have a form on a page, you might start like:
FooBar_KishKashesHelper::render_edit_form($kish_kash_id);
To start with that function might just be some DB access code and an
HTML template that uses the values from the DB to do with
$kish_kash_id. Traditional PHP code.
That might be the end of the story. But lets say that you need a kish
kash editing form as an object somewhere else.
You translate your HTML template into HTML tag generating code inside
a function called:
FooBar_KishKashesHelper::get_edit_form($kish_kash_id);
FooBar_KishKashesHelper::render_edit_form($kish_kash_id) might now look like:
class
FooBar_KishKashesHelper
{
public static function
render_edit_form($kish_kash_id)
{
$form = self::get_edit_form($kish_kash_id);
echo $form->get_as_string();
}
public static function
get_edit_form($kish_kash_id)
{
$form = new HTMLTags_Form();
/* Code for putting the form together goes here */
return $form;
}
}
After this, it may very well make sense to make your own custom class
and reduce the amount of code in the get_edit_form function. Maybe you
want a FooBar_KishKashEditingHTMLForm class and a
FooBar_KishKashAddingHTMLForm class that both extend an abstract class
called FooBar_KishKashHTMLForm. Inheritance might be the way to go
with that. That's might work. Similar things can be done with more
functions in the helper class. More a question of taste than anything.
Nothing is unconditional.
But point is that it's probably better to get the render_*_form and
get_*_form functions in place before you do that.
It's probably also more sensible to restrict yourself to calling those
functions in code that puts a page together, rather than using the
constructor itself.
The reason for this is that if you call the constructor, you're tied
to a particular class. With a function like this, the class can be
changed in a single place safely.
> eg:
>
> http://code.google.com/p/oedipus-decision-maker/source/browse/sites/main/trunk/classes/html-tags/Oedipus_OedipusOptionEditorHTMLForm.inc.php
>
>
>
> On Aug 7, 4:11 am, Robert Impey <robert.im...@gmail.com> wrote:
>> One of the major features of the Haddock CMS is the HTML tags module.
>> This allows classes that represent tags to be created, manipulated and
>> then rendered as HTML.t
>>
>> One coding approach that has been used extensively for making HTML
>> forms in much of the Haddock CMS Admin back end and for writing the
>> front-end part of several projects has been to extend the
>> HTMLTags_Form class. Then instances of these classes can be created in
>> code using the constructor.
>>
>> I would like to suggest an alternative approach. Instead of focussing
>> on writing new sub-classes of the form class, programmers should start
>> of by writing static functions in helper classes that return form
>> objects that are composed within the function. Common features might
>> be refactored into a new subclass of HTMLTags_Form later.
>>
>> This has the advantage that it is less restrictive than the coding
>> complex constructors.
> >
>
--
Rob Impey