Hi, it's probably too late for OXID eShop 4.7, as the first release candidate has already been published, but I thought I'd share some thoughts on module handling in the admin area anyway ;-)
I think it would be very useful to be able to add tabs to modules, e.g. by defining language constants and admin controller classes in the metadata, e.g.: $aModule = array( // ... 'id' => 'mymodule', 'tabs' => array( array( 'title' => 'MYMODULE_TEST', 'class' => 'myModuleTest', 'position' => 10 ), ), 'files' => array( 'myModuleTest' => 'mymodule/admin/mymoduletest.php', ), // ... ); This should result in a tab with the translation for 'MYMODULE_TEST' being shown when the module with id 'mymodule' has been selected in the list. The tab should be shown in addition to the usual "Installed Shop Modules", "Overview" and "Settings" tabs. This tab only appears when this module has been selected and disappears when another one is selected. That would allow us to add tabs to the modules in the "extensions" menu in the admin area. I believe that this should be the central area where all information, settings and additional options for modules should be placed, so they can be found more easily. Most modules would not need a separate main menu entry if they could offer their functionality here (and the entries from the menu.xml only seem to appear after activating the module and then logging out and in again, thus refreshing the main menu sidebar). Another thing that I would really love to have is some way to modify module settings constraints during runtime. I'm writing a module that needs to show some entries from an external system (groups and topics from the GREYHOUND server) and store their ids in a module setting. I'd like to fill the options for the "select" settings type dynamically by fetching them from the external system. I could do that by writing a module of module_config and then override the _loadConfVars() method, but I can only add the settings values (in my case the ids of the external entries), but not their titles. The titles are generated in the module_config template by appending SHOP_MODULE_ + setting-variable-name + value. That means that I would have to generate language constants on the fly, which I can't ;-) If there was a method in either module_config oder oxModule that would return both the values and the (already translated) titles for the constraints of a module setting, then we could override that and add options for "select" settings dynamically during runtime. In fact, that brings me to an idea that came to my mind the more I looked through the code of the oxModule class and the metadata idea in eShop 4.6: I think it would make sense to put all module specific stuff into oxModule, including an option to fetch the constraints of settings variables, the tabs for the admin module list (if that module has been selected), etc. That would give us a single point that we could extend to represent our individual module. The data can of course come form metadata.php initially and be read and interpreted by the oxModule methods, but the more methods we have in oxModule, the better we can customize our modules for things that can't be solved by just editing the metadata file. I've read some discussions about being able to create database tables (or probably also to check database consistency) when activating a module. There could (and probably should) be a hook for that in oxModule, too. So, if oxModule would hold all the central module handling functionality, then we could extend oxModule by a module and override these methods to customize them to our needs (e.g. always checking if $this->getId() == 'mymodule') first). What would be even better still (but would require more code changes in the shop admin) would be to be able to specify a class that extends oxModule in the metadata and have the shop instantiate that class instead of just oxModule when loading the module with that id. Then each module could represent itself by its own extension of oxModule, if it needs to do some fancy stuff that cannot be solved by the metadata directly. What do you think? Would that make sense for your modules, too? Might be that I'm the only one with such obscure requirements ;-) Which module functionality do you think could be handled in oxModule as the central "module" object? Like I said, it's probably too late to make it into eShop 4.7... It just would be hot because 4.7 would already introduce massive api changes, and if we could just fit in some changes that would make integrating modules into the admin more easy, then this would probably save us some worries in the future. Cheers, Robert
_______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
