Hi Ina, I actually like the idea and understand why it is necessary to increase shop stability. However, I feel that this needs to be enforced at a core level instead of just being mentioned in a wiki. i.e. OXID/PHP should *prevent* a module from loading if it touches part of the private API. Otherwise, you're still going to get a load of crackpots like me wildly extending things without checking/caring about the wiki.
But, at the moment, there are many 'disallowed' classes that contain methods that could still be considered part of the public API. Would it not be a better idea to block *some* specific methods instead of blocking specific classes? Maybe you could just mark them as final if they shouldn't be extended? http://php.net/manual/de/language.oop5.final.php Regards Dave On Wed, Aug 27, 2014 at 11:34 AM, Ina El-Kadhi <ina.el-ka...@oxid-esales.com> wrote: > Hi Joscha, > > thanks very much for your feedback. > > I am answering directly because this is for us a very important issue. > > It could be argued that there are two types of classes in the OXID core – > classes that make sure that the OXID framework works and classes that either > provide functionality or hooks for enhancing functionality. > > In order to minimise risks to project application stability, it is important > that in principle everything to do with the framework is not endangered by > using any extraneous code, which changes framework behaviour, as it is then > not guaranteed that the application as a whole still works. > > On top of that, with the previous procedure, it was sometimes impossible to > fix framework bugs in patches, as according to OXID versioning semantics, > these bug fixes would have constituted BC breaks because in principle all > code is part of the public interface. This meant either hot fixes (which may > lead to versioning problems during shop updates) or leaving known bugs > unfixed for a longer period of time. > > Coming up with the list of classes that should not be overwritten was our > first answer for solving these issues. > > Having said that, it might of course necessary to tweak the new process a > little – e.g. change the granularity of stuff that should not be overwritten > etc. We don't want to make life harder but rather the opposite :) > But in order to be able to do that, we need information. As you pointed out, > we don't know in detail what problems all the different agencies with their > totally different projects face in project implementation – we need to be > told. > > Looking forward to further input, > all the best, > ina > > Ina El-Kadhi > Head of Development eShop Platform > > ina.el-ka...@oxid-esales.com > Fon +49 761 36889-188 > Fax +49 761 36889-29 > Mobile +49 151 1423 3099 > www.oxid-esales.com > > > OXID eSales AG > Bertoldstraße 48 > 79098 Freiburg > Deutschland > > Vorstand: Roland Fesenmayr (Vorsitzender), Andrea Seeger > Vorsitzender des Aufsichtsrats: Michael Schlenk, Sitz: Freiburg > Amtsgericht Freiburg i. Br., HRB 701648, USt-IdNr.: DE231450866 > > > Von: Joscha Krug | marmalade GmbH <k...@marmalade.de> > Antworten an: <dev-general@lists.oxidforge.org> > Datum: Wed, 27 Aug 2014 11:01:28 +0200 > An: <dev-general@lists.oxidforge.org> > Betreff: Re: [oxid-dev-general] Core OXID eShop classes: must not be > extended > > Hi Linas, > > we hav an very important module that will be released open source in the > next week. > With that module it will finally be possible to version module settings in a > project. > > It has to extend oxUtilsObject which has an own loop to ensure that it is > overloadable. > > So we take your note very serious, but in some points you can't imagigine > what makes problems in projects and what we as an agency had to do to fix / > solve that. > > I will keep you updated! :-) > > Best regards, > > Joscha > > //--------- > > Joscha Krug > marmalade GmbH > > www.marmalade.de > k...@marmalade.de > > Leibnizstr.25 > 39104 Magdeburg > GERMANY > > phone: +49 (0) 391 / 559 22 104 > fax: +49 (0) 391 / 559 22 106 > Am 25.08.2014 14:54, schrieb Linas Kukulskis: > > Hi, all > > Not all classes of the OXID eShop are part of the public interface (public > API). > > Some classes offer core OXID framework functionality, which ensure that the > OXID eShop (including extensions that have been written according to our > guidelines) work as expected. Extending these core classes in modules or in > individual eShop customizations therefore engenders the risk of breaking > core functionality. > > As these classes are not part of the public OXID API, they may be changed in > patches and are not part of the deprecation procedure. > > Please ensure that none of your modules or customizations extend any of > these classes. > > A list of the classes and how they are marked in code may be found: > http://wiki.oxidforge.org/Tutorials/Core_OXID_eShop_classes:_must_not_be_extended > > Linas Kukulskis > Software Developer > > linas.kukuls...@oxid-esales.com > Fon +49 761 36889-0 > Fax +49 761 36889-29 > www.oxid-esales.com > > OXID eSales AG > Bertoldstraße 48 > 79098 Freiburg > Deutschland > > Vorstand: Roland Fesenmayr (Vorsitzender), Andrea Seeger > Vorsitzender des Aufsichtsrats: Michael Schlenk, Sitz: Freiburg > Amtsgericht Freiburg i. Br., HRB 701648, USt-IdNr.: DE231450866 > > > > _______________________________________________ > dev-general mailing list > dev-general@lists.oxidforge.orghttp://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 > > _______________________________________________ > 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
