[TYPO3-dev] stdWrap for all TLO's

[Ernesto Baschny [cron IT]]

JoH asenau wrote: on 27.02.2008 23:40:

>>> the idea is good but then it depends on authors using it. If it
>>> would be generally applied to USER/_INT the author must not care
>>> about and even older extensions would work this way.
>> But TYPO3 cannot know if the plugin itself already applied the
>> "stdWrap" on its own, because the cObject's rendering is like a
>> "black box". And applying a stdWrap twice can make damages. So it is
>> not possible (now)
>> to have a "fallback stdWrap" being done by TYPO3 in USER/USER_INT
>> cObjects.
> 
> ??? - What are the damages caused by a double stdWrap except some
> milliseconds of performance?
> And if there are such damages why does the possibility to use stdWrap
> recursively (yes, there is stdWrap.stdWrap.blah) exist?
> Even if the extension developer already applied stdWrap to his functions, it
> doesn't hurt to have a default stdWrap anyway.

Sorry for only following up now, but of course it does damage. Imagine:

	obj = USER
	obj.stdWrap.wrap = <div class="bla">|</div>

If the USER method already called stdWrap at the end, the output will 
already have a <div> around. If TYPO3 core now also calls stdWrap on 
that, of course you get two <div>s around the output. Same for all other 
transformations applied by stdWrap, some might even be more dangerous 
than this one.

> What I'm asking for is just the option to add stdWrap parameters to any
> USER/USER_INT element regardless of what the developer of the plugin already
> did.
> If there already is something available, fine, we don't have to use the
> default stdWrap then.

Ok, so you have to call this parameter something other than "stdWrap", 
because many plugins are probably already using it. What name would you 
give this property? It cannot clash with any property already being used 
by any extension.

> But if there is nothing (which is the case for lots of extensions), the
> administrator can still use stdWrap parameters to process or wrap the output
> of the plugin without having to use the COA workaround.
> 
> To make sure the performance loss will only happen, if there really is a
> stdWrap parameter in the setup, there could be a check for the existance
> before the stdWrap function is called.

Cheers,
Ernesto