[TYPO3-4-3] Re: [TYPO3-dev] Fixing the last 20% and TypoScript annoyance

[JoH asenau]

My fault. I always thought, typo3.dev was the "general" list.
So let's move it there ...

Sorry for the confusion

Joey

> The same is being discussed since some days in the 4.3 general list.
> Perhaps we should join the discussions before it gets confusing.
>
> 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

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your gob sometimes!)
Dieter Nuhr, German comedian
Xing: http://contact.cybercraft.de
Twitter: http://twitter.com/bunnyfield
TYPO3 cookbook (2nd edition): http://www.typo3experts.com