37 messages in net.sourceforge.lists.plone-developersRe: CMFFormController should abort th...
FromSent OnAttachments
Dorneles TreméaNov 9, 2007 3:17 pm 
Philipp von WeitershausenNov 10, 2007 7:07 am 
Dorneles TreméaNov 10, 2007 7:58 am 
Wichert AkkermanNov 10, 2007 12:22 pm 
Martin AspeliNov 10, 2007 2:12 pm 
Wichert AkkermanNov 10, 2007 4:20 pm 
Philipp von WeitershausenNov 11, 2007 1:32 am 
Dorneles TreméaNov 11, 2007 5:19 pm 
Alan RunyanNov 11, 2007 5:20 pm 
Martin AspeliNov 11, 2007 5:44 pm 
Martin AspeliNov 11, 2007 5:51 pm 
Wichert AkkermanNov 12, 2007 4:37 am 
Sidnei da SilvaNov 12, 2007 4:43 am 
Daniel KraftNov 12, 2007 5:40 am 
Martin AspeliNov 12, 2007 5:52 am 
Dorneles TreméaNov 12, 2007 9:35 am 
Wichert AkkermanNov 12, 2007 9:56 am 
Martin AspeliNov 12, 2007 9:59 am 
Martin AspeliNov 12, 2007 10:00 am 
Dorneles TreméaNov 12, 2007 10:56 am 
Martin AspeliNov 12, 2007 11:14 am 
Martin AspeliNov 12, 2007 11:21 am 
Wichert AkkermanNov 12, 2007 11:36 am 
Martin AspeliNov 12, 2007 11:41 am 
Sidnei da SilvaNov 12, 2007 11:47 am 
Martin AspeliNov 12, 2007 12:04 pm 
Dorneles TreméaNov 12, 2007 12:28 pm 
Dorneles TreméaNov 12, 2007 12:34 pm 
Dorneles TreméaNov 12, 2007 1:29 pm 
Wichert AkkermanNov 12, 2007 1:32 pm 
Martin AspeliNov 12, 2007 1:41 pm 
Dorneles TreméaNov 12, 2007 1:44 pm 
Martin AspeliNov 12, 2007 1:46 pm 
Wichert AkkermanNov 12, 2007 1:46 pm 
Martin AspeliNov 12, 2007 1:47 pm 
Dorneles TreméaNov 12, 2007 5:11 pm 
Daniel NouriNov 13, 2007 4:14 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: CMFFormController should abort the current transaction when the validation failsActions...
From:Dorneles Treméa (deo-@public.gmane.org)
Date:Nov 12, 2007 12:28:32 pm
List:net.sourceforge.lists.plone-developers

Hey Martin,

We're conflating Archetypes' possibly-broken validation machinery with CMFFormController's general page flow mechanisms here.

Archetypes is far from the only user of CMFFormController! :)

I know, and I already said this earlier. Anyway, the 'form processing' principle is the same, independent on what products are involved...

Follow the path with me:

- You press the 'Save' button in the Archetypes form edit screen

Check.

- That form edit screen is a ControllerPageTemplate (base_edit.cpt) with validate_base.vpy as the unique validator

Check.

- validate_base.vpy calls BaseObject.validate() to check for errors

Check.

- BaseObject.validate() calls BasicSchema.validate() which in turn calls widget.process_form() for all fields

Check. Except process_form should never write anything persistent, right. It it does, then this process is broken - you're writing when the form may be invalid!

It's easy to say something is broken, huh? :-)

I'd say that writing persistent things while at validation is a perfectly valid use case, and then the fact that it does not roll those changes back when the validation fails is what is broken...

But discussing the sex of angels is not that useful, so let's proceed... :-)

- We have a ReferenceField which uses a special reference widget, UploadReferenceWidget, which was designed to be a simple replacement for the default ReferenceWidget

Ok.

- That widget receives a FileUpload object via REQUEST, proceeds with a 'File' creation and only returns its UID as the widget value

This is nuts.

You're creating objects during validation. This needs to happen somewhere *after* the validation has succeeded (e.g. in an event handler such as IObjectSaved or whatever it's called in AT). That's what validation means - you're deciding if the request is valid before proceeding.

Ok, I agree with you. Indeed, you just gave me an additional idea!

I discovered (and you pointed out) that the widget.process_form() is called from two places:

- some point inside BaseObject.validation()

- some point inside BaseObject.processForm()

This means I can postpone the object creation until the second call.

It would be great if Archetypes pass an additional keyword to the widget.process_form() call saying that it's in the 'validating' or the 'processing' phase... otherwise we'll need to mess with the REQUEST and set some kind of flag...

What do you think about this additional keyword? Do I have your +1 here?

- Now that there's already a File in ZODB, the validation of another field fails, let's say 'title' was required but nothing was passed

Right.

- At this point the validation failed and you're back to the edit form screen with no chance to abort the transaction

Right.

Do you see the problem?

Yes. Your widget is broken. :)

:-P

The point is: the only place where you can do additional stuff without changing any default Archetypes/CMFFormController settings is in the widget process_form() call, while at validation phase.

What happens if validation succeeds? Doesn't it go through and process the form again to save properly?

Yep, thanks for the pointer!

I'm still strongly arguing that CMFFormController would be the best place to have this fixed, but I can live with a change on Archetypes.

And I'm still strongly arguing that it's the wrong level of abstraction and far too blunt a change.

I'm not that convinced yet, but you enlightened me... and so I'll stop trying to convince the world... ;-)

If you're worried about the 'transaction.abort()' being called by validate_base.vpy, I can suggest to fire a IObjectFailedValidation (or something like that) event there, that can be subscribed by third party code (the special widget, in this case).

Having a failed-validation event makes sense, as does a validation-succeeded event if there isn't anything like it already.

I'll implement the support for failed/succeeded validation events, if I got a +2 from you... :-)

--

_______________________________________________________

Dorneles Treméa · Developer, Jarn · www.jarn.com

Plone Solutions, Development, Hosting and Support

_______________________________________________________

Plone Solutions is now known as Jarn www.jarn.com/name-change