[TYPO3-ect] tx_forms

[Steve Ryan]

Hi All,

Few observations/suggestions about how I would like to see a forms lib.
* the TCA sits at the center of a typo3 forms library. It is the 
'official' way of describing meta data for form component types and 
validation after all.

* I'm all for a fully automatic layer to the API.
renderForm($fieldList,$TCA,$data);
renderView($fieldList,$TCA,$data);
renderList($fieldList,$TCA,$data)
using
renderFormMarkers($fieldList,$TCA,$data)
using a more granular layer
renderFormField($field,$TCA,$data);
renderFormValue($field,$TCA,$data);
using an even more granular layer
renderRTEValue
renderLinkValue
renderRTEFormField
renderRTELinkField

* Sufficient granularity in the meta data based form generation API 
would allow any rendering technique from totally custom php that just 
uses the lowest levels like getRTEValue through php style templates that 
just use the marker array functions eg 
getFormMarkers($fieldList,$TCA,$data) to get the prepared and populated 
form widgets. HTML customised templates are are a popular choice that 
use markers for the  generated input fields/values so the highest level 
functions need to generate default templates with markers or accept a 
filesystem template as an alternative eg 
getForm($fieldList,$TCA,$data,$template);

* It is not necessarily a good idea to seperate lists and views form 
forms, they all really mash together. At least at the level of 
generating field widgets.

* The TCA needs to grow to support additional field types including 
advanced relationships, javascript widgets like spreadsheets and graphs, 
more advanced validation, possibly collective field lists, search 
configuration......

* A really simple extension that provides a flexform to choose a table, 
field lists and behaviour stereotype (search/list/view, admin editing, 
autosearch, create/confirm (registration) ....) would bring the forms 
lib to the wider typo3 community of non programmers.

* Access control raises some difficult questions because all the fine 
grained access control settings are related to back end users but I 
imagine that a forms lib would be most popular for creating front end 
editing solutions.

* Creating 'entity bean style' class files to define a persistent object 
and provide getter/setter methods seems like overkill to me. Arrays 
combined with meta data do the same job (if not so comprehensible) and 
are so much easier to reflect/treat in the abstract.

* Input processing/validation and persistance functions can also be 
implemented in the abstract based on meta data.
processDataValue($field,$TCA,$data);
processDataValues($fieldList,$TCA,$data);
validate($fieldList,$TCA,$data);
validateField($field,$TCA,$data);
validateEmail($data)
I'm not sure if these functions should be split into seperate libraries 
as they are quite interdependant around the internal structure of the 
data array.

* Somehow I feel like I am at odds with good 'object orientated' design 
as this approach does not use any of the cascading aspects of objects 
which facilitate reusability and extensibility. Particularly when it 
comes to adding additional field types, the entire validateField method 
would need to be overridden. Perhaps this could be overcome with a 
configuration array mapping TCA.config.type to a function ??????


* Control structures take many different forms, from extremely simple 
list/view requirements where everything can be done in 5 lines of php in 
the main plugin class through to struts style controllers based on 
cascading control classes tied together with configuration that assists 
in the interpretation of command parameters. A forms library should be 
useful in all these cases.


In summary, what do you think about an API that goes something like the 
following.

* class tx_forms.renderer.php {
	// render form fields, values, combined form/list components from meta data
	renderForm($fieldList,$TCA,$data);
	renderView($fieldList,$TCA,$data);
	renderList($fieldList,$TCA,$data) ;
	renderSearchForm($TCA,$searchCriteria)
	
	renderFormMarkers($fieldList,$TCA,$data)
	renderFormField($field,$TCA,$data);
	renderFormValue($field,$TCA,$data);

	renderRTEValue
	renderLinkValue
	.....
	renderRTEFormField
	renderRTELinkField
	.....
}

* class tx_forms.inputprocessing.php {
	// capture post variable input and convert it into a format suitable 
for internal storage/persistence.
	processDataValue($field,$TCA,$data);
	processDataValues($fieldList,$TCA,$data);
}
* class tx_forms.dataprep.php {
	// convert the internal representation of entity from what is loaded by 
the database to something suitable to pass to the rendering classes. For 
example converting lookup ids into strings.

}
* class tx_forms.validation.php {
	// validation based on TCA meta data
	validate($fieldList,$TCA,$data);
	
	validateField($field,$TCA,$data);
	
	validateEmail($data)
	.......
}


// because there are potentially many data stores, the persistence class 
hierarchy should start abstract. I feel the rendering, input processing, 
data prep and validation can be implemented in 'the one true way' based 
on the TCA
// there is a strong argument that the persistence classes belong in a 
different extension. The reason I suggest combining them into tx_forms 
is the cohesion/interdependance that is created by the 'standard format' 
  of the internal data storage. perhaps an argument for entity bean style.
* abstract class tx_forms.persistence.php {
	// save/load/search assisted by meta data, TCA extensions required for 
search configuration
	save($fieldList,$TCA,$data)
	load($fieldList,$TCA,$uid)
	delete($TCA,$data)
	search($searchConfig,$searchCriteria)
}
* class tx_forms.mysql_persistence.php implements tx_forms.persistence{
	save($fieldList,$TCA,$data)
	load($fieldList,$TCA,$uid)
	delete($TCA,$data)
	search($searchConfig,$searchCriteria)
}
	
I have a vested interest in this topic. With some friends I look after 
the admin_interface extension which is essentially a forms lib.
It is rooted in fe_adminLib.inc as are many of the existing forms lib 
extensions however I started by ripping the code to generate form 
components and parse form input and then went my own way.
It probably wouldn't pass muster for great coding style but I have been 
working toward improving that. Recently split the whole thing up from a 
monolith to MVC, more work to do there removing interdependance between 
the components. There are a few of us here in Bega that are very keen to 
   continue to refactor the code base until it is a tidy and reusable 
library that could be used for tx_forms.

I expect we will be working toward something like this inside the next 
month. Much of the TCA rendering functionality is already done.
I'd really appreciate comments and feedback about the structure I am 
proposing.


cheers

Steve Ryan
stever at syntithenai.com