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
manuel.re...@mediaopt.de | 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: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Gernot Payer
Gesendet: Montag, 21. Januar 2013 11:28
An: dev-general@lists.oxidforge.org
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 <lehm...@unit-m.de>:
> 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/> k...@marmalade.de
> > <mailto:k...@marmalade.de>
> > 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
> > dev-general@lists.oxidforge.org
> > 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
pa...@shoptimax.de
http://www.shoptimax.de
*******************************************
_______________________________________________
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
_______________________________________________
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
