Well, why reinvent the wheel? One table should be enough for all config
values - a namespace column inside of the oxconfig table and the
possibility to define the namespace on setting/getting would be enough,
wouldn't it ? Just my 2 cents.
--
mit freundlichen Grüßen
Alexander Kludt
__________________________
Phone: 09283-5925453
Skype: kingschnulli
Email: cod...@aggrosoft.de
Website: www.aggrosoft.de
__________________________
Aggrosoft it intelligence GbR
Tannstrasse 12
95111 Rehau
GERMANY
Sitz Rehau, Amtsgericht Hof
Steuernummer: 223/165/54508
Ust.-Id. Nr. gemäß § 27 a Umsatzsteuergesetz: DE260722773
___________________________
Diese Nachricht ist nur für den Empfänger () bestimmt, sollten
Sie nicht der Empfänger sein löschen Sie diese Nachricht
umgehend und geben Sie uns bitte per Email (cod...@aggrosoft.de) Bescheid
über den fälschlichen Erhalt.
anzido GmbH schrieb:
Hi all,
I'd like to discuss an issue that I am thinking about for some time:
As a sort of 'best practice' we do try with all our modules to make as few
changes as possible to OXID standard-classes, -tables and files (such as
lang-files etc.). So if we do need new fields for oxarticle we do prefer to set
up an new table and put our stuff in there, connected to the oxarticle table
via OXID.
Same thing we do with config values. Now, it would be really cool to be able to
call methods like getShopConfVar() or setShopConfVar() with an additional
parameter containing the table name. So one could just copy oxconfig table and
rename it and use that for the own config stuff.
Could that be a good idea? Or did I miss anything important?
Beste Grüße aus Dortmund!
Andreas Ziethen | Geschäftsführung
_______________________________________________
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general