Hi Everyone, Hi Daniel I have been informed today, that there is simpler way to include an own autoloader in your module, simply by referencing that autoloader/bootstrap script in metadata.php, in the file section, as first entry.
Would be nice to read if someone have experience with that and if you can be sure that file is loaded automatically in every situation. Best regards Keywan Ghadami Software-Entwickler Professional Services [email protected] Fon +49 761 36889-235 Fax +49 761 36889-29 www.oxid-esales.com Koelnmesse, 16.-17.09.2015, Halle 8 / Stand A-060 Jetzt Termin vereinbaren OXID eSales AG Bertoldstraße 48 79098 Freiburg Deutschland Vorstand: Roland Fesenmayr (Vorsitzender), Dr. Marcus Klosterberg Vorsitzender des Aufsichtsrats: Michael Schlenk, Sitz: Büdingen Amtsgericht Freiburg i. Br., HRB 701648, USt-IdNr.: DE231450866 -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Mersiowsky, Daniel Gesendet: Donnerstag, 27. August 2015 09:23 An: [email protected] Betreff: Re: [oxid-dev-general] New blog post on planet: Overloading non-overloadable classes - don't! Hello Keywan, thank you very much for the insight! I'm going to switch to this solution. Still, I hope there will be "official" support someday, e.g. some kind of event to hook into. :) Regards, Daniel -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Keywan Ghadami Sent: Mittwoch, 26. August 2015 17:19 To: [email protected] Subject: Re: [oxid-dev-general] New blog post on planet: Overloading non-overloadable classes - don't! Hi Daniel, Instead of modifying functions.php , some modules require their individual bootstrap file in each and every class of that module (which is of cause not very DRY). Another way of interacting with the oxid autoloader and maybe also for bootstrapping. You can extend oxUtilsObject. oxUtilsObject is very handy to do all kind of 'alien' stuff because you can be sure, that it's being loaded as soon some code uses oxNew. But take care! It is also on the List of not overloadable classes even if it works well to extend it by modules in newer oxid versions. http://wiki.oxidforge.org/Tutorials/List_of_not_overloadable_classes#core.2F Anyway it's my preferred way to do all the cool 'alien' stuff. Keywan Ghadami Software-Entwickler Professional Services [email protected] Fon +49 761 36889-235 Fax +49 761 36889-29 www.oxid-esales.com Koelnmesse, 16.-17.09.2015, Halle 8 / Stand A-060 Jetzt Termin vereinbaren OXID eSales AG Bertoldstraße 48 79098 Freiburg Deutschland Vorstand: Roland Fesenmayr (Vorsitzender), Dr. Marcus Klosterberg Vorsitzender des Aufsichtsrats: Michael Schlenk, Sitz: Büdingen Amtsgericht Freiburg i. Br., HRB 701648, USt-IdNr.: DE231450866 -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Mersiowsky, Daniel Gesendet: Mittwoch, 26. August 2015 15:28 An: [email protected] Betreff: Re: [oxid-dev-general] New blog post on planet: Overloading non-overloadable classes - don't! Hi Everyone, I knew this wasn't a good practice, but I wonder how I'm going to adapt module-dependent bootstrap functionality in the future. Example: I'm using a custom Autoloader for registering namespaces at runtime. Every module adds its own namespace by extending oxShopControl::__construct (and oxWidgetControl), calling something like "MyAutoloader::addNamespace(/*module namespace and root folder*/);" Another example would be a custom error handler (e.g. for sending errors on-the-fly via e-mail - I won't describe my solution here since it required lots of not-so-beautiful workarounds). Yes, I know this is kind of alien, and I know there are off-the-shelf solutions like composer's autoloader to solve this particular problem. But, in general, triggering all kinds of events on System startup should be possible in a somehow elegant way. So, here's the question: Is there a possibility to add module-dependent "bootstrap" functionality? I don't want to mess around in functions.php (adding/removing lines on module de/activation, or something worse). If there isn't, do you think it's a considerable new feature for future releases? You could, for instance, simply add a new event type to module metadata. Cleaning up control flows in the application is always nice and appreciated, but removing (or as in this case simply disallowing) features without giving any alternative probably isn't the best way to satisfy the developer community. Looking forward to discuss your ideas! Regards, Daniel -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Marco Steinhaeuser Sent: Mittwoch, 26. August 2015 14:11 To: [email protected] Subject: [oxid-dev-general] New blog post on planet: Overloading non-overloadable classes - don't! Hey folks, did you use oxShopControl in modules yet? Well, it was moved to non-overloadable classes recently. Please read this blog post to find a workaround. All others: hands off these classes http://planet.oxidforge.org/2015/08/overloading-non-overloadable-classes-dont.html Cheers Marco _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
