Comments on: Don’t change the meaning of parameters

By: cakebaker

cakebaker — Wed, 18 Mar 2009 16:11:13 +0000

@ADmad: Yes, that’s true. In the end it is probably a matter of preference which approach you use.

By: ADmad

ADmad — Tue, 17 Mar 2009 19:18:42 +0000

@cakebaker I am not mixing anymore than core already does. You can pass an options array as second param. I am just adding one more key to it.

By: cakebaker

cakebaker — Tue, 17 Mar 2009 16:46:38 +0000

@all: Thanks for your comments!

@Jonah: I think the problem of such an approach is that the parameters $whiteList and $blackList are mutually exclusive. You use either a whiteList or a blackList strategy, but not both. And having such a method signature doesn’t communicate this fact…

@teknoid: Yes, as long as it is not supported by the core, you have to find a workaround.

@Brandon: Yes, I fully agree with you.

@poLK: Yes, writing a behavior is a possible workaround.

@ADmad: Yes, that’s a possible workaround, however your solution still mixes responsibilities.

@Abba: Not me ;-)

By: Abba Bryant

Abba Bryant — Tue, 17 Mar 2009 15:20:33 +0000

Who is going to be first to write a full featured blacklistable behavior?

By: ADmad

ADmad — Mon, 16 Mar 2009 14:47:25 +0000


//$this->ModelName->save($data, array('blackList' => array('fieldA', 'fieldB')))

function save($data = null, $validate = true, $fieldList = array()) {
	if (is_array($validate) && isset($validate['blackList'])) {
		if(!empty($this->whitelist)) {
			$validate['fieldList'] = array_diff($this->whitelist, $validate['blackList']);
		} else {
			$validate['fieldList'] = array_diff(array_keys($this->schema()), $validate['blackList']);
		}
	}
	return parent::save($data, $validate, $fieldList);
}

By: poLK

poLK — Mon, 16 Mar 2009 05:55:15 +0000

I forgot to point out that Model::$whitelist is public property.

By: poLK

poLK — Mon, 16 Mar 2009 05:52:38 +0000


//$this->ModelName->save($data, array('blacklist' => array('fieldA', 'fieldB')))

class BlacklistBehavior extends ModelBehavior {
	public function beforeSave(&$Model, $options = array()) {
		debug($options);
	}
}

By: Brandon P

Brandon P — Mon, 16 Mar 2009 04:40:13 +0000

Sorry, but issues like this perplex me. Why do people want to change the functionality of core components? There is no way that a framework can cover every use-case scenario out there.

If a framework doesn’t provide built-in functionality for what you are trying to do, take the time and add it to AppModel or a utility class (making it reusable) that Daniel suggested rather than writing about how core components should be changed to meet your obscure needs.

Frameworks are general, made up of classes to help you solve common/everyday/redundant tasks. Don’t get surprised or frustrated when something doesn’t work out of the box. And please don’t waste your time trying to get a framework to work for you. Let it do what it’s designed to do. Any specific tasks you want, create your own functionality decoupled from the framework as much as possible so its highly reusable.

By: teknoid

teknoid — Sun, 15 Mar 2009 21:30:09 +0000

I absolutely agree that from a programmatic point of view one should not hack away at the designated parameter to make it behave as something else.

However, this functionality is desired in many cases (still IMO), and ultimately what Jonah proposed is the best approach. Yet, until it is supported by the core we are stuck with a some little hacks one way or another.

By: Jonah

Jonah — Sun, 15 Mar 2009 21:08:39 +0000

I don’t like any of these solutions.

Why not this signature:

save($data = null, $validate = true, $whiteList = false, $blackList = false)

You could use one, the other, or both even