Dear Core-Team.
I really like the way that I am able to extend OXID with modules,
inherit templates, etc. This is what sets OXID apart from other shop
solutions.
But this module handling can become quite frustrating, time consuming
and annoying.
Even the slightest mistake can break the complete shop and it can take
forever to get it working again.
This makes working in teams so much harder than it should be since most
of the devs really do use helpers.
Think: 10 Devs, GIT and one QA-Department that moved one or more modules
to a different folder because of the "better" name --> endless work
after pull!
Think: a complicated module with an error in something "essential" like
"noticelist" --> module disabled and complete shop gone.
I just dont want to end up having to add a module for each and every
function I add.
It might sound exaggerated but I hope you get the point.
So: +1 to Joscha's Mail ... should rather be a +100 :)
Best Regards,
Christian
Am 20.01.2013 23:18, schrieb Joscha Krug | marmalade.de:
Dear OXID Core-Team,
now we've used the new module system in many projects.
It makes activating and deactivating in most cases very easy.
But it gets very hard sometimes, like when modules deactivate
themselves or you get those strange red bars in the backend.
What are my thoughts about all that:
I think the metadata.php helps a lot and is the right place for the
base configuration. Great job!
What i don't like is that the ModuleID must be exactly the module
path. This is simply redundant.
Either you want to have the module path,then we should not set it
again OR it is an own key like a module-identifier that is unique in
the OXID world (maybe there could be a central repository where you
could register new ones) - which i think is the right way.
After that, you store someof the metadata informations in the
database. Why? If you remove some of the classes, files,... your
module leads to those strange red entries as mentioned before. I think
you had good reasons to do so - could you explain them? Maybe we
together find another solution that is cleaner and doesn't need that
double-storeing thing.
Then, there is amissing featurein my opinion: Dependencies to other
modules. Could be an easy array, but would often help a lot.
And - i thinkthats the worst feature - there is that
self-deactivating: Is see your idea but i think it breaks more than it
helps.
We often develop modules (like many other agencies as well i guess)
that keep lots of helpers for one project. So in that module you have
an extension for oxarticle, for details, start, for the checkout,...
so now it comes to the point that something is broken in some special
cases let's say in the checkout for example. Now the shop deactivates
the module and baaaaaaammm oxarticle, details, start,... will also be
broken in ANY way!
Hope to start a fruitful and constructive discussion.
Best,
Joscha
--
//---------
Joscha Krug
marmalade.de e.K.
www.marmalade.de <http://www.marmalade.de/>
[email protected] <mailto:[email protected]>
Leibnizstr.25
39104 Magdeburg
GERMANY
phone: +49 (0) 391 / 559 22 104
fax: +49 (0) 391 / 559 22 106
-------------------------------------------------------------------------------------
Besuchen Sie das *eCommerceCamp 2013*
vom 15. bis 17. März an der Ernst-Abbe-Fachhochschule Jena
http://www.ecommerce-camp.de/
Am 15. März ist es soweit! Dann startet das erste deutsche
eCommerceCamp. Wir möchten Entwickler und Integratoren von Open-Source
Shopsystemen, wie z.B. Magento, OXID oder Shopware, sowie
Interessierte für ein Wochenende im Stil der Web 2.0 Barcamps
zusammenbringen. Damit wollen wir den Teilnehmern eine Plattform für
den informellen Austausch von Know-how und Erfahrungen bereitstellen.
Vorträge, Präsentationen, Workshops und Diskussionsrunden von und mit
den Teilnehmern bestimmen dabei das Tagesprogramm.
-------------------------------------------------------------------------------------
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
