[TYPO3-dev] stdWrap for all TLO's

[JoH asenau]

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

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

Just my 2 cents

Joey

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your gob sometimes!)
Dieter Nuhr, German comedian
openBC/Xing: http://www.cybercraft.de
T3 cookbook: http://www.typo3experts.com
Jobs: http://www.professionals-only.com