Carsten Ziegeler wrote: > Giacomo Pati wrote: > > >> Will this enable to try to store something like "abc" into a integer >> widget/model (which obviously would raise an Exception). If this would >> be possible I would certainly be against allowing >> unvalidated/invalid-state saves. >> > I don't know :) I guess it depends, if your model is using an int, I > guess you will get an exception. But if your form model is using an int > datatype but your data model is using a string (for whatever reason) > this might work. It also might work if you're binding to xml. But all > these are just guesses. > > Now, we could argue that if someone explicitly calls save() he should > have ensured beforehand that his data is valid. >
+1. CForms makes sure in all places that any data returned to the application to be valid, and returns null otherwise (with a validation error being set). This therefore completely shields the application from buggy data, which simplifies application development and avoids bugs and to some extend rogue data injection. However some people have some use cases where they want to be able to save a form in a "draft" state, even if it's invalid. In this context, "saving" should'nt considered IMO to be the same as the form's save operation, as the form data can be not only semantically invalid (i.e. validators fail), but also syntactically invalid (i.e. a "abc" for an integer). Invalid syntax means the form's binding more than likely to fail to save the form (invalid bean property types). Saving as draft therefore means saving the form values as plain text and restoring them as such, just as if they where read from the request. This is however not possible today because of the lack of the needed entry points in widgets. This can be solved though if people really needed with a couple of setStringValue()/getStringValue() methods. Sylvain -- Sylvain Wallez - http://bluxte.net
