Hi Dave, sorry - missed a point in your mail.
"there are many 'disallowed' classes that contain methods that could still be considered part of the public API." That is exactly the sort of thing I meant with "tweaking the process". Maybe we could set up a suggest list for methods in "do-not-extend"-classes that could be considered part of the public API? All the best, Ina Am 8/27/14 1:07 PM schrieb "Ina El-Kadhi" unter <ina.el-ka...@oxid-esales.com>: >Hi Dave, > >glad u sort of like the idea :) > >As to the enforcing - we did not just want to plonk draconian measures >onto everyone - spontaneously switching from "u can do everything" to "u >must not ever do this thing" > >There is the wiki and core classes are marked in the header - we would >first like to see how far we get with these gentle reminders. > >All the best, >Ina > > > > > > > >Am 8/27/14 12:14 PM schrieb "Dave Holloway" unter <li...@dajoho.com>: > >>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. >>>g >>>eneral >>> >>> >>> _______________________________________________ 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 > _______________________________________________ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
