[TYPO3-dev] RFC:s standard processing property as stdWrap replacement

[Martin Kutschker]

Elmar Hinz schrieb:
>> Hi Elmar and all,
>>
>> why not capsaling it, would be easier to understand for everybody, like
>>
>> TMENUITEM.wrap.all
>> TMENUITEM.wrap.subMenu
>> TMENUITEM.wrap.link
>> TMENUITEM.wrap.beforeLink
>> TMENUITEM.wrap.afterLink
>>
>> ok, now wrap is an object instead of string before, but this helps to 
>> understand the meaning of wrap without study the docs.
>>
>> vg  Steffen
> 
> Another advantage would be that it reads more like human grammer in the
> sense of: 
> 
> TMENUITEM, wrap it all.
> TMENUITEM, wrap the link.
> 
> One could go to extremes:
> 
> TMENUITEM.wrap.itAll
> TMENUITEM.wrap.theSubMenu
> TMENUITEM.wrap.theLink
> TMENUITEM.wrap.itBeforeTheLink
> TMENUITEM.wrap.itAfterTheLink
> 
> But that probably results in to much typing.

No. This won't be right because now wrap/process is dependent of the 
property of the object.

SO it must be

MENUITEM.link.process ...

(please, no article in property names)

etc

Only then TS has a clean and validatable syntax. eg the object MENUITEM 
has a property "link" of the type "string". A "string" type "object" has 
per definition the property "process".

> StdWrap shows the dilemma of wrap. Soon you want to process not only to
> wrap. TMENUITEM.wrap.itToUpperCase? That doesn't give sense.
> 
> The best solution IMHO would be to really work with two objects/functions.
> One for processing the value and one for wrapping it. That would bring 2
> advantages.
> 
> a) It is more logical to understand.
> b) It results in smaller classes and functions on level of PHP.
> 
> XYZ.process. ... = xxx
> XYZ.process. ... = yyy
> 
> XYZ.wrap. ... = xxx | yyy
> XYZ.wrap. ... = ...
> XYZ.wrap. ... = ...


What's wrong with this?

XYZ.process.10.wrap = yyy

Masi