I'm using FuelPHP's built-in ORM. My application has an emailer component. Basically it takes a \Model\User object and a \Model\Ticket object and renders a nice little email. The client has asked for email previews. This is easy if there is at least one ticket in the system for the current user, however, it falls flat on it's face if the user doesn't have any tickets yet.
My initial thought was that I could use mock data to create a fake ticket (without running the save() method on it). However, whenever I try to use one of my mock objects in my email body rendering method, I get a "Trying to get the property of a non-object" error. Running a var_dump() on the object, I can see that the _custom_data field is populated, but the _data array is not populated. I'm pretty sure the getter method for ORM models fetches data from the _data array, so it seems to me that the data from an object isn't available via the getter until the data is saved to the database, is that correct?
For example:
$data = array('name' => 'Ben');
$user = User::forge($data);
echo $user->name; // Error: trying to get property of a non-object
Is this the expected functionality or am I doing it wrong? How can I create mock objects that behave like objects populated with real data?
Assuming that User extends \Orm\Model, it requires a $_properties array that defines the column 'name'. If not, it will not be seen as a data property.
I just blindly followed the instructions, not really understanding the significance of "profile_fields". Right now, the user's name, title and phone number are stored in the profile_fields column. At some point, I thought "I should be able to access the user's profile fields with the object getter. For example:
$user->name // should return "Ben Harold" for my account
To handle this, I setup both "after_load" and "before_save" observer methods to unserialize and serialize the data, respectively. Judging from the amount of trouble this has caused me, I suspect it is not the ideal solution.
This brings up several questions:
1) What are the best practices for using the profile_fields column?
2) Should I migrate "name" from profile_fields to it's own column on the user table? Why or why not?
3) Am I missing an easier method of using profile_fields?
In case of Ormauth, the Auth package provides all required ORM modules. Ormauth also doesn't use the profile_fields column, it has a separate metadata table used as an EAV container, which means $object->name just works.
In case of Simpleauth, you need to create a model for it. Set the datatype to 'serialize', and use the Typing observer to automatically serialize/unserialize it. I have apps that do the same, no problem there. Observer_Typing must be defined on 'after_load', 'before_save' and 'after_save'.
But if you intend to use ORM, switching to Ormauth would be a better option, as it provides more features, and everything comes out of the box.
Both also have a generic getter, get(), which allows you to get properties from a user record. It works transparently on both table columns and profile_fields (or metadata).
Donate
