[TYPO3-dev] alwaysActivePIDlist

JoH asenau info at cybercraft.de
Tue Oct 24 11:20:48 CEST 2006

>> [..]> Yes, but stdWrap is so incedribly ugly [wrap, wrap2, wrap3,
>> innerWrap,
>>> outerWrap... simply crap ;-)] that we should think of a better
>>> solution.
>>> I was thinking of a "data processing/value transformation array".
>>> Like a COA it has numbers to allow for ordering and each array entry
>>> denotes a transformation (eg a wrap). So we don't need all those
>>> incrediby high number of wraps, and pre-/apprends.
>>> Masi
>> 1. Step: implementation based on stdWrap
>> 2. Step: redesign of stdWrap.
> stdWrap is broken as it is,

says who? - And for which reason?
And if this is so, why don't you fix it?
And if you don't want to fix it, why don't you tell others what seems to be
"broken" for you so that they can fix it?

> so I'd rather add the new and shiny thing
> to  all "string propertys" rather than go and add stdWraps
> I'd like to get rid of.

These "new and shiny" things are what I would like to get rid of, since they
are just confusing people. Somebody invented the := operator for a similar
reason, but hardly anybody is using it ...

The basic idea of stdWrap is good, well known by many developers and it
works perfectly fine for any kind of object (including strings).
So why not improve and streamline the code that is executed behind the
scenes to get a better performance instead of introducing just another
I already tried to do something like that with the "fully blown stdWrap"
extension, but I introduced some conceptual bugs, maybe we can use it as a
testing field for improvements.

Anybody interested?


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

More information about the TYPO3-dev mailing list