cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [CForms] Load/Save model events never send?
Date Fri, 07 Jul 2006 06:16:04 GMT
I removed the phase checks for load and save.


Sylvain Wallez wrote:
> 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

Carsten Ziegeler - Open Source Group, S&N AG

View raw message