[TYPO3-ect] translations with lib/div

Steffen Kamper steffen at sk-typo3.de
Wed Aug 1 00:37:55 CEST 2007


Hi Elmar,

"Elmar Hinz" <elmar07 at googlemail.com> schrieb im Newsbeitrag 
news:mailman.1.1185901141.1407.typo3-team-extension-coordination at lists.netfielders.de...
> Hi,
>
>> We  could try to abuse a COA as configuration carrier, so that it can be
>> referenced. Mayby that works.
>>
>
> This does not work. I tested. So I don't have an Idea for a smart 
> solution.
> All 3 solutions have disadvantages.

i think there is no "kingway" (is there a simular expression in english ?)
It depends on the needs

>
> 1.) Classical
>
> Def: One configuration per plugin and common constants.
> Pros: Programming as usual.
> Pros: Easy to confiuge in TS templates.
> Cons: Much typing because of redundant configurations.
>

make sense in some cases. e.g. bananas has different params for form and 
list, there is no (less) intersection.

> 2.) By copy
>
> Def: Common configuration is copied to each plugin.
> Pros: Programming as usual.
> Pros: Few typing.
> Cons: Confusing to configure in TS templates, because of copy limitations.
>

make sense for simular plugins with common setups. i would vote for 
something like

temp.configuration {
#global part
...
}

plugin.ext.controllers.plug1 = USER
plugin.ext.controllers.plug1 < temp.configuration
plugin.ext.controllers.plug1 {
#special part
...
}
...


> 3.) By setup path
>
> Def: Configuration is taken from $GLOBALS['TSFE']->tmpl->setup.
> Pros: Few typing.
> Pros: Easy to confiuge in TS templates.
> Cons: Programming is different. Needs additional setup path.
> Cons: Confusing merging procedure with main() config.
>
no need after last cognitions (right?)





More information about the TYPO3-team-extension-coordination mailing list