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:Wichert Akkerman (wich@public.gmane.org)
Date:Nov 12, 2007 9:56:16 am
List:net.sourceforge.lists.plone-developers

Previously Dorneles Treméa wrote:

Hey Martin,

No, I mean, it's a (serious, but discoverable) bug in the code that's using CMFFormController.

In now way is this a bug in CMFFormController. At best it's a missing feature, and I'd argue it'd be a mis-feature.

I see you point, but I disagree, keep reading... ;-)

Rolling back the transaction seems drastic. In some cases, you may even want to save something even if validation fails.

If you need to save something even if the validation fails at a later point, you can do a full commit at anytime.

Doing a full premature commit is bad. Something later (outside the control of your cpy script) could fail, in which case you do want something rolled back.

You asked for a way to 'save something even if validation fails'. I presented that to you.

A premature commit is bad, but at least you have the choice to do it, and this choice is something that we don't have now for the 'abort' case.

I don't think it's hard. Let's say you set up a chain like this:

+---(success)-->[save script] --[page template]-->[validator]--+ +---(failure)-->[abort/error page]

The validator is in the chain explicitly. You may not know what in the validator exactly failed, but you *do* know that something failed, and you can react accordingly.

Of course I can do whatever I want in a custom content-type and/or plain form validation... but I'm talking about the *standard* behavior of the Archetypes/CMFFormController integration... and even further, the standard behavior of CMFFormController validation.

As Wichert and Sidnei pointed out, the default use case should be:

- abort any persistent change, and give the option to save something even if the validation fails

I did not point that out and I do not agree with that point of view. In my opinion a transaction should never be aborted unless a programmer very explicitly says so. A formcontroller path does not fall in that category in my opinion.

But the current default implementation can be read as:

- keep the persistent changes, and doesn't allow us to abort them if the validation fails... :-/

It does allow that. If you need to doom the transaction your verification script can do so.

In fact, it's much easier to fix it directly on Archetypes, but what I want to make sure people understand is that the current implementation assumes the wrong case as the default one.

I also don't think this should be changed in archetypes.

Wichert.

-- Wichert Akkerman <wich@public.gmane.org> It is
simple to make things. http://www.wiggy.net/ It is hard to make things simple.