Hello,
Nice to hear that developers want to use metadata as central point for all
module control.
Tabs:
You are right, it is not the best time to add it to 4.7, but you can similar
thing with menu.xml in module directory.
The only thing you can not do with menu.xml, is positioning and displaying on
specific module select, if is global.
<?xml version="1.0" encoding="ISO-8859-15"?>
<OX>
<OXMENU id="NAVIGATION_ESHOPADMIN">
<MAINMENU id="mxextensions">
<SUBMENU id="mxmodule" cl="module" list="module_list">
<TAB id="tbclmymoduletest" cl="myModuleTest"/>
</SUBMENU>
</MAINMENU>
</OXMENU>
</OX>
Title translations has to be defined in admin language file.
'tbclmymoduletest' => 'MYMODULE_TEST',
Constraints and Database:
* Dynamic module constraints and database table creations in is our plans for
future.
Improvements in module system ( for version 4.7 ):
1. Added activated module version tracking (for future install/update
functionality)
2. Fixed module settings management, now they can be edited even if module is
not active (as suggested by AZ in oxid commons).
3. Shop file structure transformations affected module system too (language
files and template blocks), but backward compatibility is preserved.
Frontend translations
modules/mymodule/out/lang => modules/mymodule/translations/
Admin translations
modules/mymodule/out/admin/ => modules/mymodule/views/admin/
Template blocks files has to be written including full path from module
directory.
4. Introduced module events, executed on module activation and deactivation,
more events will come in other releases
'events' => array(
'onActivate' => 'myModuleTestEvents::onActivate',
'onDeactivate' => 'myModuleTestEvents::onDeactivate'
)
'files' => array(
"myModuleTestEvents" => "mymodule/core/mymoduletestevents.php",
),
Greetings
Alfonsas Cirtautas
________________________________
From: [email protected]
[[email protected]] on behalf of Robert Rosendahl
[[email protected]]
Sent: Tuesday, October 16, 2012 12:44 AM
To: OXID eSales Mailingliste
Subject: [oxid-dev-general] module handling in admin (eShop 4.7.0 RC1)
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
