This provides a way to create forms
textarea:Label | [* = required][fieldname =] textarea[,cols,rows,"wrap= [eg. "OFF"]"] | [defaultdata] | Special evaluation configuration (see note below)
input:Label | [* = required][fieldname =] input[,size,max] | [defaultdata] | Special evaluation configuration (see note below)
password:Label | [* = required][fieldname =] input[,size,max] | [defaultdata]
file:Label | [* = required][fieldname (*1)=] file[,size]
check:Label | [fieldname =]check | [checked=1]
select:Label | [* = required][fieldname =]select[,size (int/"auto"), "m"=multiple] | label [=value] , ...
radio:Label | [* = required][fieldname =]radio | label [=value] , ...
hidden:|[fieldname =]hidden | value
submit:Label |[fieldname =]submit | Caption
reset: Label |[fieldname =]reset | Caption
label:Label | label | Label value
property:[Internal, see below]
------------------
This is an example, where "Brown" is the preselected item of a selectorbox:
Haircolor: | *haircolor=select| Blue=blue , Red=red , *Brown=brown
You can enter multiple items to be preselected by placing a asterisk in front of each preselected item.
This can be done with the following properties from the table below:
type, locationData, goodMess, badMess, emailMess
syntax:
|[property] =property | value
(*1) (fieldname for files)
In order for files to be attached the mails, you must use the fieldnames:
attachment, attachment1, ... , attachment10
In order for the mails to be attached with the email address of the people that submits the mails, please use the fieldname "email", eg: Email: | *email=input |
By prefixing a “*” before the fieldname of most types you can have the value of the field required. The check is done in JavaScript; It will only submit the form if this field is filled in.
Alternatively you can evaluate a field value against a regular expression or as an email address for certain types (textarea, password, input).
This is done by specifying the “Special evaluation configuration” for those types as part 4 in the configuration line (see examples above).
The special evaluation types are divided by a semicolon (“:”).
The first part defines the evaluation keyword. Current options are “EREG” (for regular expression) and “EMAIL” (for evaluation to an email address).
If the “EREG” keyword is specified the 2nd and 3rd parts are error message and regular expression respectively.
Examples:
Your address: | address=textarea,40,10 | | EREG : You can enter only characters A to Z : ^[a-zA-Z]*$
Your email: | *email=input | | EMAIL
Property: | Data type: | Description: | Default: |
|---|---|---|---|
data | string /->stdWrap | This is the data that sets up the form. See above. "||" can be used instead of linebreaks | |
dataArray | [array of form elements] | This is an alternative way to define the form-fields. Instead of using the syntax with vertical separator bars suggested by the .data property, you can define the elements in regular TypoScript style arrays. .dataArray is added to the input in .data if any. Every entry in the dataArray is numeric and has three main properties, label, type, value and required. 'label' and 'value' has stdWrap properties. There is an alternative property to .value, which is .valueArray. This is also an array in the same style with numeric entries which has properties label, value and selected. 'label' has stdWrap properties. Example: dataArray { 10.label = Name: 10.type = name=input 10.value = [Enter name] 10.required = 1 20.label = Eyecolor 20.type = eyecolor=select 20.valueArray { 10.label = Blue 10.value = 1 20.label = Red 20.value = 2 20.selected = 1 } 40.type = submit=submit 40.value = Submit } This is the same as this line in the .data property: Name: | *name=input | [Enter name] Eyecolor: | eyecolor=select | Blue=1, *Red=2 | submit=submit | Submit Why do it this way? Good question, but doing it this way has a tremendous advantage because labels are all separated from the codes. In addition it's much easier to pull out or insert new elements in the form. Inserting an email-field after the name field would be like this: dataArray { 15.label = Email: 15.type = input 15.value = your@email.com 15.specialEval = EMAIL } Or translating the form to danish (setting config.language to 'dk'): dataArray { 10.label.lang.dk = Navn: 10.value.lang.dk = [Indtast dit navn] 20.label.lang.dk = Øjenfarve 20.valueArray { 10.label.lang.dk = Blå 20.label.lang.dk = Rød } 40.value.lang.dk = Send } | |
radioWrap | ->stdWrap | Wraps the labels for radiobuttons | |
type | int | Type (action="" of the form): Integer: this is regarded to be a page in TYPO3 String: this is regarded to be a normal url (eg. "formmail.php" or "fe_tce_db.php") Empty; the current page is chosen. NOTE: If type is integer/empty the form will be submitted to a page in TYPO3 and if this page has a value for target/no_cache, then this will be used instead of the default target/no_cache below. NOTE: If the redirect-value is set, the redirect-target overriddens the target set by the action-url NOTE: May be overridden by the property override feature of the formdata (see above) | |
target | target | Default target of the form. | |
method | form-method | Example: GET | POST |
no_cache | string | Default no_cache-option | |
noValueInsert | boolean | By default values that are submitted to the same page (and thereby same form, eg. at searchforms) are re-inserted in the form instead of any default-data that might be set up. This, however, applies ONLY if the "no_cache=1" is set! (a page being cached may not include user-specific defaults in the fields of course...) If you set this flag, "noValueInsert", the content will always be the default content. | |
compensateFieldWidth | double | Overriding option to the config-value of the same name. See "CONFIG" above. | |
locationData | boolean / string | If this value is true, then a hidden-field called "locationData" is added to the form. This field wil be loaded with a value like this: [page id]:[current record table]:[current record id] For example, if a formfield is inserted on page with uid = "100", as a page-content item from the table "tt_content" with id "120", then the value would be "100:tt_content:120". The value is use by eg. the cObject SEARCHRESULT. If the value $GLOBALS["HTTP_POST_VARS"]["locationData"] is detected here, the search is done as if it was performed on this page! This is very usefull if you want a search functionality implemented on a page with the "stype" field set to "L1" which means that the search is carried out from the first level in the rootline. Suppose you want the search to submit to a dedicated searchpage where ever. This page will then know - because of locationData - that the search was submittet from another place on the website. If "locationData" is not only true but also set to "HTTP_POST_VARS" then the value will insert the content of $GLOBALS["HTTP_POST_VARS"]["locationData"] instead of the true location data of the page. This should be done with search-fields as this will carry the initial searching start point with. NOTE: May be overridden by the property override feature of the formdata (see above) | |
redirect | string /stdWrap | url to redirect to (generates the hiddenfield "redirect") Integer: this is regarded to be a page in TYPO3 String: this is regarded to be a normal url Empty; the current page is chosen. NOTE: If this value is set the target of this overriddes the target of the "type". | |
recipient | (list of) string /stdWrap | Email recipient of the formmail content (generates the hiddenfield "recipient") | No email |
goodMess | string | Message for the formevaluation function in case of correctly filled form. NOTE: May be overridden by the property override feature of the formdata (see above) | No message |
badMess | string | Prefixed Message for the formevaluation in case of missing required fields. This message is shown above the list of fields. NOTE: May be overridden by the property override feature of the formdata (see above) | No message |
emailMess | string | Message if a field evaluated to be an email adresse did not validate. NOTE: May be overridden by the property override feature of the formdata (see above) | |
image | ->IMAGE (cObject) | If this is a valid image the submitbutton is rendered as this image!! NOTE: CurrentValue is set to the caption-label before generating the image. | |
layout | string | This defines how the label and the field are placed towards each other. Example: This substitutes the "###FIELD###" with the field data and the "###LABEL###' with labeldata. <tr><td>###FIELD###</td><td> ###LABEL###</td></tr> You can also use the marker ###COMMENT### which is ALSO the label value inserted, but wrapped in .commentWrap stdWrap-properties (see below) | |
fieldWrap | ->stdWrap | Field: Wraps the fields | |
labelWrap | ->stdWrap | Labels: Wraps the label | |
commentWrap | ->stdWrap | Comments: Wrap for comments IF you use ###COMMENT### | |
REQ | boolean | Defines if required-fields should be checked and marked up | |
REQ.fieldWrap | ->stdWrap | Field: Wraps the fields, but for reuired fields | the "fieldWrap"-property |
REQ.labelWrap | ->stdWrap | Labels: Wraps the label, but for reuired fields | the "labelWrap"-property |
REQ.layout | string | The same as "layout" above, but for reuired fields | the "layout"-property |
COMMENT.layout | string | Alternative layout for comments. | the "layout"-property |
CHECK.layout | string | Alternative layout for checkboxes | the "layout"-property |
RADIO.layout | string | Alternative layout for radiobuttons | the "layout"-property |
LABEL.layout | string | Alternative layout for label types | the "layout"-property |
stdWrap | ->stdWrap | Wraps the hole form (before formtags is added) | |
hiddenFields | [array of cObject] | Used to set hiddenFields from TS. Example: hiddenFields.pid = TEXT hiddenFields.pid.value = 2 This makes a hidden-field with the name “pid” and value “2”. | |
params | form-element tag parameters | Extra parameters to form elements Example: params = style=”width:200px;” params.textarea = style=”width:300px;” params.check = This sets the default to 200 px width, but excludes check-boxes and sets textareas to 300. | |
wrapFieldName | wrap | This wraps the fieldnames before they are applied to the form-field tags. Example: If value is tx_myextension[input][ | ] then the fieldname "email" would be wrapped to this value: tx_myextension[input][email] | |
noWrapAttr | boolean | If this value is true then all wrap attributes of textarea elements are suppressed. This is needed for XHTML-compliancy. The wrap attributes can also be disabled on a per-field basis by using the special keyword "disabled" as the value of the wrap attribute. | |
arrayReturnMode | boolean | If set, the <form> tags and the form content will be returned in an array as separate elements including other pratical values. This mode is for use in extensions where the array return value can be more useful. | |
accessibility | boolean | If set, then the form will be compliant with accessibility guidelines (XHTML compliant). This includes:
Notice: In TYPO3 4.0 and later, CSS Styled Content is configured to produce accessible forms by default. | |
formName | string | An alternative name for this form. Default will be a unique (random) hash. <form name=”...”> | |
fieldPrefix | string | Alternative prefix for the name of the fields in this form. Otherwise, all fields are prefixed with the form name (either a unique hash or the name set in the “formName” property). If set to “0”, there will be no prefix at all. | |
dontMd5FieldNames | boolean | The IDs generated for all elements in a form are md5 hashes from the fieldname. Setting this to true will disable this behaviour and use a cleaned fieldname, prefixed with the form name as the ID, instead. This can be useful to style specifically named fields with CSS. |
[tsref:(cObject).FORM]
In order to creating a loginform supply these fields:
"username" = username
"userident" = password
"login_status" = "logout" for logout, "login" for login.
If you insert "<!--###USERNAME###-->" somewhere in your document this will be substituted by the username if a user is logged in!
If you want the login-form to change into a logout form you should use conditions to do this. See this TS-example (extract from the static_template "styles.content (default)"):
# loginform
styles.content.loginform {data = Username:|*username=input || Password:|*userident=password
}
[usergroup = *]
styles.content.loginform.data = Username: <!--###USERNAME###--> || |submit=submit| Logout
[global]
(shortend a bit...)
This creates a simple mailform (this is not TypoScript, but the setup code that you should put directly into the "bodytext"-field of a pagecontent record of the type "FORMMAIL":
Name: | *the name = input | Enter your name here
Email: | *email=input |
Like TV: | tv=check |
|formtype_mail = submit | Send this!
|html_enabled=hidden | 1
|subject=hidden| This is the subject
|recipient_copy=hidden | copy@email.com
|auto_respond_msg=hidden| Hello / This is an autoresponse. //We have received your mail.
|tv=hidden | 0
- "NAME" is required (the asterisk, *) and the fieldname will be "the_name". A default value is set ("Enter your...")
- "Email" is also required, the name will be "email" (which it should always be for the address to shown up properly in the real email!) and theres no default value here.
- "Like TV" is a checkbox. Default is "unchecked".
- "formtype_mail" is the name of the submit-button. And it should be if you use the build-in formmail of TYPO3. Then this var makes TYPO3 react on the input at interpret it as formmail-input!
- "html_enabled" will let the mail be rendered in nice HTML
- "use_base64" will send the mail encoded as base64 instead of quoted-printable
- "subject": Enter the subject of your mail
- "recipient_copy" : A copy is sent to this mail-address. You may supply more addresses by separating with a comma ",". The mail sent to recicipent_copy is a the same, but a separate message from the one sent to the 'recipient' and furthermore the copy-mail is sent only if the 'recipient' mail is sent.
- "auto_respond_msg": This is a autoresponder message. This is sent if the email of the "submitter" is known (field: "email"). The value of this is the message broken up in to lines by a slash "/". Each slash is a new line in the email. The first line is used for the subject.
- "tv" (again, but hidden). Repeating this field may be smart as the value "tv" is normally NOT submitted with the value "false" if not checked. Inserting this line will secure a default value for "tv".
