[TYPO3-4-3] [TYPO3-core] RFC #13074: Feature: stdWrap for inclusion of CSS and JS files via pageRenderer

[Ernesto Baschny [cron IT]]

Steffen Kamper schrieb am 07.02.2010 23:23:
> Hi Joey,
> 
> JoH asenau schrieb:
>>>> 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']
>> }
>>
> 
> yes, that would be possible.
> 
>> 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.
>>
> 
> exact this is what makes it really difficult to understand, you always
> have to look in tsRef to see if a parameter supports stdWrap.
> 
> I'm for this solution if really "every" parameter support stdWrap if
> used with "name" + ".". This would make it for a user easy and transparent.
> 
>>> 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)
>>
> 
> I know this object is one of the most complex object. Do you think it's
> possible to make it more easy and transparent?
> 
> 
>> 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
>> 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%" :-)
>>
> 
> yes, +1 for this. And a general stdWrap for all params when used with
> "." :)
> 
> Also extension authors should support this:
> $this->conf['param'] = $this->cObj->stdWrap($conf['param'],
> $conf['param.']);

Which "all params" do you mean? Depending on the context, the stdWrap
cObject might contain different data (e.g. in case of a menu it might
contain the currently rendered menu item).

And what is your idea regarding USER objects? You cannot simply add
support to .stdWrap on "all parameters" without interfering with what
the plugins do with their TypoScript tree. They might already be using
the .stdWrap property?

So still I don't understand the proposed concept, other than adding the
stdWrap() call to used property where we aren't doing it yet.

Could someone clarify?

Cheers,
Ernesto