Hi Andreas, (1). OK.
(2). As far as I can tell, the list of classes that cannot be extended is totally arbitrary and is not controlled in any way. If you trace in Eclipse from index.php you'll see this is just a consequence of the way the classes are created before you hit the call _loadVarsFromDb() in oxconfig->init(), to load aModule. Any class that is created before then cannot be extended. Regards from Augsburg Chris Jolly Ontraq Europe ________________________________ From: anzido GmbH <[email protected]> To: [email protected] Sent: Sat, November 6, 2010 10:40:20 AM Subject: Re: [oxid-dev-general] Suggestion: Put modules from database intoan PHP File [T-DIA317V99U-31] Hi Chris, I am not really sure but I think: (1) is done just because using the oxconfig stuff is a very simple way to store the module configuration. And oxconfig values are encoded because there might be some confidential parameters in there, e. g. if you store account data for smtp or for other modules (soap access etc.) into oxconfig table. So if the database would be hacked those parameters could not be read in a simple way (allthough everybody who knows a little bit about oxid can decode them ...). (2) I think that the OXID developers wanted to prevent some classes from beeing overloaded cause they are sort of basic for the whole shop functionality and can easily screw the whole thing up. So I guess this had been done to have some control about such essential stuff. But that's just a guess ... Beste Grüße aus Dortmund! Andreas Ziethen | Geschäftsführung -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: [email protected] Web: http://www.anzido.com/ USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 -----Ursprüngliche Daten----- Datum: 03.11.2010 18:24:32 Von: Chris Jolly <[email protected]> An: <[email protected]> Betreff: Re: [oxid-dev-general] Suggestion: Put modules from database intoan PHP File Vorgang: T-DIA317V99U-31 Am I missing something, because this seems very simple to me... > >(1). Why is it necessary to encode the list of plug-in modules and to then >store >this in the database ? >(2). Why is it necessary to start the framework in such a way that 5 classes >can't be extended ? > >If there are no good reasons for either and assuming the fix is simple, why >shouldn't we ask OXID to make this change ? > > > > > ________________________________ From: Christopher Simon <[email protected]> >To: [email protected] >Sent: Wed, November 3, 2010 11:22:33 AM >Subject: Re: [oxid-dev-general] Suggestion: Put modules from database into an >PHP File > >Hi, > >I know that it works with a wrapper, still this doesn't solve the >"synchronization" issue within development teams. Such kind of >"emergency scripts", help for the moment, but they don't fix the source >of the problem. > >btw you can also initiate the shop framework for such a script. > >Am 03.11.2010 10:40, schrieb Stefan Krenz: >> Hi, >> >> you can edit the module list outside from OXID. >> >> We need two "wrapper" classes, one for config.inc.php (named as >> ConfigWrapper) and one for oxconfk.php (named as ConfKWrapper). >> With this classes you can get the required information: >> - ConfigWrapper->dbHost >> - ConfigWrapper->dbName >> - ConfigWrapper->dbUser >> - ConfigWrapper->dbPwd >> - ConfKWrapper->sConfigKey (needed to en-/decrypt the aModules DB entry) >> >> Connect to the database, get the content of 'OXVARVALUE' from 'oxconfig' >> with the MySQL function 'DECODE' (use 'ConfKWrapper->sConfigKey' for the >> second argument). >> You will get the serialized array within the module list. Unserialize >> and modify it and put the new serialized array into the database. Don't >> forget the encryption with ENCODE. >> >> This will also work with the Zend Guard encoded versions of OXID. >> >> Regards Stefan Krenz >> >> >> Am 03.11.2010 08:53, schrieb Christopher Simon: >>> Hi, >>> >>> when you work in a team at a shop project, you often have the problem >>> that if some team member adds a new module which is used in templates >>> and stuff the other team members have to be noticed that they have to >>> add new the new modules in their respective test database. (we work with >>> virtual machines for each dev). In addition, if a user adds a Module >>> which breaks the shop somehow, he sometimes isn't able to remove this >>> module because it broke some component which is mandatory for the admin >>> area. The module array is saved as a blob, which makes it a little >>> tricky to edit modules without the admin area. >>> >>> Because of this, we do it like this: Delete (or rename) the "aModules" >>> entry in the database and put this line in config.inc.php: >>> >>> >>> $this->aModules = tc_modules($this); >>> >>> "tc_modules" includes this nice little PHP File: >>> >>> <?php >>> return array( >>> 'oxbaseshop' => array( >>> // standard >>> 'oxorder' => 'invoicepdf/myorder', >>> ), >>> ); >>> >>> With this small modification, you are able tu put your modules in >>> projects under version control (with SVN), and work much more effective >>> in teams. If you now include a module which breaks the shop in any way, >>> you are able to simply remove it by editing the file. >>> >>> I would like to suggest this for 4.5. >>> >>> Only downside: Some "module installers" would not work anymore. I know >>> that you are working on "automatic module installer" stuff, but i would >>> rather like our solution for the modules, because i think it's much >>> easier to maintain a shop without having the modules in database. Maybe, >>> our approach and the automatic installer approach are combinable. >>> _______________________________________________ >>> dev-general mailing list >>> [email protected] >>> http://dir.gmane.org/gmane.comp.php.oxid.general >> > >_______________________________________________ >dev-general mailing list >[email protected] >http://dir.gmane.org/gmane.comp.php.oxid.general > >
_______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
