Hi Christopher, That's a good point addressed. Yes, you are right. To access any object property it would be better to use real getters and setters. During the refactoring we made sure there is no single public property left in any class. The "only" exception are data field properties. The reason they are left public are backward compatibility. It would require huge amount of work to get rid of table__field properties in templates, partner modules and eshop code itself. But overall it is glad to hear from partner developers that people are willing to change that, so in future I hope we can get rid of them also.
Another question is particular oxuser__oxcountry property. Actually it is deprecated property and you will not find it in oxuser table. In previous eShop versions we had full country name in oxuser table, but since we are using oxcountryid field and store countries in separate table there are no sense to have it in oxuser table anymore. Again it's left only for older templates. So there is no sense to set this field value either. Anyway, as people are confused about it and we started this discussion, probably it is a good time to remove this field at all. Regards Tomas Liubinas > -----Original Message----- > From: [email protected] [mailto:dev-general- > [email protected]] On Behalf Of Christopher Simon > Sent: Wednesday, August 05, 2009 8:17 PM > To: [email protected] > Subject: [oxid-dev-general] Bad behavior of the ORM > > Hi there, > > i've noticed that OXID uses magic-getters, but no magic-setters. I'll > explain the problem with an example: > > the field "oxuser__oxcountry" is retrieved by the __get function, if its > not already existing. But, if it's set once directly with an line like > this "$oUser->oxuser__oxcountry->value = 'test';" the magic getter remains > uncalled, because the property already exits on $oUser. > > Because of this behavior i had trouble with the efire paypal module. > Somewhere "oxuser__oxcountry" was set to an empty string (i didn't found > the spot yet), and therefore, Paypal recieved no Country and an error was > thrown. > > But there is some other misbehavior caused by this: If you once read > oxuser__oxcountry, the metho "getUserCountry()" sets user country directy > on this property. But if user countryId changes in the meantime, "$oUser- > >oxuser__oxcountry->value" will remain untouched because it never gets an > update. > > In general, working with object propertys directly is very very dirty. For > error prevention in OXID 4 the magic setters should be utilized as soon as > possible. But for OXID 5, i would like to see OXID to utilize real getters > and setters and retrieve values like this: > > $oUser->getCountryName() and set Values like this $oUser- > >setCountryName($value); > > This would be more OOP-Style, and more suitable for all module developers > out there, because the "getDatabaseField" methods could be extended, too. > > For dynamic field adding, you could use the "__call" magic method. > > _______________________________________________ > 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
