[TYPO3-dev] FORM element

[Francois Suter]

Hi,

Warning, long post :-)

> just fyi - i talked to Patrick Broens and we formed a team to force 
> developing enhanced FORM.
> Atm there is also Ingo Renner and Ernesto Baschny joining the team (Ernesto 
> doesn't know yet :-) ).
> At first we investigate all Form extensions and add-ons (there are over 30 
> available) to decide which way we want to go.
> We will keep you informed about our steps, and when a website or wiki is 
> started for that, we will inform you as well.
> Your ideas and comments are welcome at any time, also joining the team.

Good, because I thought about all this some more and have much more to 
say :-)

Actually I'll outline some of ideas here, in order not to loose them in 
the meantime :-)

As I said earlier in this thread as much as I agree that the FORM 
cObject needs enhancement, I also feel that it should be possible to 
still use it in a very simple way after that. I think we should avoid 
having a complex machine that does it all and rather break it up in 
functional parts. Maybe this is encouraged by the extensions mechanism, 
but I feel there's a tendency in the TYPO3 community to build big 
monolithic extensions rather than several small extensions that can work 
together in a more flexible way and be more reusable by other people (no 
offense meant, ok? It's just a feeling I have).

Case in point, the new FORM cOjbect. I feel it shouldn't have database 
interaction capabilities. This should be left to other scripts. Let me 
take an example: I recently released a very simple extension, called 
Cobweb Protector. It is included as a content element on a page and is 
instructed to watch for a certain variable among GPvars and to compare 
it with a given value. If the variable is defined and the value matches, 
the page is displayed. If not a redirection is made to some other page.

I designed this extension that way because it can take its input from 
any form, no matter with what it was designed (simple FORM, 
th_mailformplus, whatever). As long as the page it sits on is called 
upon submitting the form, this extension will work. This makes its use 
very flexible.

I think an object that write to the database should be designed the same 
way: it should sit on a page (it could even be the same as the form's) 
and check input from GPvars. This makes it possible to have a variety of 
objects to handle such stuff, some very simple, some other which might 
have complex workflows. A site developer would use whatever object suits 
his needs best.

This raises 2 points I've been thinking hard about recently, 2 kind of 
mechanisms that I feel would be useful:

- a message queue: I've been using that for years in my custom 
developments. The idea is to have a global variable which stores a queue 
of messages (errors, warnings or success messages). The message can be 
added for immediate delivery (in which case they get displayed in the 
page itself) or queued for later delivery (stored in session and 
displayed in the next page, which allows for redirections). Several 
named areas can be defined, if error messages are to appear in different 
places on the page. Each of these areas must of course be placed 
somewhere in the template. This makes it very easy for any object to 
throw error messages. It can just be queued in the message queue and the 
object can be confident that it will be displayed at the right point.

- page header objects: recently I encountered the problem of wanting 
something like content objects, but that just do some application logic 
and don't display anything. My solution was to do these indeed as 
content objects and have them placed first in my content area, and just 
have them not display anything. But it would be more logical to have a 
Page Header where those could be placed and arranged in order, just like 
normal content elements. The other typical solutions today in TYPO3 are 
not satisfactory: either those objects are defined as libraries and 
loaded all the time (even when they are not needed) and attached to 
every page with TS, which is a bit better, because TS can at least be 
limited to a part of the page tree (and even a single page if you care 
to unset your TS object, but that's a bother if there are a lot of 
subpages).

All of this I think is related to the redesign of the FORM cObject, as 
it would make it possible to keep the FORM simple while adding a lot of 
possibilities for using it within complicated application logic.

Does this make sense? I would be glad to have your feedback, because it 
is a direction I'll certainly be moving into sometime soon and I feel it 
could be valuable to TYPO3 as a whole (and I'm not being pretentious, 
just very convinced :-).

Cheers

-- 

Francois Suter
Cobweb Development Sarl - http://www.cobweb.ch