basic but.... |
[eluser]nmweb[/eluser]
Models represent data, if a field is no longer needed the model will misrepresent the data and therefore the model should be adapted, together with its rules. Having validation in your model will give consistency to your data since all data that passes must be validated meaning your database/text files whatever will have validated data. Validating in the model without having rules in the model seems a weird compromise. Similar fieldnames is a convention, used in other frameworks as well. You can choose to abide it or not, it's not that important.
[eluser]xwero[/eluser]
If you have a table with a lot of fields chances are there is going to be more than one form that alters another slice of the fields. So if i understand you well you would create a method for each view in which case you couple the model methods to a certain view file making the methods less reusable? And what would you do with data that is required on one form but not on another or that has to match another field in on form and not on another? I think there a several scenario's where it's beneficial for the model code not to have the validation in the model methods but in a separate layer, like the Akelos solution if i'm not mistaken or in the controller. This is why i made the compromise.
[eluser]nmweb[/eluser]
Akelos Code: //controller When you have a table with a lot of fields and multiple forms to fill them, I don't see why the rules should therefore by stored in the controller. Each form field that is inserted into the db should be validated when an attempt to insertion is being made. The current CI_Validation falls short on that but that's no excuse to not do it. Sure you might have forms which are so complex that validation in the controller is easier, at this point you might want to retrieve the rules for the models concerned from the model. No I don't have methods for each view, if I would need to do that, my model would be designed wrongly. If data is required in one form and not in another it'll lead to inconsistencies in your data. If you have properly designed your model and its validation you shouldn't run into any problems and you'll find that it is much easier. You could always implement a save($validate=true) for exotic cases. I wrote a Form generation class which also does validation. I'm now writing something so I can pass my model (with rules) to that class and it'll generate a form of the fields I desire. The form generation class will also write my Javascript validation for usability purposes. To have this work properly I'll have to call the Form_generation->validate() method and may avoid calling the models validation methods. The validate() will check each form field against the rules retrieved from the model. This way I have to write my rules once and it'll validate my forms everywhere with nice error messages and even javascript validation. All the way from the model through the controller to the view I have perfect validating forms with only a few lines of code. It's proper OOP so I can always for example add an extra javascript rule for usability purposes such as an ajax-username-exists rule or if my model doesn't exactly map to my form I can add or remove fields from the form. I can override rules, messages, anything. Not validating in the model at all times, sure, you might want to do something like the above and forms don't always map to models. Not having rules in the model I find strange, try adding 300 characters to a varchar field and it'll trigger a crappy mysql error. Yet your controllers or views should have no knowledge of this limitation of varchar, it's the job of the model and using rules you can prevent 300chars from being added and trigger an error that is comprehensible for the user.
[eluser]xwero[/eluser]
If you put this in CI model code a method would look like this (in a primitive state) Code: function update_user($where,$custom_fieldnames = array(),$custom_val_rules = array())
[eluser]nmweb[/eluser]
You pass values to your model, your model should have no knowledge of $_POST nor should it do something with it. Your controller should give the model the values. (primitive state) Code: class Some_Model{ Now, what does the controller look like: Code: //controller To show how Django handles it and how I plan to handle it: Code: //bit of pseudo code Code: $form=new Email_Form(new Some_Model(10); //record number 10
[eluser]xwero[/eluser]
Nice nice. If i read it right you think there are 2 problems with the CI validation class - The $_POST[$field] should be replace with the actual string - and you shouldn't be able to do trim, xss_clean, ... I already noticed that from your validation library where you have a method to prepare the data. Another question how would you handle uploads? Also in the model or in the controller?
[eluser]nmweb[/eluser]
The CI validation class has several issues most of which can be solved by being more OO but it would involve a rewrite. For one think that a validation class should do what I expect it to do, namely validate and not assume that the page contains $_POST data or something. We should pass the data it should validate, for all I care I want to validate the data coming from the database once again. This means a simple Code: $validate=new Validation($_POST); //or $_GET or any array I think uploads should be handled by the model in that sense that you pass the $_FILES to a model and it should handle its storage. Ideally I would have an object representing the file Code: class Image_Model extends File_Model{} This would be my approach. I love OOP
[eluser]nmweb[/eluser]
To come back to the Form generation from the model: http://h1368840.stratoserver.net/2008/03...eneration/ It works neat as it is but needs some polishing. I hope to release something soon. |
Welcome Guest, Not a member yet? Register Sign In |