Re: [oxid-dev-general] New blog post on planet: Overloading non-overloadable classes - don't!

2015-10-14 Thread Florian Engelhardt 
+1 on this :)

On Tue, 13 Oct 2015 11:43:34 +0200
"Frank Zunderer IT Beratung"  wrote:

> Hello all,
> 
> i would suggest to label oxshopcontrol "can be overloaded but
> oxwidgetcontrol extends it" like alist/details. Also i suggest to
> refactor oxwidgetcontrol into oxshopcontrol so it can be fully
> extended again. Are there any objections against this?
> 
> Regards,
> Frank Zunderer

-- 

Florian Engelhardt
Seidemann Web GmbH
Albstrasse 52
72764 Reutlingen
https://seidemann-web.com

eMail : f.engelha...@seidemann-web.com
Tel.  : +49 7121 - 69509 - 41
Fax   : +49 7121 - 69509 - 50

Eingetragen beim Amtsgericht Stuttgart HRB 749221,
Geschäftsführer Florian Engelhardt und Philipp Seidemann

___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

Re: [oxid-dev-general] New blog post on planet: Overloading non-overloadable classes - don't!

2015-10-13 Thread Frank Zunderer IT Beratung 
Hello all,

i would suggest to label oxshopcontrol "can be overloaded but oxwidgetcontrol 
extends it" like alist/details. Also i suggest to refactor oxwidgetcontrol into 
oxshopcontrol so it can be fully extended again. Are there any objections 
against this?

Regards,
Frank Zunderer



-Ursprüngliche Nachricht-
Von: dev-general-boun...@lists.oxidforge.org 
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Marco 
Steinhaeuser
Gesendet: Mittwoch, 26. August 2015 14:11
An: dev-general@lists.oxidforge.org
Betreff: [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

Re: [oxid-dev-general] New blog post on planet: Overloading non-overloadable classes - don't!

2015-09-04 Thread Keywan Ghadami 
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 

keywan.ghad...@oxid-esales.com
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: dev-general-boun...@lists.oxidforge.org 
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Mersiowsky, 
Daniel
Gesendet: Donnerstag, 27. August 2015 09:23
An: dev-general@lists.oxidforge.org
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: dev-general-boun...@lists.oxidforge.org 
[mailto:dev-general-boun...@lists.oxidforge.org] On Behalf Of Keywan Ghadami
Sent: Mittwoch, 26. August 2015 17:19
To: dev-general@lists.oxidforge.org
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 

keywan.ghad...@oxid-esales.com
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: dev-general-boun...@lists.oxidforge.org 
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Mersiowsky, 
Daniel
Gesendet: Mittwoch, 26. August 2015 15:28
An: dev-general@lists.oxidforge.org
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: dev-general-boun...@lists.oxidforge.org 
[mailto:dev-general-boun...@

Re: [oxid-dev-general] New blog post on planet: Overloading non-overloadable classes - don't!

2015-08-27 Thread Mersiowsky, Daniel 
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: dev-general-boun...@lists.oxidforge.org 
[mailto:dev-general-boun...@lists.oxidforge.org] On Behalf Of Keywan Ghadami
Sent: Mittwoch, 26. August 2015 17:19
To: dev-general@lists.oxidforge.org
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 

keywan.ghad...@oxid-esales.com
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: dev-general-boun...@lists.oxidforge.org 
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Mersiowsky, 
Daniel
Gesendet: Mittwoch, 26. August 2015 15:28
An: dev-general@lists.oxidforge.org
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: 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
___
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

Re: [oxid-dev-general] New blog post on planet: Overloading non-overloadable classes - don't!

2015-08-26 Thread Mersiowsky, Daniel 
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