Dorneles Treméa-2 wrote:

Sure you do. Just don't do any writing prior to the validator or on the "failure" path after the validator.

Or, let the failure path of the validator call abort() explicitly.

We need to keep Archeytpes and CMFFormController separate. If Archetypes causing writes prior to the validator succeeding, then that's insane, and Archetypes must be fixed. That doesn't mean we should doom any and all transactions whenever any validator in any form controller chain dies, though.

I don't think we don't have a choice - see above.

I see your point from an Archetypes perspective. I don't think CMFFormController is the right place to put this, though - Archetypes is. Form page flow should be separate from transaction management, imho. I wouldn't expect a form page flow framework to irretrievably doom my transactions ever. That should be an explicit choice.

And as I said, in any sane formlib chain, this isn't an issue. You don't save (unless you wanted to!) before the validator has had a chance to validate.

I'm not sure I agree. And even if it's the most common use case. That is, I think in the vast majority of cases, this is a non-issue. Having an abort hardcoded in there would make it very hard to have cases where you wanted to save after a validator failure.

In fact, the way form controller work, we have the conventions "success" and "failure" as exit paths from a validator. However, IIRC you can use anything. "partial-success" maybe. In any case, it's a matter of flow design where you put your writes.

I don't think it's the Right Thing, or at least, it's not the Right Place. :)

Archetypes 1.5 has subscription-adapter based validation.

Not necessarily. A premature commit is bad, because if something later failed (a ConflictError, say) then you may end up with inconsistent state. If that's your only choice, then you're sacrificing integrity.

If you think about it, we use transaction.abort() very rarely in Zope and Plone. It's pretty drastic. Doing it in a form page flow framework feels completely wrong.

Yes. I'm still -1 on this change. (but +1 on fixing in Archetypes, or that widget, obviously). Aborting a transaction is a blunt and clunky instrument for fixing what should be an obvious programming error, and may stop people from doing legitimate things.

CMFFormController is the wrong place to take decisions about data integrity, and it's so easy to control this explicitly (don't write before validator/don't write on failure path) that I think anyone who does it (apart from Archetypes, apparently, which is buggy in this regard) probably meant to (in which case forcing them prematurely commit to pre-empt an abort - wtf?).

Martin