Hi,
i love the events - some more would be nice but this is great!
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
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
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
|
