<?php
/**
 * notes for the developers, kind of a todo list with suggestions, etc.
 *
 * $Id: notes.txt 116 2004-08-26 13:05:33Z argh $
 *
 * @access	public
 * @package	patForms
 * @author	Sebastian Mordziol <argh@php-tools.net>
 * @author	Stephan Schmidt <schst@php-tools.net>
 */
?>

BUGS:
=========================


Planned features (schst):
=========================

* Event based form-processing:
------------------------------
Event handling can be used to automate form handling and
could be used best with the autovalidate option.
It allows you to register callback methods or objects.

This feature already is implemented but in alpha state.

$form->registerEventHandler( 'onError', 'handleFormErrors' ); [OK]
$form->registerEventHandler( 'onSuccess', array( $handlerObject, 'handleSuccess' ) ); [OK]
$form->setEventHandlerObject( $handlerObject ); // supplies methods for all events [OK]

boolean setEventHandlerObject( object &handlerObj [, array methodNames] )
boolean registerEventHandler( string event, mixed handler )

Events that are triggered:
- onSubmit( &$form ) [OK]
- onError( &$form ) [OK]
- onValidated( &$form ) before finalize() [Needs attention]
- onSuccess( &$form ) after finalize() [Needs attention]
- onInit( &$form ) [Needs attention]
- onRender( &$form ) [Needs attention]

Event handling has to be implemented for:
 - Element
 - Rule

* Storage containers:
---------------------
Storage Containers will allow automatic-storage of validated
data in a database, CSV-File, XML-File or any other place (like the moon).
Planned containers:
 - DB (using PEAR::DB)
 - XML
 - CSV

* Creators:
-----------
Creators build a form from any datasource or config file. Possible containers are:
- DB (using DB::tableInfo)
- MySQL (using SHOW COLUMNS)
- DB_DataObject
 
* Client side integration:
--------------------------
Basic functionality should be available on the client side:

Class for each element type, derived from a base class

patForms:
- patForms::validate()
- patForms::getElementByName() (does not return a HTML object but an
  instance of a javascript form element)

patForms_Element:
- patForms_Element::getValue()
- patForms_Element::validate()
- patForms_Element::addRule()

patForms_Rule:
- patForms_Rule::applyRule()

patForms_Filter:
- patForms_Filter::in()

Class defintions should reside in seperate files and included
via javascript include if possible. If not possible (not in document-root,
or script-language does not support the feature), the can be included by
using file_get_contents().

Problem:
--------
In the current implementation, script is only dependent of the format,
not the mode.
Can this be ignored?
 
* Filters:
----------
see docs/filters.txt for documentation

- Filters should also be applied to patForms object
  (push each value through the filter)

- Possible add-on:
  Allow filter to be a callback (or a set of callbacks):

  patForms_Element::applyFilter( mixed outCallback [, mixed inCallback]  )
  
  Problem: Type has to be specified as third parameter

ARGH:
=================================
- add access private/public flag for attributes to make them settable 
  only by private/public.
- setting number-based attributes like maxlength/minlength as 
  integers causes them not to be inserted via the insertSpecials 
  modifier (e.g. [ELEMENT_MAXLENGTH]).