?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
