Hi Roman,
I can provide you with our own "module connector" though we like to call
it framework. Don't let the name fool you, its basically a lightweight
class that does what OXID can't: Bring streamlined OOP to modules.
In our view the metadata files are really a bad design decision. The
syntax is volatile: you always have to check twice, if you need realtive
or absolute paths, whether to include extensions or not, and top of
that: some "files" need to be in special directories, like the blocks.
So we have a Module class. You simply inherit from it, modify the
required properties and are ready to start with the logic. The Module
class introduces lots of helper methodes for working with the database,
the config and module files / paths.
The only requirement for inclusion in shops is to install the framework
first. By the way, the framework is not encrypted and does not derive
any classes from OXID. So it is a real standalone module without
version-critical dependencies.
Mit besten Wünschen,
Markus Zok
*Markus Zok*
Heckenstr. 4
40764 Langenfeld
Deutschland Tel:
Mobil:
E-Mail: +49 (0) 2173 - 848 225
+49 (0) 177 - 404 89 65
[email protected] Internet: www.zoks.net <http://www.zoks.net>
Am 21.01.14 08:31, schrieb Roman Allenstein:
Hi folks,
me and my team are developing a concept for us, how to develop modules
for oxid. We are now at the point where we have to decide to develope
a connector-module for all our coming modules or not.
We know that some agecies use their own connector to integrate their
modules in oxid. And i am pretty unsure if this is the way to go
because oxid provides a standardized way to integrate modules.
Whats your pros and cons for using an own connector?
Greets
Roman
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
