[Typo3-dev] cObj FORM: Make form-name globally available

David Bruehlmeier typo3 at bruehlmeier.com
Mon Jun 7 19:18:20 CEST 2004


Hello,

I am working an a small extension that should solve the following problem: I
would like to add a new field to a form that will display a series of gif's
(emoticons). Each emoticon has a link to a Java-Script that will add the
symbol for the emoticon to another field in the same form.

(The result would be a line of emoticon-gifs beneath the text-field of the
guestbook where the user can click an the emoticon and the
char-representation of this emoticon will go into the text-field. When the
entry is posted, the char-emoticons will then be parsed back to gifs when
displaying the guestbook.)

Adding the additional field was no problem using stdWrap in the regular FORM
cObj. However, adding the links to the necessary Java-Script poses the
problem that it takes a reference to the current form-name. Unfortunately,
even in the latest CVS-version of class.tslib_content.php, the form-name is
only created AFTER the fields are parsed. I don't see any hooks that I could
use either.

For these reasons, I decided to change the source of class.tslib_content.php
as follows:

1) Moved the creation of the form-name to the top of the function (Line 1892
to 1493 in CVS-Version 1.42)
    $formname = $GLOBALS["TSFE"]->uniqueHash();

2) Made the formname globally available:
    $GLOBALS["TSFE"]->tx_emoticons_pi1["formname"]= $formname;

3) In my own extension, I added my own Java-Script for adding the
char-emoticons to the text-field

4) Again in my own extension, I could now use the form-name for linking the
gifs to the Java-Script which would add the char-symbols in the text-field
of the form

This works, but of course it's not nice as it takes a modification of
standard-coding to get my extension running... Therefore, I wanted to ask if
you would consider this worthwhile for a feature request to Kasper. I see
the following possibilities (2a-c are alternatives):

1) The form-name creation should be done BEFORE the rendering of the
form-fields (in any case)

2a) Make the form-name globally available. This might pose problems if
multiple forms are used on one page (which form is the form-name referring
to?)

2b) Add an additional conf-value (optional): formName. If configured, check
if the formName is unique (if not, append with an extra number or something)
and used it as form-name instead of the hash-value normally used.

2c) Provide a hook for the creation of the form-name

I think this approach would not only solve my (specialized) problem, but it
would also enable people to write own Java-Script checks for their fields,
while still using the standard FORM cObj.

I would be glad to get some feedback on this proposal. Maybe you even see
other possibilities to solve to problem even in the current version of
TYPO3?

Best wishes,
Dave.






More information about the TYPO3-dev mailing list