[cvs] [Wiki] changed: FieldTypeProposal
Wiki Guest
wiki at wiki.horde.org
Wed May 26 14:07:48 PDT 2004
guest [65.112.23.131] Wed, 26 May 2004 14:07:48 -0700
Modified page: http://wiki.horde.org/display.php?page=FieldTypeProposal
New Revision: 1.5
@@ -554,4 +554,48 @@
//}}}
</php>
+
++++ Email from 5/26/04:
+
+<code>
+Date: Wed, 26 May 2004 14:59:25 -0400 [02:59:25 PM EDT]
+From: Chuck Hagenbuch
+Subject: [dev] Horde_Form_Type, VarRenderer, and what to do about it all.
+
+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
+</code>
More information about the cvs
mailing list