Feature #15324

Clean-up in mailform code: more TypoScript flexibility

Added by Ernesto Baschny almost 14 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2005-12-29
Due date:
% Done:

0%

PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

This relates to the changes applied by #14921. This new patch enhances the features that have already been integrated into 4.0beta1 with the following:

The admin now can configure all tags from a mailform via TypoScript. There are now just very few tags hardcoded into PHP, mainly the tags that represent the fields for the FORM. The TypoScript code has been reorganized to be easier to understand and to adapt. The static TypoScript that comes with css_styled_content has been adapted for this.

- no more "accessibility=1" setting. All "accessible" settings are done just by configuring the tags and parameters in TypoScript itself. The default included TypoScript is now accessible out-of-the-box.
- all settings that are related to a specific element type (e.g. RADIO, SELECT, etc) are now organized into respective setting groups. See the new default static TypoScript to see what it means. But all "old" settings are still valid for backwards compatibility.
- the hardcoded "<label>" in accessibility-mode is now part of the TypoScript setup (labelWrap.wrap with ###ID### that gets replaced with appropriate ID). The user can override this per element-type (e.g. for LABEL type there is no <label>|</label> wrapping.
- labelWrap.wrap and REQ.labelWrap.wrap can now both be overridden in a specific element-type

Specific for RADIO-element:

- the user is now free to layout the radio-items appearance (used to be hardcoded to "[radio][label][br/]")
- static TypoScript used to have a "testform_radio" id for all radio-fieldsets, this was not only wrong, but also invalid if you have more than one radio-fieldset. Now the ID gets set correctly ("###ID###") according to the field-name.
- also the hardcoded "<legend>" is now part of the TypoScript setup, so it can be removed/changed/etc.

New settings (where XXX is the name of the element-type in UPPER-case):

- RADIO.item.layout with markers ###RADIO### (the radio-button) and ###RADIO_LABEL### (the corresponding label, stdWrapped in RADIO.item.labelWrap)
- RADIO.item.addParams with marker ###RADIO_ID### (the id of this specific item)
- RADIO.item.labelWrap with marker ###RADIO_ID### (the id of this specific item)
- XXX.addParams with marker ###ID### (the id of this field). This are attributes that will get added to the tag (input, select, textarea, ...) for this field in the FORM.
- XXX.labelWrap.wrap with marker ###ID### (the id of this field)
- XXX.REQ.labelWrap.wrap with marker ###ID### (the id of this field)

Obsolete (but still supported) settings and new equivalents:

params.xxx = XXX.addParams
radioWrap = RADIO.item.labelWrap
accessibility=1 = all accessible stuff can now be done directly in TypoScript

(issue imported from #M2119)

mailform-40beta1.diff View (13.7 KB) Administrator Admin, 2005-12-29 00:28

manual-doc_core_tsref-FORMS.sxw (28.4 KB) Administrator Admin, 2005-12-30 12:24

mailform_v2-40beta1.diff View (14.4 KB) Administrator Admin, 2005-12-30 12:28

History

#1 Updated by Ernesto Baschny almost 14 years ago

New enhancements to the mailform accessibility code. It would be cool if someone from core could review this to get integrated before 4.0-RC1!

#2 Updated by Sebastian Kurfuerst almost 14 years ago

Hi,
I had a quick glance at it: First of all - Good work!

A little thing:
please don't use "} else if" but use "elseif" instead. it is rather cosmetical.

Just to make sure I got this right: This typoscript will be activated when compatibility version is >= 3.9.0 - like it is right now with the accessibility configuration?
What happens when someone uses the old "wraps" - how do you take care this still works? (I didn't find it quickly, so I hope you don't mind the question).

Thanks for your great and permanent work!

Greets, Sebastian

#3 Updated by Ernesto Baschny almost 14 years ago

Yes, all the changes I did won't change anything in the output of what we already had in 4.0beta1: In compatibility < 3.9.0 the same "good old" tables will be generated, and in >= 3.9.0 the same "accessible" version will be generated (with a minor bug "testform_radio" fixed). So optically there are no changes. The patch "only" moves several parts that were still hardcoded in PHP into TypoScript so that they can be configurable.

The old wraps are still valid, which can be seen in the original < 3.9.0 TypoScript, which I left untouched. The params.XXX and radioWrap is still there are working. The backwards compatibility is being guaranteed in that "elseif" parts. Scan the patch for "compatibility" and you will see how it works (new settings have priority, but in the absense of these, old settings will apply).

If this gets integrated, I would recommend to mark the obsolete settings in the TSref documentation.

#4 Updated by Ernesto Baschny almost 14 years ago

The attached document "manual-doc_core_tsref-FORMS.sxw" adds all changes from this report (#15324) and also from #15324 and #15324 to the "FORM" section in TSRef.

#5 Updated by Ernesto Baschny almost 14 years ago

The new patch (mailform_v2-40beta1.diff) has the following changes from the first one:

- using "elseif" instead of "else if"
- added [TYPE].fieldWrap wrapping to be consistend
- removed ###RAWLABEL### and used already avaliable ###COMMENT### marker. Thus readding commentWrap in TypoScript.
- nicer layouting for LABEL elements (just the label)
- corrected layout for the COMMENT element
- in sync with the updated documentation

#6 Updated by Sebastian Kurfuerst almost 14 years ago

in core list.

#7 Updated by Sebastian Kurfuerst almost 14 years ago

Hi,
after some discussion with Michael, we decided not to take this patch for now, because of backwards-compliancy reasons.
I already discussed it with Ernesto.

Please reopen the bug when there are new developments.

Greets, Sebastian

#8 Updated by Ingmar Schlecht over 13 years ago

OK, now that 4.0 is released and work on new features for 4.1 can begin, I re-open this bug.

cheers
Ingmar

#9 Updated by Michael Stucki about 13 years ago

Setting this bug to a fresh state. Sebastian, feel free to assign it again if you still want to work on this...

#10 Updated by Robert Markula about 12 years ago

Any news on this subject. The new possibilities are really nice plus all the hard work already seems done. Typo3 4.2 anyone?

#11 Updated by Jo Hasenau over 11 years ago

Just to push this up.
It seems that radio buttons still get a double "label".
The text is rendered as label and as legend for the fieldset around the radiobuttons.

Has this been fixed for 4.2.1 or is it still pending?

#12 Updated by Ernesto Baschny over 11 years ago

Jo, this seem to be another issue, right? Maybe you mixed up the report ids. :) If you find the correct one, please inform me too. Thanks!

#13 Updated by Jo Hasenau over 11 years ago

Well - yes and no.
The question is:
Has this diff been implemented yet (4.2.1)?
If yes: Why are the double labels still there?
If no: Will it fix the double labels as well?

BTW: The original report seems to be missing or maybe I just didn't use the appropriate search term yet

#14 Updated by Ernesto Baschny over 11 years ago

Jo:

no, this "fix" (which is more like a new feature) was never implemented in core. It was meant for 4.0, but was dropped because of "backwards compatibility" problems and no time (and noone interested) in fixing that.

And I have no idea if this solves the "double-label" issue. I recall that we had some issue here, but I don't have it in memory. If you don't find a specific double-label bug tracker report, please submit a new report and add a notice to me.

Thanks!

#15 Updated by Morten Therkildsen about 11 years ago

Hi...

I like get get this fixed... "dobble label for radio".

Any one, got a diff-file for 4.2.1 or has a "fresh" class.tslib_content.php-file.

When I did a patch from the diff-file, something got wrong..

/Morten

#16 Updated by Alexander Opitz over 6 years ago

  • Category deleted (Communication)
  • Status changed from New to Needs Feedback
  • Target version deleted (0)
  • PHP Version deleted (4)

This issue is very old and it seems no one is interested any more. Is it still a problem in newer versions of TYPO3 CMS which should be handled or can this issue be closed?

#17 Updated by Alexander Opitz about 6 years ago

  • Status changed from Needs Feedback to Closed

No feedback for over 90 days.

Also available in: Atom PDF