Please don't drop the ERP classes. I use this mechanism for several proprietary customer interfaces
Thanks Chris J ________________________________ From: Rimvydas Paskevicius <[email protected]> To: [email protected] Sent: Tue, October 19, 2010 2:33:47 PM Subject: Re: [oxid-dev-general] oxerptype vs oxid-standard-classes ?Hello, Actually what you mentioned is true. Now csv import don't take care about all fields and field values. Lazy loading in admin is switched off so this is not a problem. We are going to improve/refactor csv import tool in future versions and drop usage of erp types and use standard oxid classes (or at least optimize erp types to make them more flexible) . We will search for best solution for that. Best regards, Rimvydas Paskevicius -------------------------------------------------- From: "dasGollum" <[email protected]> Sent: Thursday, October 14, 2010 3:15 PM To: <[email protected]> Subject: [oxid-dev-general] oxerptype vs oxid-standard-classes > Hi all, > > actual i'm looking in the oxerptype classes and for me this classes are a > little useless. > > Erptypes are for importing and exporting datas. > But really the existing core-classes (should) can do this as well. > > > > Let me discribe on example article: > > The different is, that the core-classes can only handle one language at > once. > There is a value $_blEmployMultilanguage in oxi18n (method > setEnableMultilang()) but child classes dont use this flag straight. > > Eg: In oxarticle oxlongdescription and oxtags (table oxartextends) are not > loaded in all languages. > > It's a little bit strange, longdiscription use this flag for saving, but > not > for loading. (oxarticle::setArticleLongDesc vs > oxarticle::getArticleLongDesc) > > > The Erptypes don't have a logic for calculated fields eg. oxvarcount, > oxvarstock, oxvarsomething... or nested sets for categorys. > And they have hardcoded fieldnames, so I think lazyloading fields don't > work > with erptype. I don't test it, but for me it looks like. > > So erptypes are really primitv and don't take care about all fields and > fieldvalues. > The mirroreffects are for me not unforeseeable. > > > > Also, if the childclasses of oxi18n use > straight '$_blEmployMultilanguage=false' you can load a existing object by > id, if not exisist, a new object will create. > You can set all values in all languages... with class-logic for special > fields. > You can save the object. > > In PHP it will look like this: > > $oArticle=oxNew( 'oxarticle' ); > $oArticle->setEnableMultilang(false);//work with all languages > $oArticle->load('articleId'); > $oArticle->getArticleLongDesc(); > $oArticle->oxarticle__oxtitle='title de'; > $oArticle->oxarticle__oxtitle_1='title en'; > $oArticle->oxarticle__oxlongdesc='longdesc de'; > $oArticle->oxarticle__oxlongdesc_1='longdesc en'; > $oArticle->save(); > > ...and you don't need any oxerptype class. > > My thinking is to reduce code and have a more flexible api for > importing/exporting datas. The mirroreffects, if exists, are dropped, too. > > > What youre thinking, is this a possibility for future versions? > > Regards, > Markus > > > _______________________________________________ > 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
