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: dev-general-boun...@lists.oxidforge.org [mailto:dev-general-boun...@lists.oxidforge.org] On Behalf Of Marco Steinhaeuser Sent: Mittwoch, 26. August 2015 14:11 To: dev-general@lists.oxidforge.org 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 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