Re: [oxid-dev-general] oxemail: put function calls intoproperty [T-D3898PM6XJ-46]
Hi Arvydas,
thx for your response.
What exactly do you mean or want to know by:
The question is how will look your function which trigger some special
functionality before sending an email dependent on the type of email?
?
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: i...@anzido.com
Web: http://www.anzido.com ( http://www.anzido.com/ )
USt-ID: DE257982972
Geschäftsführung: Andreas Ziethen
Amtsgericht Dortmund HRB 20883
-Ursprüngliche Daten-
Datum: 14.10.2010 13:21:52
Von: Arvydas arvydas.vap...@oxid-esales.com
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] oxemail: put function calls intoproperty
Vorgang: T-D3898PM6XJ-46
Hello,
thanks for your ideas, that's a good hint for refactoring/improving. Sadly
we cant just change code the way you want
due to compatibility with previous shop versions, thus we will improve this
code in next major releases.
If you are free to change/extend your own code and able to replace current
mail function calls you may use a bit tuned
your suggested executeSendMailFunction() function:
public function executeSendMailFunction( $sFunction, $aParams )
{
return call_user_func_array( array( $this, $sFunction ), $aParams );
}
The question is how will look your function which trigger some special
functionality before sending an email dependent on the type of email?
Best regards,
Arvydas Vapsva
--
From: anzido GmbH entwickl...@anzido.com
Sent: Sunday, October 03, 2010 12:24 PM
To: dev-general@lists.oxidforge.org
Subject: [oxid-dev-general] oxemail: put function calls into
property[T-D3898PM6XJ-46]
Hi,
several times we had projects where one of the requirements was to trigger
some special functionality before sending an email from oxemail class.
Especially if this special functionality is dependent on the type of
email - it is quite cumberesome to solve this, cause in the _sendMail()
function you do not know which type of email has to be sent.
So I would like to have a property which is filled by the name of the
function which has been called before, like this:
$_sActMailFunctionCall = ;
public function sendOrderEmailToOwner( $sOrder, $sSubject = null )
{
$this-_sActMailFunctionCall = sendOrderEmailToOwner;
...
}
Of course you could even build a small sort of factory function which
would be called by the several view classes, doing this job - so you would
not have to put a new line of coude into each mail function - like this
for example:
in class oxEmail:
public function executeSendMailFunction( $sFunction, $aParams )
{
$this-_sActMailFunctionCall = $sFunction;
$this-$sFunction( $aParams);
}
in oxOrder::_sendOrderByEmail():
$oxEmail-executeSendMailFunction( sendOrderEmailToOwner, $aParams );
Doing this would give developers a whole bunch of nice possibilities. For
example you could write a central function to manipulate email subjects
dependent on the type of email. Or you could save the content of special
email and so on ...
At the moment all this is possible - but you have to overload a lot of
functions for this to detect the type of email.
Using the factory function would mean that the several send-functions
would not have to be changed appart from the parameters given to them. But
even this could be done inside the factory, which then would have to
prepare the params for the single calls.
The factory way in my opinion would be the best one regarding code
layout, but I see that in terms of compatibility to old versions and
modules this could cause some trouble .. - So perhaps as a first step you
could just add the first mentioned line of could to each function?
If somebody has got a better idea to solve this - let me know!
Regards,
Andreas
--
anzido GmbH
Kirchhörder Str. 12
44229 Dortmund
Tel.: 0231 - 60 71 079
Fax.: 0231 - 60 71 081
Mobil:0176 - 8325 1488
Email: i...@anzido.com
Web: http://www.anzido.com ( http://www.anzido.com/ )
USt-ID: DE257982972
Geschäftsführung: Andreas Ziethen
Amtsgericht Dortmund HRB 20883
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
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: i...@anzido.com Web: http://www.anzido.com ( 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 cpjo...@yahoo.com An: dev-general@lists.oxidforge.org 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 si...@topconcepts.com To: dev-general@lists.oxidforge.org 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
Re: [oxid-dev-general] Suggestion: Put modules from database intoan PHP File [T-DIA317V99U-31]
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 entwickl...@anzido.com To: dev-general@lists.oxidforge.org 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: i...@anzido.com 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 cpjo...@yahoo.com An: dev-general@lists.oxidforge.org 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 si...@topconcepts.com To: dev-general@lists.oxidforge.org 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
Re: [oxid-dev-general] Suggestion: Put modules from database intoan PHP File [T-DIA317V99U-31]
Hi Andreas, Am Saturday 06 November 2010 10:40:20 schrieb anzido GmbH: (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 ... I don't think so. For this cases php knows keywords like 'final' or 'private'. Take a look to oxutilsobject::_makeSafeModuleClassParents( $aClassChain, $sBaseModule ) this method is declared as private. I think use the class chain (aModules) so early as possible is a good way. If some methods should be really protected you can do it with php keywords. Ok there exists ways to breakthrow private methods, but really a developer who know (and use) this, should know what he do. Regards, Markus ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Suggestion: Put modules from database intoan PHP File [T-DIA317V99U-31]
Hi, i agree. Additionally, there are no real downsides in doing this like proposed. You could even generate those file with ease: file_put_contents($modulesFile, '?php return ' . var_export($aModules, true) . ';' ); So you can preserve the actual frontend (or make some kind of autoinstaller, like it's planned) and have small improvements in speed, very huge improvements in maintainability and the shop gets more extendable too. Make it happen ;) ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
