atom feed3 messages in net.sourceforge.lists.plone-usersRe: Kupu problem with RichWidget and ...
FromSent OnAttachments
Morten W. PetersenOct 20, 2006 11:34 pm 
Tim CouperOct 21, 2006 9:59 am 
Duncan BoothOct 21, 2006 10:07 am 
Subject:Re: Kupu problem with RichWidget and Archetypes
From:Duncan Booth (dunc@public.gmane.org)
Date:Oct 21, 2006 10:07:26 am
List:net.sourceforge.lists.plone-users

"Morten W. Petersen" <morten-A9enih0ZUwqRtqRaY+ou@public.gmane.org> wrote:

I don't remember exactly what the fix was, or which project it was for - but you can try copying a RichWidget example from ATContentTypes/content/ or from another product that makes use of Archetypes.

For the record. The original post was:

I have a problem with a custom archetype class, where the field is using a RichWidget for editing. The schema looks like this:

schema = BaseSchema + Schema(( TextField('body', searchable=True, required=True, primary=True, validators = ('isTidyHtmlWithCleanup',), default_content_type='text/html', default_output_type='text/html', widget=RichWidget( rows=25, allow_file_upload=False, ), ), ), marshall=PrimaryFieldMarshaller(), )

and whenever someone tries to edit an instance of this type, they get a regular HTML text area, instead of the kupu interface. When someone is editing an ATDocument - they do get the kupu interface.

The allowable_content_type for the above field is not set, therefore it uses the default setting which is:

'allowable_content_types' : ('text/plain',),

Kupu only lets you edit fields where text/html is an allowable content type.

I think in this case the HTML generated for the widget will create a hidden field (no need for a pulldown since there is only one allowed type) which sets the field format to text/plain overriding the default content type. It would be good if Archetypes applied some sanity checking here, but it doesn't.