Grouping in CModel::rules

The rules are currently grouped by validator:




array(

  array('field1, field2', 'required'),

  array('field1', 'email'),

)



  1. Would it be better if separated?



array(

  array('field1', 'required'),

  array('field1', 'email'),

  array('field2', 'required'),

)



  1. Or grouped by field (this would actually need more arrays)?



array(

  array('field1', array('required', 'email')),

  array('field2', array('required')),

)



  1. Or grouped by scenario, then separated like (1)?



array(

  '*' => array(

    array('field1', 'required'),

    array('field1', 'email'),

    array('field2', 'required'),

  ),

)



  1. Or grouped by scenario, then grouped by field like (2)?



array(

  '*' => array(

    array('field1', array('required', 'email')),

    array('field2', array('required')),

  ),

)



Or is it good as it is? Please leave your opinion.

I’d prefer it more granular, like the version 3.

The reason is because it is easier to manipulate the rules when you extend the model.

It is also better to reuse and override rules when merging the arrays for the scenarios.

Also, see this related thread.

Both first and third versions could be implemented without any problems at the same time. Detection of the used way of rules declaration may be performed by checking whether array keys are numeric or not (cheap operation). In other words non-numeric keys means that scenario grouping is used.

First way is good for simple rules set where scenarios is not needed. I think there is no need to drop it.

qiang, samdark, mdomba: what do you think about implementation of this feature (scenario grouping based on arrays) in the upcoming 1.1.11 release? Is it worth it to work on it? :)

No, I don’t think we should change the current implementation .

1). This is already supported by the current implementation.

2). This is bad because we may need to configure each individual rule.

3). Using the current implementation, you can achieve similar effect by arranging the rules and putting rules of the same scenario in different code blocks.

4). The format is too complex to be useful.

Since rules() is a function, there are many advanced ways to organize your rules if there are many. For example, you can write a function which returns the rules of a particular scenario. Then in the child class, you can override this function alone.