[TYPO3-ect] Again: Forms library

[ries van Twisk]

I don't have a solution,

but the main result that PHP doesn't have a forms library is
that

a) it's complicated to handle all, if not most situations
b) PHP is a scripting language..

me and gerard made our own which does a good job,
but is ajax based. I know Elmar doesn't like that.
Not I think it's good for deployment due to it's complexity.

Ries

On Oct 22, 2007, at 11:39 AM, Simon Tuck wrote:

> Elmar Hinz wrote:
>> Hello,
>>
>> time to reopen this theme.
>>
>> Do you sometimes wonder, why there isn't a really good forms library
>> available for PHP, although PHP is that many years old by now? I  
>> often do.
>>
>> Google.com gives me an ECTs wiki page as 5th result for the search  
>> "php
>> forms library". No joke. That is funny and sad at the same time.  
>> Other
>> languages overtake right and left. Just think of the modern  
>> JavaScript
>> frameworks.
>>
>> Is it that difficult to write a forms library? I don't think so.  
>> Kasper
>> wrote 2 of them. One for the BE, the TCE Forms, but they are not  
>> usable for
>> FE plugins. The second, the TS forms, are for the FE, but they are  
>> not
>> object orientated, so that the are unflexible in the field of plugin
>> development.
>>
>> The core team modernizes the forms element by now. Who knows  
>> details? Will
>> it be object orientated?
>>
>> I meanwhile have made up my own vision of a forms library. It   
>> should be
>> useful inside and outside TYPO3. There would be an object tree that
>> represents the forms structure and data, but no rendering data at  
>> all. The
>> rendering would be the task of independent renderers. (It could be
>> orientated on the XFORMS specification).
>>
>> Because it doesn't contain rendering informations, it is rather  
>> simple to
>> code. The second advantage is, that you could choice between  
>> different
>> tools, to output the form to differnt formats.
>>
>> Also the construction would be simple. It would be generated from a
>> typoScript or XML setup. Finally the population with data is  
>> straight away.
>> The data finds it's places by the name/id that every form element  
>> has. You
>> don't have to fiddle with the structure of the tree at all. It  
>> would simply
>> take an array or object like piVars.
>>
>> To summarize:
>>
>> The usage has three steps:
>>
>> 1.) Automatic tree object tree creation:
>>
>>   From a setup with TS or XML or PHP array. Could evalute the TCA.
>>   It's a real object tree that can be extended, processed etc.
>>
>> 2.) Populating the tree with data:
>>
>>   Array or object with id/names as index.
>>
>> 3.) Rendering the tree to output:
>>
>>    Could be simply rendered to a form as a whole.
>>    Could be placed piecewise by ids into templates like smarty.
>>
>> What do you think about? Does anybody take up the spark to light a  
>> firework?
>>
>> Regards
>>
>> Elmar
>>
>>
>
> Hi Elmar,
> I have on occasion used the pear quickforms library. In combination  
> with
> Smarty it is a comfortable solution, because it will render  
> directly to
> Smarty (it works w/o Smarty as well of course). In this context I  
> have a
> patchwork of classes and methods (nothing I'd call mature) which
> translate TCA configurations into quickform and allow additional
> configuration via TS. So my question is, what's the general opinion on
> the PEAR quickform library?
> Cheers,
> Simon
> _______________________________________________