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

Reply via email to