[TYPO3-ect] tx_forms

[Elmar HInz]

Hello Steve,

I still didn't answer to this, because it's a lot of stuff to think about.
I will send in answer during the next days.

Regards

Elmar




Am Sat, 13 Jan 2007 02:07:24 +1100 schrieb 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