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

[Ernesto Baschny [cron IT]]

JoH asenau schrieb am 10.02.2010 17:58:
>>>> 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).
>>> "all params" simply means: Every default parameter of any default
>>> element will be sent through stdWrap if there is a key with a dot
>>> like: "param." AND "param." contains stdWrap function names.
>> What is a "default parameter"? And with "default element" you mean our
>> fixed set of available cObject types (COA, TEXT, IMAGE, etc)?
> 
> Every cObject in TSref (except USER and USER_INT) is "default" means:
> Available out of the box without having to install anything else but the
> core. We got one default toplevel object (PAGE) and default content objects
> and these objects got default parameters.
> 
>> Can you be sure that there will be no conflict with existing
>> parameters that have the same name as the stdWrap properties? Isnt't
>> this a potential problem?
> 
> No - it is not, because we will check the default objects and parameters for
> conflicts before changing anything. If we might find a problem, we will try
> to find a solution that fits the "rules" we are currently discussing as
> close as possible. But this is quite unlikely, because AFAIK there is no
> such parameter, since parameters with the same name as stdWrap functions
> usually are "executed" using the corresponding stdWrap functions.
> 
> There might be some changes of the current behaviour, but I expect them to
> be in a range that will be acceptable for most of the setups. As there is
> always the option to have a compat-version and a corresponding option in the
> install tool, I don't see too many problems.
> 
> Did I miss something else?

No, that were exactly my "fears", which you are talking small, but to me
are pretty crucial. Manually going through every parameter in TSref to
scan for potential conflicts sounds like a very audacious task.

We need to go through the complete tslib classes and remove all manual
calls to stdWrap which are then being replaced by the "automagical"
calls (else we would call it twice).

I love the idea and hope we can get that working, but I guess it is not
as easy as Steffen is implying. Walking through the array is the easy
part, but the task of cleaning up the existing code is not.

Cheers,
Ernesto