[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