Hello Saulius, thanks for your reply.
Well a parameter to prevent modules from self-deactivation could be a solution. Although i'm pretty sure that you would find that in almost any installationsit will be turned off. ;-) > 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. A ok. That leads to problems in some of our installations. Iwill come back if i could reproduce that.Good to hear thatwe ot the id right. 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. ------------------------------------------------------------------------------------- Am 22.01.2013 10:53, schrieb Saulius Stasiukaitis: > > 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
_______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
