Documentation, models and magic getters

Question

Documentation, models and magic getters

s0m30n3 May '14

Created May '14	Last Reply May '14	Replies 1	Views 1031	Votes 0

s0m30n3 1.1k

May '14

Hi everyone,

I've read carefully https://docs.phalcon.io/en/latest/reference/models.html and in the 'Public properties vs. Setters/Getters' section, there's the following sentence : "The ORM is compatible with both schemes of defining properties.".

So I tried making the properties of my class private and added the corresponding (public) getters. So for instance, there's "private $fullName;" and "public function getFullName() { return $this->fullName; }" in my class. To be complete, I call ::find() in the controller followed by $this->view->setVar and finally in the .phtml, I use $p->fullName;

My first discovery is that $p->fullName don't call automagically getFullName (" Access to undefined property ..."). So I had to call it manually : $p->getFullName() And then I found that $this->fullName was failing inside getFullName ("Undefined variable: fullName"). From a pure class point of view, this should be valid but I guess it's caused by "extends \Phalcon\Mvc\Controller". So I changed my properties from private to protected and then $this->fullName was accessible.

Reading php docs, I discovered I had to implement/override magic isset and get functions if I really wanted to have my variable private but then, phalcon is not automating things anymore as I have to manually code everything..

So obviously, either phalcon has to evolve or the docs has to be updated .. only if I'm right of course.

Thanks for reading ^^

Tomasz Ślązok · Answer 1 · 2014-05-11T06:40:58-07:00

Phalcon ORM works fine. If I'm right magic getters and setters in Phalcon ORM are only for relations not propertie.

If you are making properties private and even write getFullName() method than you must use getFullName() method instead of fullName property.

In my opinion making private property and trying using it from outside is not good idea. You can't write interface with properties. This way you write code that depends on implementation, not abstraction.