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

[JoH asenau]

>> Any pitfalls I have forgotten? ;-)
>
> The way I understand it is that stdWrap does its thing in the order
> that it's listed in TSref. So for instance, with CONTENT currently
> 'wrap' happens before 'stdWrap'.
>
> 10 = CONTENT
> 10.wrap = ....
> 10.stdWrap....

Which is not due to stdWrap's order of function but to the order these
functions are called by CONTENT.
So this is already inconsistent and confusing.

> If CONTENT then got stdWrap applied to it's base wouldn't that mean it
> behaved like this?
> 10 = CONTENT
> 10.stdWrap.stdWrap...
> 10.stdWrap.wrap = ....
>
> And if it behaves like that then doesn't that mean this would change
> the order that these are then processed (as stdWrap recursively calls
> itself before wrap is called)?
>
> Or am I misunderstanding this all?

Unfortunately you are not ;-)

While still being able to call all the functions just like before, the order
will change indeed, so we won't get the expected backwards compatibility at
all :-(
The question is: Do we have to care about that and if we do, which would be
the better approach?

The goal is still to unify stdWrap functions as close as possible to the top
level. If we can't get the top level, the next level would be:

10 = TEXT
10.wrap = blah|blah #deprecated will be removed in 4.6
10.specialStuff = blah
10.stdWrap.wrap = blah|blah

with all stdWrap functions being removed from the top level.

In any case we couldn't get complete backwards compatibility, so which is
the approach that costs less?
Or do you guys have another solution?

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