[TYPO3-dev] Revamped FORM cObj, take 2

[Patrick Broens]

Hi Francois,

I've started very recently (this week :-) again with the FORM cObj, or 
the backend Form Wizard in particular.

I have a lot of ideas already on paper, but still not on the wiki. I 
will put these ideas on it asap.

It's not only the FORM cObj who needs to be rewritten, not revamped, but 
also the Form Wizard in the backend. I'm currently developing a wizard 
based on Prototype with drag and drop functionality, inline editing of 
labels and stuff. The first goal I try to achieve is to have almost 
every configuration you can imagine in there. For instance the 
validation is extendible, some default settings are there, but you can 
also add your own validation to it. When you have a look on the Wiki, 
I'm currently using a markup solution published by Cameron Adams on 
Sitepoint which makes the form stylable very well. It's an accessible 
markup which will be used in the FORM cObj as well as in the Wizard.

I can write down all my ideas here, but then you will get a huge email. 
Stay tuned on the wiki.

Please inform me about your ideas and development.

Patrick

PS. Most of the users don't know you can add regular expressions in the 
form wizard, so it is possible to add your own validation :-)

Francois Suter wrote:
> Hi all,
> 
> I know the revamping of the FORM cObj has been pushed back to 4.3 and 
> that we should be concentrating on 4.2, but client projects schedules 
> sometime push items to the top of the personal agenda :-)
> 
> I have started developing a tool to handle online processes of pretty 
> varied format (one or more steps, forms to fill out, online payment, 
> downloads, etc.), so I went for a flexible structure akin to "cal" 
> (central controller, models and views as services).
> 
> Whatever the details, my main concern here is about forms. Basically 
> what I am trying to achieve is to use the standard FORM cObj from inside 
> my extensions and simplify configuration work by just referencing 
> tt_content.mailform.20.
> 
> This also implies things like a helper class to create FORM 
> configurations or to translation TCA information to FORM syntax.
> 
> Now this comes up against a few limitations (I may be forgetting some):
> 
> 1) the FORM cObj has only few validation rules
> 2) the rendering of the FORM cObj is not totally coherent, especially 
> when it comes to radio buttons and checkboxes
> 3) the FORM configuration syntax should be extended to be able to 
> defined rows, groups, sections (more maybe?) structural elements to 
> group fields (in rows, fieldsets, div's of alternating color, whatever).
> 
> For the time being I'm putting stuff into an extension, but I think such 
> work should not go wasted and should help towards the goal of a revamped 
> FORM cObj. Which is why I am writing here at a very early stage to 
> inform you of what I am doing and - ideally - get feedback, ideas or 
> directions.
> 
> Should I start by putting some of my ideas into the wiki? I'm just not 
> sure where...
> 
> Cheers
>