Hi there, the problem lays within updates. How do you document the changes between versions? What do you do with legacy data? What to do if the update fails? (rollback)
Best regards
D³ Kristian
processed by David.fx
Subject: Re: [oxid-dev-general] Improving metadata.php (21-Sep-2012 14:42)
From: Kai Gazmaga <[email protected]>
To: [email protected]
Hi!
I absolutely support the approach. Writing the four functions optionally (kind
of interface-class) would make it clean and easy for developers. Executing SQL
is very important for me, too. There should be options to install SQL
automatically on activation and deactivation. Further there must be an option
to leave SQL untouched in order to keep data in DB. An install- /
uninstall-function would be very nice beside the current (de)activation.
As you already said, Alexander, showing infos would be interesting too, but by
far not as important, as the former things.
Regards, Kai
VektorDesign - Online-Shops und Programmierung
Kai Gazmaga
Katharinenstraße 57
73 728 Esslingen
Tel.: +49 711 - 25516226
Fax: +49 711 - 25518078
Mail: [email protected]
Web: www.vektordesign.de
Von: [email protected]
[mailto:[email protected]] Im Auftrag von Alexander Kludt
Gesendet: Freitag, 21. September 2012 14:18
An: [email protected]
Betreff: [oxid-dev-general] Improving metadata.php
Hi guys,
I was developing a new module today, and the metadata.php already makes a lot
of things possible,
but I still need a way to do some initial things - like executing sql, maybe
check some things, capture some
use input or just to show some warnings. So my idea is to add a way to execute
code "onInstall", "onUninstall", "onActivate", "onDeactivate" .
I don't know the mechanics of includinig metadata.php but maybe it could be
done like this:
<?php
$sMetadataVersion = '1.1';
$aModule = array(
'id' => 'mymodule',
'title' => 'Some Module',
'description' => 'Does something',
'thumbnail' => 'module.png',
'version' => '1.0',
'author' => 'Aggrosoft',
'extend' => array(
...
),
'blocks' => array(
...
),
...
'onInstall' => 'myModulOnInstall',
'onUninstall' => 'myModulOnUninstall',
'onActivate' => 'myModulOnActivate',
'onDeactive' => 'myModulOnDeactivate',
);
function myModulOnInstall ($aSomeInfosAboutTheShop?Module?State?){
//Write down code to execute on install, return true on success, false if it
fails
}
function myModulOnUninstall ($aSomeInfosAboutTheShop?Module?State?){
//Write down code to execute on deinstallation, return true on success, false
if it fails
}
function myModulOnActivate ($aSomeInfosAboutTheShop?Module?State?){
//Write down code to execute on activation, return true on success, false if
it fails
}
function myModulOnDeactivate ($aSomeInfosAboutTheShop?Module?State?){
//Write down code to execute on deactivation, return true on success, false
if it fails
}
?>
Maybe wrapping an inner class maybe better which follows some kind of interface
- so names will not conflict, or come up with some kind of naming sheme.
What do you think? Would this make your day easier? I think many modules can be
improved with this.
--
mit freundlichen Grüßen
Alexander Kludt
__________________________
Phone: 09283-5925453
Fax: 09283-592671
Skype: kingschnulli
Email: [email protected]
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 ([email protected]) Bescheid
über den fälschlichen Erhalt.
<<image001.png>>
_______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
