[cvs] [Wiki] changed: NewFieldType

[Wiki Guest]

guest [65.19.150.231]  Sun, 21 Aug 2005 20:07:05 -0700

Modified page: http://wiki.horde.org/NewFieldType
New Revision:  12.0
Change log:  Revert

@@ -554,48 +554,4 @@
 
 //}}}
 
 </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>