[TYPO3-dev] Fixing the last 20% and TypoScript annoyance

[Susanne Moog]

The same is being discussed since some days in the 4.3 general list.
Perhaps we should join the discussions before it gets confusing.

Best regards,

Susanne


Am 09.02.2010 13:54, schrieb JoH asenau:
> I took this one from the core list to get more ideas.
> The original thread was about adding stdWrap to includeJS.name like:
> 
> includeJS {
>     name = blah
>     name.stdWrap.wrap = blubb|blubb
> }
> 
> my first idea was to make it even shorter
> 
> includeJS {
>     name = blah
>     name.wrap = blubb|blubb
> }
> 
> on the other hand most of the TS elements do it with a special stdWrap
> parameter.
> 
> So IMHO we should streamline all of the TypoScript elements to stick to the
> same syntax and to remove inconsistencies as well as redundancies.
> 
>>>> Just push the value of any includeJS.blah through stdWrap and make a
>>>> prominent notice about it in the docs - that's all.
>>>
>>> i don't like that, and it has drawbacks: we need cObj all the time in
>>> pageRenderer which slows down, as it's not easy to differentiate.
>>
>> I don't see a big problem with something like that:
>>
>> if (isset($array['name.']])) {
>>     do something
>> } else {
>>     $JSfile = $array['name']
>> }
>>
>> Only use stdWrap functions, when there are any parameters assigned to
>> name+'.'
>>
>>> The "direct" stdWrap in TS only exists in TEXT, all others need
>>> stdWrap.bla. This is inconsistent anyway and confuses many users, as
>>> the TEXT object mostly is the first one they use, and they use same
>>> syntax with other objects and fail.
>>
>> This is why I always have been asking to assign stdWrap to all
>> cObjects the same way as it is done with TEXT objects.
>> HTML objects make it even worse, because the stdWrap is only
>> available as parameter of *value*.
>> COA, IMAGE, HMENU and some others use if and wrap separately, even
>> though they also use stdWrap.
>>
>>> Good comparison here is TMENU where you also have an "allWrap" and an
>>> "stdWrap" for special operation.
>>
>> This is no good comparison, because allWrap, wrapItemAndSub and
>> linkWrap are the *special* operations (for menuitems) while stdWrap
>> is *default*. And sdtWrap is used for the *text* of the menuitem
>> only, while the special parameters are applied to the ready made
>> *link*. (except you set doNotLinkIt=1, which again is a very special
>> case)
>>
>> On the other hand it would be fine for me to make it consistent by
>> using stdWrap as "the one and only" default parameter for all objects
>> (making the direct "wrap" and "if" deprecated but offering them
>> together with all stdWrap functions), while leaving the specialties
>> to the first level of parameters.
>>
>> # deprecated - will be removed in 4.6 or so
>> 10 = OBJECTNAME
>> 10.wrap = <blah>|</blah>
>>
>> # new default for all cObjects including those
>> # who still haven't got stdWrap functions
>> 10 = OBJECTNAME
>> 10.stdWrap.wrap = <blah>|</blah>
>>
>> For me consistency is a must to tackle the famous "last 20%" :-)
> 
> # new default for all cObjects having
> # special parameters besides stdWrap
> 10 = OBJECTNAME
> 10.allWrap = <blah>|</blah>
> 10.maxItems = blah
> 10.stdWrap.wrap = <blah>|</blah>
> 
> The rule would be:
> If there is a stdWrap function used by any object or parameter, remove it
> form the first level of parameters and let stdWrap do the job.
> 
> This way if, wrap & co. would be triggered by stdWrap only.
> And stdWrap would be available for any possible object and parameter.
> 
> What do you think about it?
> 
> Joey
>