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

[Tyler Kraft]

Hi Joey

> Well - in the dev list Steffen Ritter came up with the following check:
> 
> count(array_intersect(array_keys($TS['mypart.']),array('wrap','if',.....)))>
> 0
> 
> The second array would contain all possible stdWrap function names to make
> sure stdWrap will only be triggered when needed.
> This way we can still use special parameters AND move all default stdWrap
> functions to the top level of each object.
> 
> The interesting thing about this approach is: It would be fully backwards
> compatible, because all the existing if, wrap & co. would still be working
> as well as the existing "stdWrap.blah", since stdWrap got a recursive
> function.
> 
> There might be issues with menuitems, since they use stdWrap in a completely
> different way, but for the rest of the objects that I can remember, it
> should be no big deal.
> 
> Any pitfalls I have forgotten? ;-)

Forgive me as PHP isn't my strong point, but would this then change the 
order in which some TS would be rendered (when someone upgraded)?

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....


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?

Thanks
Tyler