Hi Manuel, yes, that's a good way to do this manually and with pre-4.6.x versions it was the only way. But now that we have a real module configuration interface, it's about time that we developers get some advantage out of it. ;)
regards Gernot Am Tue, 22 Jan 2013 12:50:34 +0100 schrieb Manuel Reiß <[email protected]>: > Hi Gernot, > to keep module-dependencies inside tpls failsafe, we're currently > using following way: > > extend (e.g. oxcmp_utils) or create a component or oxViewConfig and > set a tpl-variable: > > public function render() > { > //activate module for templates > //you could also add some addional checks here as well... > $this->getParent()->_aViewData['my_module__isActive'] = true; > > return parent::render(); > } > > therefore your tpl-integration looks like this: > > [{if $my_module__isActive}] > [{ $oView->my_module__method() }] > [{/if}] > > your suggestion however, sounds much nicer indeed :) > > Best, > Manuel > > > [email protected] | www.mediaopt.de > > derksen mediaopt gmbh | elbestrasse 28/29 | 12045 berlin | +49 (30) > 34 09 42-77 | fax-66 | Amtsgericht Charlottenburg | HRB 120935 B | > ust.-id DE265886017 | geschäftsführer dipl.-ing. philipp derksen > > -----Ursprüngliche Nachricht----- > Von: [email protected] > [mailto:[email protected]] Im Auftrag von > Gernot Payer Gesendet: Montag, 21. Januar 2013 11:28 An: > [email protected] Betreff: Re: [oxid-dev-general] new > module handling > > Dear Core-Team, > > let me add one more thing as Joscha and Christian have already > covered most major points. > > Dependencies between modules and templates are not handled at all. > Yes, there is the "tpl blocks" feature which might work nicely for > defined changes to a standard template set. But the more common case > for agencies is to do a comlete redesign of a template set and to > change a lot of things. Many of those changes of course depend on > modules. > > So now a few (or all) modules deactivate themselves for one reason or > another and while the shop might still run, as soon as you hit a page > with module dependencies in its templates, you are screwed. > > How about something like this: > > [{oxdep module="mymodule"}] > [{ $oView->mymodule_method() }] > [{/oxdep}] > > If module "mymodule" was deactivated, oxdep would output something > like "<span>Module 'mymodule' not active</span>". > > Another bonus of this would be inline documentation, you can directly > see that this is no standard feature and in which module it is > located. > > regards > Gernot > > Am Mon, 21 Jan 2013 00:43:09 +0100 > schrieb Christian Lehmann <[email protected]>: > > > 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 > > > > > > -- > ******************************************* > Dipl.-Inf. Gernot Payer > Software-Entwickler > > shoptimax GmbH > Guntherstraße 45a > 90461 Nürnberg > Amtsgericht Nürnberg HRB 21703 > GF Friedrich Schreieck > > Tel.: 0911/25566-17 > Fax: 0911/25566-29 > [email protected] > http://www.shoptimax.de > ******************************************* > > _______________________________________________ > 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 -- ******************************************* Dipl.-Inf. Gernot Payer Software-Entwickler shoptimax GmbH Guntherstraße 45a 90461 Nürnberg Amtsgericht Nürnberg HRB 21703 GF Friedrich Schreieck Tel.: 0911/25566-17 Fax: 0911/25566-29 [email protected] http://www.shoptimax.de ******************************************* _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
