[dev] Horde_Form_Type, VarRenderer, and what to do about it all.

[Chuck Hagenbuch]

I'm going to take the opportunity of a Text_Wiki design discussion on the PEAR
lists to propose we reorganize our whole concept of varrenderers and form
types, etc.

First of all, we should clean up the form types so that they are solely
conceptual - no display assumptions/logic/differences in them. No difference
between radio and select lists, for example.

Then we have the field renderers/etc., one renderer per type of field (where
radio and select lists *are* different) per rendering format supported (XHTML,
PDF, etc).

It'd be a lot of files, which I've tried to avoid in the past, but it seems the
only way to really make this flexible, and to avoid having to parse *too* much
code just to get a select widget, for example. This should be useable with
things like Horde_UI_Table, the Prefs system, the Blocks configuration, etc.,
too, without intrisically requiring Horde_Form.

I'm not sure where the renderers should live in the class tree.

The Text/Wiki class tree idea that got me thinking about this again looks like
so:

        Text/Wiki/Parse.php

        Text/Wiki/Parse/Bold.php
        Text/Wiki/Parse/Code.php
        Text/Wiki/Parse/Wikilink.php

        Text/Wiki/Render.php

        Text/Wiki/Render/DocBook.php
        Text/Wiki/Render/DocBook/Bold.php
        Text/Wiki/Render/DocBook/Code.php
        Text/Wiki/Render/DocBook/Wikilink.php

Thoughts? This may be somewhat similar to
http://wiki.horde.org/display.php?page=FieldTypeProposal, too.

-chuck

--
"Regard my poor demoralized mule!" - Juan Valdez