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 <[email protected]>: >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 ><[email protected]> 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 >> >> [email protected] >> 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 <[email protected]> >> Antworten an: <[email protected]> >> Datum: Wed, 27 Aug 2014 11:01:28 +0200 >> An: <[email protected]> >> 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 >> [email protected] >> >> 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 >> >> [email protected] >> 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 >> >>[email protected]http://dir.gmane.org/gmane.comp.php.oxid.g >>eneral >> >> >> _______________________________________________ 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
