It's good having someone to discuss with. We are not seeking approval from each other, but more about learning practical experiences and needs.
I actually thought about your new proposal about rules. I'm afraid the structure is getting too complex to be easily learned by users. Also, it doesn't save much (mainly saving the typing of 'on' option).
Yes I agree. Are you planning on implanting your "safeAttributes() with scenarios" idea? I think it would be much better than the way it works now.
And about the proposal about a different way of organizing rules - true, it does not necessarily save that much typing, but it helps me to visualize my rules better and to me it looks better organized. - just a thought
Yes, will implement it today. Please let me know if you have any suggestions.
For rule organization, you could simply separate them with a blank line with comments.
Maybe a dumb question, but what does that mean now in the end? 
The guide still has this example:
public function rules()
{
return array(
array('username, password', 'required'),
array('password', 'authenticate'),
array('rememberMe', 'safe'),
);
}
But if i understand right, the 'safe' validator was removed again. I also get an error when using it with both svn branches (1.0 and trunk). So we still have to go the safeAttributes() way, right?
Sorry, just fixed this. Yes, we still use safeAttributes. The difference is that you can specify scenarios inside safeAttributes (the default one doesn't need that).
Ok, thanks.
What about the list of attributes that are safe in every scenario? The guide says, i need to write them as comma separated string. But the default implementation returns an array, so i use this:
<?php
return array_merge( parent::safeAttributes(),array('otherattribute'));
Can i still add scenario name/value pairs here, if i need to further specify the scenario for specific attributes?
Yes, you certainly can add scenario name/value pairs.
I have not commented on this new fix yet, but I'd like to say it's working great qiang. I'm totally happy with the way it's implanted.
I did however extend getSafeAttributeNames() in my model so that it automagically finds the required fields and knows they are safe:
<?php
public function getSafeAttributeNames($scenario='') {
$safe = parent::getSafeAttributeNames($scenario);
foreach ($this->validators as $validator) {
if ((get_class($validator) != 'CRequiredValidator') || !$validator->applyTo($scenario)) continue;
$safe = array_merge($safe, $validator->attributes);
}
return array_unique($safe);
}
I understand it has to loop through all the validators however for this so I am still deciding whether I should keep this code. On the other hand I may turn it into a model behavior (if that's possible?) and submit it as an extension for others so use if they wish. It's just less typing for the developer, that's all. I have not found any flaws in this idea yet.
How would you implement this as a behavior? CActiveRecord already has behavior feature.
That's why I was asking, I'm not sure if you can override and extend inherited methods with a behavior as you can with normal class inheritance. I think probably not though, and I don't see how it would be possible…
I don't know how to achieve that. Currently behaviors can do the following:
provide methods that are not defined in CActiveRecord
respond to predefined events in CActiveRecord
It seems unless we are willing to modify every method of CActiveRecord to add behavior check…
That does seem like it would be the only solution, adding a behavior check in every method in every class. Something does not seem right about that though. I wonder if anyone else has any ideas.