[TYPO3-ect] Again: Forms library

[Simon Tuck]

Hi Elmar,

Elmar Hinz wrote:
> 
> Your approach seems to me the most promising solution for the efficiant 
> development of formbased FE plugins with TYPO3 on the short end. Could be
> very interesting to let your patchwork collection grow to a usable library.
> I think there are a lot of people that need to deal with forms day by day.
And a it's huge headache I might add. the number of form libraries 
available in the TER is testament to the fact that we as programmers are 
lazy and would rather spend weeks coding a forms library than coding 
forms logic and presentation in PHP ;-)

I would certainly be interested in contributing to this project, but in 
view of the many form libraries available in the TER I am apprehensive 
about whether we are working at cross purposes here. I have to say that 
some the solutions in the TER are pretty impressive, my main issue has 
always been that they are locked into TYPO3 (with all it's quirks) and 
(due to the nature of the problem) very complex. Whereas pear projects 
(such as qf) are much more widely used and familiar to people who do not 
know TYPO3. In particular, seeing as I use Smarty a lot and qf has a 
Smarty renderer this seemed like the ideal approach. That's not to say 
that I haven't had my share of issues with qf, but I haven't found a 
better alternative yet.

My problem therefore was how to best integrate qf with TYPO3. As 
mentioned I decided it would be nice to be able to reuse the TCA array: 
interpret the TCA for a given table and translate this to quickform. 
additional TS mimics TCA (so configurations are merged).

The main problem I encountered was that the TS configuration becomes 
unwieldly and is not very readable. It's nice to be able to use the TCA 
array, but an additional means to define forms is essential. At any rate 
in the absence of alternatives I would stick with TS (XML is an option). 
I suspect that given the nature of the issue configuration files for 
forms  will always be fairly complex...

In practice the approach goes something like this:

// New quickform instance where $formConf delivers
// required information about tables, fields etc.
$form = tx_quickform::quickform($formConf);

[Additional form stuff. e.g add rules, set default values etc.]

if($form->validate()) {
     do CRUD or save to session for multipage forms or whatever...
}

// Render the form to the view (in this case Smarty)
// 'renderer' is an instance of the qf Smarty renderer
$form->accept($this->renderer);
$smarty->assign('someVar',$this->renderer->toArray());
						
// Render HTML
return $smarty->display($myTemplate);	

An example of the corresponding TS could look like this:

formConf {
     table = fe_users
     fieldsFromTable = email, country, zip, city, telephone
     form {
         action.parameter = some page id
         name = register
         attributes =
         method = POST
     }
     buttons {
         submit {
             type = submit
             name = submit
             value.data = LLL:EXT:locallang.xml:register.submit
             attributes = class="float_right"
         }
     }
     fields {
         email.rules.required = 1
         email.attributes.default = class="some-class"
         email.attributes.error = class="warning"
         email_again {
             label = LLL:EXT:locallang.xml:register.email_again
             config {
                 type = input
             }
             rules.required = 1
             attributes {
                 default = class="some-class"
                 error = class="warning"
             }
         }
     }
}

> 
> I can't tell something general to the PEAR quickform library. I observe that
> quickform1 is marked as obsolete while quickform2 is alpha. A state that
> didn't change since a longer time. A strange situation for a library in
> such a key position. 
> 
> Which one do you take?
The obsolete one :-) I haven't tried qf2 yet. According to the project 
page qf2 should be backwards compatible.


As I said, I'd like to help find a practicable solution for this issue 
and I'm certainly be interested in taking the discussion further...
Cheers,
Simon