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:Martin Aspeli (opti@public.gmane.org)
Date:Nov 12, 2007 1:41:27 pm
List:net.sourceforge.lists.plone-developers

Dorneles Treméa wrote:

Martin,

For your use case, why don't you just subclass from ReferenceField and override set() to do your object creation?

because we want a 'drop-in' replacement widget that can be used with the standard ReferenceField without further changes.

You could have a drop-in replacement field that is a subclass of the existing ReferenceField, that defaults to your new widget. Being a subclass of the existing field, there'd be no migration necessary.

Putting this behaviour in a widget is plainly wrong. A widget exists to present a field in view and edit mode. The process_form() method of a widget exists to turn raw form data into something usable for a field. The whole persistence layer works at the field level, not the widget level.

Martin