[TYPO3-dev] future of FORM

[Kai Vogel]

Hi,

here are the results of a short brainstorming session for the FORM
assistent:


Field types:
-------------------------
- Single line
- Multi line
- Radio group (horizontal / vertical)
- Checkbox
- Checkbox group (horizontal / vertical)
- Select
- Date-Picker
- Time-Picker
- Period-Picker
- Color-Picker
- File
- File with preview (e.g. images)
- File on server
- iFrame
- WYSIWYG editor
- Script (highlighting)
- Slider
- Captcha
- Show value only
- TypoScript


Output of error messages:
-------------------------
- List
- Single messages
- Tooltips
- XML
- JavaScript array
- JSON


View types:
-------------------------
- Single page
- Multiple pages
- Fieldset
- Tabs


Other things:
-------------------------
- AJAX validation
- AJAX autocomplete


If form was submitted:
-------------------------
- Send emails
- Store into DB
- Store into external DB
- Store into session
- Log
- Execute a JavaScript function
- Execute a PHP userFunc
- Redirect to another page


Best regards
--
Kai



On Thu, 26 Aug 2010 11:08:52 +0200, Kai Vogel <kai.vogel at speedprogs.de>
wrote:
> Hi Reinhard, Hi Ernesto,
> 
> I think these are two more examples for nice to have methods:
> 
> - Some kind of Flash binding like XML output of validation results
> - Real MIME type validation of uploaded files
> 
> And what do you think about graphical statistics of the submitted data
in
> the log module?
> 
> Best regards
> --
> Kai
> 
> 
> On Thu, 26 Aug 2010 10:23:37 +0200, Reinhard Führicht <rf at typoheads.at>
> wrote:
>> Am 2010-08-26 09:50, schrieb Ernesto Baschny [cron IT]:
>>> Reinhard Führicht schrieb am 25.08.2010 19:35:
>>>
>>>>> Thank you for the insight - i would appreciate if the project would
> go
>>>>> on and i'm still very interested in a solution to easily manage
> forms.
>>>>> Reinhard - leader of formhandler-project - once wrote me (sorry for
>>>>> quoting without asking):
>>>>> "IMHO the most reasonable was, if all developers working on
something
>>>>> with forms in TYPO3, would come together and negotiate a single core
>>>>> extension that provides the basic functionality and a good API for
>>>>> advanced needs. If we could get that there would be no need for so
> much
>>>>> people worrying about one and the same problem and we finally had a
>>>>> form
>>>>> handler thats fast, stable and powerfull." (Translated from german)
>>>>> +2
>>>>> Cheers,
>>>>> Christian
>>>>
>>>> Thanks for reminding me about that. I really wanted to get in touch
> with
>>>> all the form extension authors, but I somehow got busy and forgot
> about
>>>> it.
>>>> I talked to Patrick during the t3dd09 about providing error checks
and
>>>> utility function in core to be used in form handling extensions, but
>>>> this came to nothing too somehow.
>>>> It would be really cool to team up and try to provide at least some
>>>> useful error checks in core. The new FORM object needs them,
> Formhandler
>>>> needs them, Powermail needs them and any other form extension too.
>>>
>>> That might be a good candidate for a start to get stuff in small steps
>>> into the core (in 4.5). Can you ellaborate a bit more on what you mean
>>> with "error checks" and "utility functions"?
>>>
>>> Cheers,
>>> Ernesto
>> 
>> Hi Ernesto,
>> 
>> what I have in mind is something like this:
>> The core could provide separate error check classes to be used in 
>> extensions and in the core itself.
>> 
>> Example:
>> 
>> class errorcheck_integer extends absctract_errorcheck {
>> 
>>    public function check($value) {
>>      return t3lib_div::testInt($value);
>>    }
>> 
>> }
>> 
>> That would be a very simple error check, but there could be many more.
>> 
>> Like:
>> 
>> class errorcheck_indbtable extends absctract_errorcheck {
>> 
>>    public function check($value, $settings = array()) {
>> 
>>    }
>> 
>> }
>> 
>> $settings may consist of the table and field to check.
>> The important thing is: An error check returns true/false and takes a 
>> value and a setting array as arguments. In my opinion, such error
checks
> 
>> can be used easily in other extensions.
>> 
>> Utility classes are more difficult to explain. Examples would be
>> - a usable and fully configurable mailer engine (e.g. using swiftmailer

>> http://swiftmailer.org/)
>> - a method like "getCSV($data)" which converts a multidimensional array

>> into a CSV string. (I know there is a method in t3lib_div, but it 
>> doesn't work well)
>> - I know this topic is very difficult, but it would be so important to 
>> have some kind of semi-automatic GET/POST sanitizing. Maybe like this:
>> 
>> $gpVars = t3lib_sanitizing::sanitizeForDB($gpVars);
>> $gpVars = t3lib_sanitizing::sanitizeForHTML($gpVars);
>> 
>> - A unified form submission log, where any form extension can write 
>> into. The form submission log could provide a backend module for 
>> overview, filtering and exporting the submitted data. Kind of like the 
>> Formhandler backend log, but more beautiful and - as said - unified 
>> (maybe like devlog).
>> 
>> 
>> Maybe there are many more useful methods that could be implemented, but

>> this are a few thoughts I have in mind.
>> 
>> I am looking forward to any thoughts on this topic and I am willing to 
>> participate in implementing this.
>> 
>> Regards,
>> Reinhard
>> _______________________________________________
>> TYPO3-dev mailing list
>> TYPO3-dev at lists.typo3.org
>> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev
> _______________________________________________
> TYPO3-dev mailing list
> TYPO3-dev at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev