QuickForm2

api

Thu, 01 Oct 2009 11:51:10 +0200

* HTML_QuickForm2_Node * HTML_QuickForm2_Element * HTML_QuickForm2_Container * HTML_QuickForm2_Container_Group * HTML_QuickForm2 * HTML_QuickForm2_Factory * HTML_QuickForm2_Datasource * HTML_QuickForm2_Datasource_Submit * HTML_QuickForm2_Renderer * HTML_QuickForm2_Rule * Exceptions

backwards_compatibilty

Sat, 07 Oct 2006 15:48:15 +0200

Backwards Compatibility HTML_QuickForm2 will be backwards compatible to HTML_QuickForm in the sense that everything possible to do with the latter will also be possible with the former, while the API for this may be radically different. Migration from HTML_QuickForm TODO sometime.

behaviors

Tue, 03 Jun 2008 19:42:47 +0200

An element can have different behaviors depending on its attributes. The first example that comes to mind is the Select element. The Select element can be either simple or multiple, ie. it can take one single value or multiple value. Depending on this, its aspect changes as well (this is handled by the browser) as well as the way its values are set.

builders

Tue, 03 Jun 2008 19:42:47 +0200

I don't see these Builders as the base functionality: if they are adding stuff to the form, they'll have to use some API for that. Most probably they'll use the same appendChild() method of HTML_QuickForm2_Container. --- Alexey Borzov That's right. The default builder will use the Container API. The question is then do we need a default builder. If we don't provide a default builder, people might not understand what a builder is. I can think of many different builders that can be useful depen…

competitors

Thu, 15 Nov 2007 13:26:52 +0200

Zend_Form proposal The proposal: There's a useful discussion going on here, more useful than the proposal itself. Among some rather less useful comments (like form validation rules belonging to the View of MVC; judging the quality of the form library on the basis of how far its API is from QuickForm) there are some very good ideas.

controller

Fri, 09 Jul 2010 15:59:29 +0200

Page should aggregate Form Common complaint is that in QuickForm 3.x / QuickForm_Controller 1.x HTML_QuickForm_Page extended HTML_QuickForm and therefore it was impossible to use customized subclass of HTML_QuickForm with Controller. For example, in HTML_QuickForm_DHTMLRulesTableless package two classes had to be implemented: HTML_QuickForm_DHTMLRulesTableless extending HTML_QuickForm and HTML_QuickForm_PageDHTMLRulesTableless extending HTML_QuickForm_Page.

feature_requests

Sun, 09 Dec 2007 19:21:06 +0200

Feature requests in PEAR bug tracker All the open feature requests that accumulated over the years for HTML_QuickForm package were moved to HTML_QuickForm2 package. Read the requests Justin Patrin for FormBuilder * Tree structure for group grouping, moving elements, and more customization * Separation of QuickForm code and HTML code to support multiple backends (note that this means finding a way to deal with multiple “submit” types) * HTML * XHTML * XUL * WML * XFORMS *…

filters

Fri, 16 Apr 2010 12:44:03 +0200

Form filters act on form values, no matter if they are submitted values or default values. The most common use of a form filter is for example the trim() function. You hate it when form users fill your fields with a space just to pass the required field validation. You also hate it when they use only uppercases. This means that filters can be applied before validation takes place and definitely transform the value of the element before it reaches the getValue() step.

home

Fri, 16 Apr 2010 12:06:10 +0200

Gathering of ideas * Feature requests * Backwards compatibility, migration from HTML_QuickForm * Ideas * Using Iterators * Using the DOM API * Borrowing the competitors' ideas * JavaScript integration Implementation * Prerequisites --- specifically, HTML_Common2 * API for HTML_QuickForm2 * Implementation Issues * Porting of HTML_QuickForm_Controller * Milestone releases

http_request2

Sat, 02 Jun 2007 21:40:15 +0200

Existing version: HTTP_Request Problem: due to E_STRICT RFC new packages requiring ability to perform HTTP requests cannot be accepted until a E_STRICT version of HTTP_Request is out. This affected for example the proposed Services_Digg package.

ideas

Sun, 09 May 2010 18:38:26 +0200

Ideas on separate pages, to reduce clutter: * Modularization * Validation * Streamlining the API for element values Some Patterns ;BINDINGS: Description forthcoming ;DELEGATION: Description forthcoming The delegation pattern is described on Wikipedia. I have seen it being used a lot in the Cocoa framework, often to handle refresh of GUI elements, like tables for example. It is lighter than using a notification system but objects are more tightly coupled together.

issues

Sun, 09 Dec 2007 23:10:18 +0200

Possible implementations of getElementById() and getElementsByName() There are two possible implementations for these methods: "Iterator" implementations This effectively means that we just iterate over all children of the element and check whether child's id (or name) attribute is equal to the given one

javascript

Fri, 14 May 2010 18:23:12 +0200

What is needed for JS support in QuickForm2: * Some global library; * Per-element-type JS; * Per-element JS; * Autogenerated validation rules; * Possibility to plug additional stuff into validation routine; * Elements should also degrade ok when javascript is turned off.

milestones

Fri, 16 Apr 2010 12:14:19 +0200

Milestone 1 (released 2007-04-17) Checklist: * [x] Base classes * [x] Simple Element classes. * [x] Datasources * [x] All elements should properly get their values from DataSources * [x] HTML_QuickForm2 class itself * [x] Bertrand promised to do Fieldset element * [x] Usage example:

prerequisites

Sun, 15 Oct 2006 17:27:41 +0200

Since QF2 will be a PHP5-only package, it needs a PHP5-only version of HTML_Common package to depend upon. HTML_Common is mostly feature-complete, so the changes to its functionality when moving from PHP4 to PHP5 version should be minimal. PHP5-only features, migration from HTML_Common HTML_Common2 has a static $_options property containing options global for the whole HTML document, like those that were previously set via setTab() and setLineEnd() and (especially) the one requested by

using_iterators

Sun, 10 Sep 2006 12:49:17 +0200

I spent some time looking at SPL and iterators, especially the RecursiveIterator part and I am puzzled on how to implement this for QF2_Group. It could be nice to extend ArrayObject which add array features to collection objects like Group, but Group will already extend HTML_Common2 and since there is no multiple inheritance or mixins in PHP, I don't know what to do.

using_the_dom_api

Tue, 04 Jul 2006 23:57:00 +0200

On this page there are examples implementation of a DOM like API using references in component objects (nextSibling, prevSibling, etc.). The other way is to use an array of elements. What would be the best solution for QF2 ? In the past, we used an array of elements. It makes it easy to iterate over the elements. It is also easy to manage since it works like an array.