I’m finally beginning to understand Yii bit by bit, but there still is something I don’t get what starts to irritate me.
While trying to understand the difference between CFormModel and CActiveRecord, which I don’t see, I’ve been playing around with some login and register examples. Right now I have 3 models, a LoginForm (CFormModel) from the Yii guide, a RegisterForm (CActiveRecord) and a User (CActiveRecord) model generated by Gii. If I understand it right, I can combine LoginForm and RegisterForm within the User model by using scenarios so there is only one model for all handlings. But what is just the best approach? Especially when being in a very large project…?
And why there actually is a difference between CFormModel and CActiveRecord if you can do the same with both (if I’m right). I’ve read something like one can only validate and the other can also save?
I’m very thankful to the one who can explain me the logic behind these beasts. Or someone can just post an example of the best model file structure/tree for common user related actions such as Login, Register, Forget password, Profile etc. which could help me understand everything a little better.
Logic is simple - if you need to save data to database - use AR model, in all other cases - Form.
So you can easy combine register model and user model, because register - it’s saving new user to database.
For login you need to validate incoming data only, no any save here. Sure, you can combine it with User model too and verify using scenario, but for me using separate Form model look more understandable.
Lot of other cases for use Form model. For example, for working with files, remote data, images etc.
So i’m using the following structure:
Form model for login as in default Yii’s application
User AR model for register
Profile AR model - profile model can be joined with User model, but in mine case I have very big profile table with lots of fields so i’m split it.
Forget password havn’t implement yet but it will be Form model (may be same as for Login, may be separate - idk yet)
Big thanks for the replies, I understand the best way now I think. But why does the grbac extention make use of a separate ‘RegisterForm’ extending the CActiveRecord class while there is another ‘User’ extending the CActiveRecord class? Wasn’t it better to combine these with using the scenario options? Did the developer have a reason for that? Just to be curious
So if I combine register with the User model, then also fields like ‘Password/EmailConfirm’ and ‘Terms of Service Agreement’ are also going with the User model which actually are not present in the User database table, which you won’t use on other pages than Register, but that’s ok right?.
And also, won’t the User model become a bit messy when I’m gonna add some other things others than register? I can imagine that the User model can become very long and inconvenient when you put every User related stuff in there (which saves to the User database)?
Sorry for all these small questions, but I just want to understand everything in detail and get the logic behind it before I’m gonna start scripting. If I don’t understand something, then I’ve got the feeling that I’m losing control about that relevant part… Also I want to do everything perfect in one time and don’t want to do it all over again because I used a wrong model structure for example.
May be only few validation rules. Can’t see other code duplication.
For someone it’s ok, for someone - no. Sometimes it’s look strange if model start to validate other data. By mine mind in clean MVC model must verify only own data. Comparing passwords and emails for register - it’s controller logic. I think thats why some people use Form model for verify additional fields and after it move data to AR model for save. Yii’s scenario in models give you nice way to move some non-models checks to model because it’s look more easy: less code, less classes, errors in one point.
Well, it’s like to build building. You can get lot of true theory but without practice you can’t do all perfect. Sometimes no ‘must be’ solutions, so you can find own way.