Improvement on models
Posted 16 May 2009 - 05:30 PM
If the default will be "save if it has a rule", then we'll have to have a way in the rule to make it unsafe.
Personally i wouldn't like it to be safe automatically if it had a rule.
Posted 16 May 2009 - 05:42 PM
What I was proposing in the first place is for attributes to be considered safe if they are set to be required
Posted 16 May 2009 - 05:56 PM
* PK: we seldom list it in validation rules unless PK is something to be entered by user. In this case, having a rule does mean it is safe to be massively assigned.
* FK: some should be set by user input (e.g. post category), some set in the program (e.g. post author). For the former, we should have a rule to ensure the category is set correctly. For the latter, no rule is needed because it doesn't come from user input. In both cases, our initial rule still works.
* security-related attributes: the analysis is similar to FK.
As you can see, in all these cases, we don't really care if the rule is required or not.
Posted 17 May 2009 - 07:32 AM
That would mean that you can't set rules for attributes that you deem unsafe.
Which means that you have to trust your co-workers and those 'authorized' people to put correct data in, because it can't be validated (with rules).
For an example: Let's say an attributed called 'securityLevel'. You want to make sure it's integer between 1 and 5. You can't make a rule for it, since you don't want public users to be able to assign in when creating User instance. So you have no way of enforcing data integrity in the database, unless you write your own validation outside the rules().
But if that's the way it will be implemented, can we at least be able to mark the rule 'unsafe' - so we can still make a rule even for those unsafe attributes.
Posted 17 May 2009 - 08:08 AM
Posted 17 May 2009 - 11:05 AM
This way I don't have to assign the email rule to the email attribute for every scenario that uses it
But with this new implementation now it will always be considered 'safe' if I do this technique
So that should be considered
Posted 17 May 2009 - 12:08 PM
Otherwise, a distressing security hole would be present.
Can I suggest not to implement these validating rules via methods, but public properties. I've seen numerous methods returning arrays and string that can be stored in class properties. This shouldn't be a performance consideration, but semantically, using methods to store data is wrong, I guess. Am I right?
Posted 17 May 2009 - 04:23 PM
@pestaa: the reason to use method to return rules is to allow dynamic customization. For example, you may want to use Yii::t() to customize the error message. This is not possible with public properties.
Posted 17 May 2009 - 04:56 PM
that was just an example. There could be some cases where you do not want an email attribute massively assigned though
Posted 18 May 2009 - 06:18 AM
You are totally right. I wasn't familiar with this limitation.
What about declaring these arrays in the constructor and storing them in public properties anyway? I wanted to stick to semantically correct ways, so here's my golden path.
In this case, discussion about merging methods (which can be confusing in the end because of endless configuration possibilities) won't be necessary, since the data is in the properties. (Simplifying their declaration may be still needed, though.)
Posted 26 May 2009 - 09:34 AM
- Remove safeAttributes() and use validation rules to decide whether an attribute is safe or not.
- Add 'safe' and 'unsafe' validators.
Additionally, I removed the $scenario parameter from all methods requiring it. Instead, we use $model->scenario to decide what the current scenario is. This makes the APIs much cleaner and more consistent.
We will keep attributeLabels() as is.
Please let me know if you find any problems with these new implementations. The code is in trunk (not 1.0 branch).
Posted 30 May 2009 - 07:12 AM
What's the difference between applying unsafe validator and not applying any safe/unsafe validators at all? Why not assume that all fields are unsafe unless explicitly marked as safe? Or do they already have a default behavior?
Posted 30 May 2009 - 07:31 AM
- An attribute is safe if it is associated with a validation rule for the current scenario.
- An exception is that if the associated validation rule is 'unsafe', the attribute is unsafe.