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

Tyler Kraft tyler.kraft at netefficiency.co.uk
Tue Feb 9 19:55:15 CET 2010



JoH asenau wrote:
>>> 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.


Right - sometimes that's handy, most time it probably doesn't matter.


>> Or am I misunderstanding this all?
> 
> Unfortunately you are not ;-)

Hey hey, it's my lucky day... or perhaps 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?

Tbh IMHO I don't think it matters. For cleanliness I think your original 
idea of applying it to the top level makes the most sense! I would 
rather look at 10.if... than 10.stdWrap.if

But I guess this then would also radically change the ability of some 
'if' statements?

Perhaps adding a new wrap  - outerWrap2 - as the very last parameter to 
stdWrap would then easily allow someone to replicate the 'wrap' and/or 
'if' that happens after stdWrap in some objects like CONTENT? This would 
then make it easy to accommodate when upgrading as well (perhaps even 
have it automatically alter the TS when upgrading)?



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

I agree.

Cheers,
Tyler


More information about the TYPO3-project-4-3 mailing list