[TYPO3-dev] stdWrap for all TLO's

[Ernesto Baschny [cron IT]]

Christopher Torgalson wrote: on 27.03.2008 22:00:
> On Thu, Mar 27, 2008 at 9:44 PM, Ernesto Baschny [cron IT]
> <ernst at cron-it.de> wrote:
>> Hi,
> 
> <snip>
> 
>>  But still that doesn't answer the problem of extensions that already are
>>  using the stdWrap property already inside the USER code. Say we have:
>>
>>         obj = USER
>>         obj.stdWrap.wrap = <div class="ya">|</div>
>>
>>  Now in my plugin I have (the plugin is 5 years old, it always worked
>>  like that):
>>
>>         function main($conf)
>>                 ...
>>                 return $this->cObj->stdWrap($out, $conf['stdWrap.']);
>>         }
>>
>>  And now we add the functionality in CORE so that a "default stdWrap" is
>>  always applied. Note that CORE doesn't know that the plugin already
>>  applied the stdWrap. So core goes and also:
>>
>>         cObj->stdWrap($pluginOutput, $conf['stdWrap.']);
>>
>>
>>  And now we've got:
>>
>>         <div class="ya"><div class="ya">|</div></div>
>>
>>  and we (the admin) have no way to get rid of the double application of
>>  the stdWrap, without changing the extension / plugin PHP source-code.
>>  Imagine that the "stdWrap" property was being used by some totally
>>  different reason inside the plugin (e.g. as a standard stdWrap for every
>>  field...), we cannot simply "re-use" that for a default stdWrap.
>>
>>  So in my eyes we either need another "name" for that (one that hasn't
>>  been used by plugins so far) or we just assume that all extensions that
>>  do use the "stdWrap" are deprecated (or just work with TYPO3 < 4.3).
>>
>>  Or is something wrong about that thought?
> 
> 
> Yes there is. How is it that you think this could happen without
> administrative input?
> 
> Unless I've missed something (could be, this is an old thread...)
> nobody is talking about *default* TS stdWrap on USER. The idea is to
> make stdWrap available from TS for the USER cObject as it is for all
> the others, but any particular wrap would still have to be *added* by
> individual site administrators. In this scenario, any 'double
> application of stdWrap' would have to be performed more or less
> intentionally by site admins, and so should not be any of particular
> concern of extension developers.

Yes, but in USER objects the difference is that all properties that are 
defined under the TLO (including the "stdWrap") *can* be used by the 
plugin. So if the "stdWrap" is already being used by the plugins PHP 
code for some other purpose, we will have a "stdWrap" setting being made 
on purpose (because the admin configured the plugin with that property 
or maybe the extension comes with static template already defining that 
stdWrap) but still we don't want TYPO3 to add it's own 
stdWrap-processing outside the plugins code!! So has nothing to do with 
"administrative input" or not. If this is being handled by the plugin 
already (for any reason at all), it will potentially "break" the 
plugin's output if we handle stdWrap a second time.

Imagine the plugin comes with static TypoScript like:

plugin.tx_myobj = USER
plugin.tx_myobj.stdWrap.cObject = TEXT
plugin.tx_myobj.stdWrap.cObject.value = Bogus

and my plugin somewhere deep inside uses this particular "stdWrap" 
property to render some unimportant part of my output.

So now after I upgrade TYPO3 to 4.x where stdWrap is being handled by 
typo3 outside the plugins domain, all I get is a "Bogus" output from my 
plugin!

Please correct me if I am wrong, but not always telling the same thing, 
but trying to tell me where my logic breaks exactly.

I am not against having a default "stdWrap", but this property has to 
have a name that has no meaning for existing plugins, or some "reserved" 
name (like "_stdWrap" or whatever). It cannot be called "stdWrap" for 
the reasons I tried to expose above.

Cheers,
Ernesto