Hi,
I started with a new wiki article.
In this article should be a list of all oxid-classes which not can be overloaded.
Please help to make the article complete.
I think it helps everybody, if he see, if a specific class is overloadable or not.
Hi,
actually this class can be overloaded, but not then it is extended. i mean if somebody uses
class A{}
class B extends A{}
you cannot overload class A if you want to new functionality would exist in class B.
In other words you can write module for class A and then in oxid it will call with oxNew(“A”) it will bring what you expected, but if in oxid there will be oxNew(“B”) you wont get you module code in that object.
this is the list of classes which is extended by some others:
oxAdminList
oxAdminDetails
oxAdminView
Object_Seo
dyn_interface
Shop_Config
Dynscreen
Efire
DynExportBase
GenImport_Main
Order_List
Article_List
User_List
oxView
oxSuperCfg
oxList
oxI18n
oxBase
oxERPBase
oxErpCsv
oxSession
oxSeoEncoder
Account
oxUBase
GuestBook
aList
Details
User
other classes that cannot be extended in no way as it is used in oxid with “new” constructor directly:
oxConfig
oxStart (in oxconfig::init)
oxExceptionToDisplay
oxConnectionException
oxLDAP
oxOpenIdDb
oxOpenIdHTTPFetcher
oxUtilsObject
oxSystemComponentException
Smarty
oxlist (in views/wrapping::getWrappingList and views/wrapping::getCardList)
oxSysRequirements
oxErpGenImport
oxField
oxStdClass
Thanks a lot. When I find time, I write it to the wiki.
BTW try to write in config.inc.php this for oxutilsobject :
$this->aModules = array(
‘oxutilsobject’ => ‘my_oxutilsobject’
);
it helps if some classes is called before the aModules variable is loaded from DB.
But also notice, this variable will be overwritten by DB variable, so you have to dublicate these special modules (didn’t have a list at the moment for what classes it needed, but some are: oxutils.* oxsession oxlang )
[QUOTE=wanis;33777]BTW try to write in config.inc.php this for oxutilsobject :
$this->aModules = array(
‘oxutilsobject’ => ‘my_oxutilsobject’
);
it helps if some classes is called before the aModules variable is loaded from DB.
But also notice, this variable will be overwritten by DB variable, so you have to dublicate these special modules (didn’t have a list at the moment for what classes it needed, but some are: oxutils.* oxsession oxlang )[/QUOTE]
Hey, this is cool. I don’t know for what, but I think in future I need.
Maybe its possible create a db-connection and preload this values…
[QUOTE=wanis;33777]BTW try to write in config.inc.php this for oxutilsobject :
$this->aModules = array(
‘oxutilsobject’ => ‘my_oxutilsobject’
);
it helps if some classes is called before the aModules variable is loaded from DB.
But also notice, this variable will be overwritten by DB variable, so you have to dublicate these special modules (didn’t have a list at the moment for what classes it needed, but some are: oxutils.* oxsession oxlang )[/QUOTE]
Ok, I found a more flexible solution for this behavior.
http://www.oxid-esales.com/forum/showthread.php?t=6604#post39644
Just put the code on the end of config.inc.php.
I made a module extending oxAdminDetails(e.g. moduleclass extends moduleclass_parent and oxadmindetails => moduleclass in admin). I found that I can call oxnew(‘module_class’) and then access methods of oxadmindetails as well as methods of moduleclass. So I would think that oxAdminDetails is extendable. Should it be deleted from this list List_of_not_overloadable_classes or am I wrong?
Hehe, of course you can overload any class which is not declared as final…
But there a lot of classes who are inherits oxadmindetails, this classes don’t have the changes of your modul.
http://docu.oxid-esales.com/CE/sourcecodedocumentation/4.4.3.30016/classox_admin_details.html
Inherited by Actions_Main, Adminguestbook_Main, Adminlinks_Main, Article_Attribute, Article_Crossselling, Article_Extend, Article_Main, Article_Overview, Article_Pictures, Article_Review, Article_Stock, Article_Userdef, Article_Variant, Attribute_Category, Attribute_Main, Category_Main, Category_Order, Category_Pictures, Category_Text, Content_Main, Country_Main, Delivery_Articles, Delivery_Main, Delivery_Users, DeliverySet_Main, DeliverySet_Payment, DeliverySet_Users, Discount_Articles, Discount_Main, Discount_Users, dyn_interface, DynExportBase, GenImport_Main, Language_Main, Manufacturer_Main, News_Main, News_Text, Newsletter_Main, Newsletter_Plain, Newsletter_Preview, Newsletter_Selection, Object_Seo, Order_Address, Order_Article, Order_Main, Order_Overview, Order_Package, Order_Remark, Payment_Country, Payment_Main, Payment_Overview, PriceAlarm_Mail, PriceAlarm_Main, SelectList_Main, Shop_Config, Shop_Main, Statistic_Main, Statistic_Service, sysreq_main, Tools_Main, User_Address, User_Article, User_Extend, User_Main, User_Overview, User_Payment, User_Remark, UserGroup_Main, Vendor_Main, VoucherSerie_Groups, and Wrapping_Main.
Ok, now I think I finaly got the point about that list of not overloadable classes. It is all about overloading a class that is extended by other classes. You will not get the module functions in the classes that extend from the base class. The module function will only be available in the base class and the module class but not in other classes that extend from the base class.
I was thinking about the explanation of wanis and did not got the point, because i thought that class B in this example meant the module class. Now I understand, that class B means an regular oxid child class of class A. And if you write a module for class A (e.g. myA extends A) the module code will not be available in class B.
I really stood on the tube … 
Thank you MBa for your explanations.
So, how can I then make a function in all views that is accessible from all templates with
[{$oView->getMyObject()}]
Theres no nice way. 
With (main)views you can do following
class myView extends myView_parent{}
Modules
start=>myView
cart=>myView
user => myView
details=>myView
...
… this is only, because there exists only one view of this for each request (eg. if start is called, (details, cart and user are [B]not[/B] called)).
I don’t like this way, because its a little confusing.
Otherwise, if you only need to work with public declared methods or variables from the views, you can write a smartyplugin or a other function and call this from template.
If you need privat or proteced things, the reflection-api
[ul]
[li]http://www.php.net/manual/en/reflectionproperty.setaccessible.php
[/li][li]http://www.php.net/manual/en/reflectionmethod.setaccessible.php
[/li][li]http://www.php.net/manual/en/reflectionmethod.invoke.php
[/li][/ul]
could be a funny solution.
But really, this is not designed for productive code, only for unit-testing… and this is a lot more confusing. I suggest you: [B]dont use it!![/B]