[TYPO3-dev] wich frontend libary to chose for cutom extensions

[Edwin de Jong]

Op donderdag 26 januari 2006 11:47, schreef Michael Scharkow:
> Evaluations should be maintained separately and only mixed in with a std
> hook. We do have an eval API (although only rudimentary), and we should
> use *only* that for field validation.

Well, that would also be my first guess. There are however quite some 'basic' 
form types that needs to do checking. Eg. if I were to add a 'Date' field 
where people could either enter 3 numbers or select it from an applet, I want 
to be sure the information I get back on the server is indeed a valid date. 
Nevertheless, I wouldn't want my application logic to be bothered by that: my 
application gets a good date, or it gets nothing.

> Since we have had this topic more than once (and I am still very
> sceptical about making it happen), keep the requirements down and make
> the thing modular. What do we have OO programming for?

Absolutely agreed, I see some people already coming with implementation level 
ideas on the wiki. It's best to keep at design right now.

> Some thoughts about real re-usability:
>
> 1. A basic *low-level* form API that does nothing but render a form
> element, just like the form helpers in rails:
>
> class FormItem {
> 	name = "";
> 	value = "";
> 	attributes = "";
>
> 	function render()
> 	...
> }

I would say this needs to be a component of a larger system. Also, I'd like to 
see this part to make somewhat more complex widgets as well, such as (again) 
a date enty field or 'panel' (or sections, or whatever you want to call 
them). Also, these widgets need to be part of a Listener pattern to be 
effectively used in an MVC framework.

> class StringItem extends FormItem
>
> etc.
>
> 2. A higher-level API that
> * groups form items into fieldsets, multiple pages, etc. +
> * provides controller functionality (submit, paginate, redisplay)
> * adds a hook to the eval/sanitizing API
> * returns the data

What is a fieldset? Well, I agree that this should be a seperate component, 
but this is just the C in MVC. It is indeed the controller of our view. 

> This class will also help with
> * prefixing the field names
> * filling in default or submitted values
> * applying the TS configuration to the low_level constructs
>
> 3. Finally, we need a class that does the above automagically for a
> defined model (=$TCA table definition), and adds some BE or FE-specific
> functions,
>
> so that you can essentially write code like this
>
> $address = new TCAobj('tt_address');
> if ($address->loadData($params['address']) && $address->save()){
> 	return "Saved data";
> else {
> 	return $address->renderForm;
> }

Yeps, this was almost the level we had during the development of the Cocoon 
Forms:
DataModel m = new WhatEverModel();
Form f = new AutoForm(m);
try {
	f.show();
	m.serialize();
} catch (lotsa exceptions) {}

But, on a sidenote, your input is really valuable. It would be great to see 
some of that on the wiki page.

Greets,

Edwin

(ps. this project needs a coordinator, otherwise things start falling apart 
because people have different views)