New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Model and Web Forms #236
Comments
Ideally, model attributes and input field names should be decoupled, so do the so-called "form names". Theoretically, the decoupling could be done via an intermediate class (using some sort of name mapping) like you proposed. Practically, the introduction of this additional class would confuse users and unnecessarily complicate the whole thing. So we are taking the practical approach by directly using attribute names as input names and model class names as the prefixes. In some uncommon cases when you want to use "hide" the class name and the attribute names from end users, you can do so by using I don't see many drawbacks of having |
Can't you move the |
@yjeroen What if you have 10 view files? |
Speaking about coupling, why do not move method “populate” from the controller to the model? |
Form name can not belong to the widget. It is necessary for the data retrieve from GET or POST. |
The |
Vote against moving
A litte heavier??? No, it not only looks horrible it's also terribly impractical and long-winded. |
Why? As far as we have "yii\base\Model::getFormName()", moving populate() inside the model looks logical.
I can see nothing horrible in my approach: it creates an entity, which represents the web form abstracting from model (or models) behind it inside the view. We are using Data Providers for the listings, why can not we use some providers for the forms? |
Just compare usage on examples. Just compare. We always have controller instance and
There is nothing horrible in approach, it just looks horribe in practice usage. But in principle, as always when choosing academic VS practical. My IMHO that academic is complex overcoding frameworks choose. Like zf2, sf2. When practice is Yii way. |
Comparing: “populate” inside controller:
“populate” inside model:
I can not see benefit from the "Controller::populate" at this view. |
@klimov-paul In fact, I am now really with you to move |
One final word about initial proposal: To understand this issue and make a conclusion, you should decide what is “model”. For me “model” is an entity, which holds the application business logic and nothing more. Model should be universal. It should be usable for any type of view or controller. Model should be able to serve both web application and console application. I can’t see any purpose of “yii\base\Model::getFormName()” inside the console application. This method can serve only web application, web form, to be precise. That is why I do not like its presence there. My opinion: model should be stripped from web, stripped from any view. Only then it can be considered as model, otherwise it is something else. Yii model began to expand to controller layer once it introduced “safe/unsafe” attributes logic, deciding which data can be filled from web form and which is not. However, this feature still stays in a “grey” zone and can be considered as valid. P.S. as I have already said, while there is none around, who consider it can be good idea, perhaps I am wrong with this. |
One more word about “yii\base\Model::getFormName()”: method name “getFormName” sounds confusing. For me words “form name” associates with “<form name=”form-name”>”.
|
Talking about forms and populate values, here an excerpt of symfony controller doing the same thing:
So the form populates itself...wich feels more "natural" in my opinion... |
Using an intermidiate to populate model attributes from GET/POST is a good idea from the arhitectural point of view. Practically, I don't see the benefit of doing so. Why? Code will just get bloated and heavier, not straight forward as it is now. You see, the idea behind Yii in the first place was the balance between architecture, design of the framework and real world everyday usage. As far as I'm concerned at this point, if you really need that kind of complexity, that your model data population needs an intermidiate to do that - just hop to Symphony/Zend Framework, Yii doesn't seems as a good choise at that point. My 0.02$. |
Actually, I have a related question - what about handling multiple models in a single code? I have a page, where I handle data for 4 different models from the same form. Right now that code is repetative and you have to populate each model by hands. |
Proposal discarded. |
@psihius check |
This issue has been exposed at #213. Also similar problem was discussed for the Yii 1.1.x at yiisoft/yii#470.
Current Yii2 approach for the web forms breaks an MVC: it allows the model to specify its form name on its own.
“yii\base\Model::formName()” generates the key, which is used to create name for the form inputs and for the submitted data retrieval from “GET” or “POST”. You can call me paranoid, “holy var man” or else, but such functionality does NOT belong to the model layer in the MVC!
Although current implementation may seems harmless, it may (and, I think, will someday) lead to the problems, which do not reveal themselves at common situation.
First suggestion, which comes to my mind: introducing another class, which represents the web form at controller layer. Possible names are “web\Form”, “web\ModelHandler” etc. Such class can serve as wrapper around the model and should have methods “formName()” (currently - “yii\base\Model::formName()”) and “populate()” (currently – “yii\base\Controller”).
This class may perform:
– data sanitizing (like removing leading or trailing spaces)
– ensuring value collection from “difficult” HTML inputs, like “checkbox”, without any HTML hacks
– perform data format conversion from the model data format to the view data format (useful for the date/datetime inputs)
Possible controller code:
“ActiveForm” widget can work with the model handler, just like “CListView” worked with data providers back in Yii 1.1.x.
Possible view code:
The approach I have proposed here is more flexible, although I admit it is a little heavier than the current one.
The text was updated successfully, but these errors were encountered: