[cvs] [Wiki] changed: NewFieldType

Mon Aug 22 00:15:22 PDT 2005

jan  Mon, 22 Aug 2005 00:15:22 -0700

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

@@ -1 +1,84 @@
++ Horde_Field:: Proposal
+
+This page is a proposal for the implementation of new package to replace Horde_Form_Type:: and Horde_Form_Variable::.
+
+I'm refactoring this page into topics.  I had a major wiki breakthrough when doing this for work (as I receive e-mail, enter meeting notes, etc., I now factor into topics which could be different pages or different headings on a page).  A really good overview emerges fairly quickly and it works extremely well with something like a project's needs analysis.  So let's call it a pattern. -- JasonFelice
+
+++ Proposed Requirements
+
++++ Useable Without Horde_Form::
+
+There are currently still some interdependencies with Horde_UI_VarRenderer:: and Horde_Form:: which really suck.  When working on Horde_UI_Table::, I need to render fields in display mode and I have no form. -- JasonFelice
+
++++ No Display Assumptions
+
+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:
+
+<code>
+        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>
+
+-- ChuckHagenbuch (from e-mail on May 26, 2004)
+
++++ Multiple Output Formats
+
+In our old framework, we can render a field to plain text, HTML, or !TeX (since that is how we produce PDFs).
+
+Here's one question, how do we handle edit formats?  We could theoretically have a PDF edit format or a Flash edit format, or more likely some sort of embedded device markup.  If we have an output matrix of ( medium * type ), we could be talking about a lot of classes.
+
+I propose that we just have one class per output medium, and display or edit is determined by which method is called.
+
+-- JasonFelice
+
++++ "Filter" Fields
+
+I don't know how to handle this just yet, but in our old framework, we have a Get_Filter_HTML() method.  For a date, it returns HTML with a start date field and an end date field (it is a possibly open-ended date range, in other words).  The field also has a Get_Filter_SQL() which takes a field name and returns a fragment of an SQL WHERE clause to "filter" by that expression.
+
+In Horde, we can't assume the back end is SQL.  In the old framework, a lot of the Get_Filter_HTML() methods have been factored into separate field types (like a date range field, in this case), so perhaps just a method to retrieve an instance of the filter field type for this field type.  The driver model makes it difficult to automagically turn this into a query limiter, though, so it might just not be feasable for Horde.
+
+-- JasonFelice
+
++++ Field Representation Is Configurable
+
+In order to take into account different sorts of representations for the same data type, the fields can accept field-dependant config parameters (the typical $params key/value array).  The field can use these to determine things like:
+
+* How wide a text field appears.
+* Whether to use radio buttons or a drop-down for an enum.
+* etc.
+
+-- JasonFelice
+
++++ Scatter/Gather
+
+I think the field class that returns the HTML edit representation needs to have a method for "gathering" the form fields back into the internal representation.  An example could be Horde's monthdayyear field, which has three form fields for representing a date value.  The gather() method would take this data and return the internal value. -- JasonFelice
+
++++ Careful Attention to Internal Value Representations
+
+We've had this problem with our old framework, and I see it to some degree in Horde.  What does a date look like?  If we could pick one form, we constrain the number of interfaces we deal with and therefore the complexity.  In our old framework, we have internal (PHP) values, database (!PostgreSQL textual representation) values and HTML form values.  We assumed when first designing when we were basically just using text inputs that all of these were the same, but that got us into big touble.
+
+In Horde, we can make sure the storage driver returns the internal form, so we seal off the database representation into the database-specific driver, which is really nice.  We currently do have a problem with the other types of values, though.  We should probably always use PEAR Date:: representations because we certainly don't want different fields for UNIX timestamp and more useful date formats.
+
+-- JasonFelice
 
