Hello Joscha, Nice to hear you like the way we lead our modules to. Discussion about module handling is very welcome as we can get information from real field what is hard to do while sitting mostly just near shop core. I’ll try to take your letter peace by peace and response to them.
But it gets very hard sometimes, like when modules deactivate themselves or you get those strange red bars in the backend. After that, you store some of 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. You probably talk about feature, when shop does not find module class. Instead of returning fatal error shop deactivate module and mark it with red bars. So it should be visible that module need to be checked for errors. We save to database because it is simple and comfortable solution to work with. Another solution would be scan file system on every load. This is much less effective performance and effort approach. And - i think thats 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! This is done to prevent from fatal errors. But from responses it looks that current solution isn’t the most effective. Maybe we could improve this place by: deactivate only corrupted class, not whole module. do not deactivate if parameter iDebug has value -1 add additional parameter that turn of auto deactivation. What is your opinion about those suggestions? Can you describe in which scenarios auto deactivation hurts most in developing process or in productive mode. 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. Module id must NOT be the same as module directory name as there is relationship between module id and module root directory saved in database. Furthermore as module id and module directory path must be unique we recommend using directory name and vendor directory name for module id. Then, there is a missing feature in my opinion: Dependencies to other modules. Could be an easy array, but would often help a lot. This suggestion is on our sight for some time. We found it very interesting as something we should implement. Before starting to develop we will discuss more how this feature should be implemented. Saulius Stasiukaitis OXID developer From: [email protected] [mailto:[email protected]] On Behalf Of Joscha Krug | marmalade.de Sent: Monday, January 21, 2013 12:19 AM To: [email protected] Subject: [oxid-dev-general] new module handling 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 some of 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 a missing feature in my opinion: Dependencies to other modules. Could be an easy array, but would often help a lot. And - i think thats 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
