Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.
Wow im so stupid. Been sub classing all to necessarily, just found this "PHP Pattern" in Zend_Form..
Just thought I'd share Been tying my head into knots over this stupid @$$ problem for longer than I'd like to publicly admit Now I can polymorphicly handle implicit as well as explicit APIs without resorting to "magic", or "reflection"
Haha I couldn't figure out how to refactor my controllers. Some models have fields that need to change at run-time, some have fields I can define on the model. I smelled a fat controller smell but couldn't figure it out, when the solution was so simple haha. Before I was subclassing my CRUD controller making template methods like:
It looks like all that code does is looks for setSomeProperty and invokes it using a variable-invocation, otherwise it's stores the values in a key-value pair array? I'm not clear what the use-case is.
class Example
{
private $_values = array();
public function setValue($key, $value)
{
$this->_values[$key] = $value;
}
public function getValue($key)
{
return isset($this->_values[$key])
? $this->_values[$key]
: null;
}
public function getExampleProperty()
{
return $this->getValue('exampleProperty');
}
}
That's the sort of thing I use for classes that contain collections of vales, such as a record from a database.
For instance in your skeleton framework you're using public properties for values in the data Mapper. Same concept, have you mappers call setOptions( array ) and have setOptions be defined in a model superclass, then each model can expose its interface independently of the mappers, as long as they implement the setOptions() method
Itll work for CRUD controllers, mappers ( data mappers ), etc..
Basically a "Foo" class might have setField( field, value ), where a "Bar" class may instead have setField( value ), if both implement setOptions they can accept a name / value array and be treated uniformly by the mappers. Previously I had to create a ComponentMapper that overrode a method that took an array of values and called each setter.. even though I knew about the reflective syntax of PHP method calling for some reason I didn't think to do this.
jshpro2 wrote:For instance in your skeleton framework you're using public properties for values in the data Mapper. Same concept, have you mappers call setOptions( array ) and have setOptions be defined in a model superclass, then each model can expose its interface independently of the mappers, as long as they implement the setOptions() method
The plan for the Skeleton Mappers is to allow you to map to a property, or to specifically named getter/setter methods, or to standard get(name)/set(name, value) methods.