[Zope-CMF] Re: [dev] newstyle content creation

Charlie Clark charlie at begeistert.org
Fri Apr 25 13:23:13 EDT 2008


Am 25.04.2008 um 09:23 schrieb yuppie:

> I simplified the code in ContentAddFormBase.create and moved it to  
> the add view. 'finishCreate' no longer exists, your add view has to  
> implement the complete 'create' method. Formlib raises an  
> NotImplementedError if 'create' is missing.
>
> This requires a few more lines of code in add views for real  
> IDynamicType content. If you hardcode factory and portal_type in the  
> view, the code becomes much simpler. And if the __init__ method of  
> your content type handles unicode and datetime correctly, 'create'  
> can be a single line.

Agreed. The first five lines are generic and should probably be in  
ContentAddFormBase leaving just the adapter stuff to be implemented by  
the view itself which is what is was before! _create would be more in  
keeping with other formlib methods such as handle_success calling  
_handle_success.

>> It's taken me such a while to get my head around the  
>> ProxyFieldProperty stuff that I've made all my new content stuff  
>> work without it but I can see you've used it elegantly.
>
> You should not use that stuff if you don't need it. Schema adapters  
> and ProxyFieldProperty are just legacy code for old content types.

I know. But I didn't know at the time and boy did it make me think  
that things were going to be harder than they needed! I had to take  
some time out at the time and curse the nameless people who hadn't  
written the dummies guide to this! Still, it wasn't a bad idea making  
me think more about this stuff.

Regarding naming: I suppose the easiest thing is to add an "id" field  
to the add form for none file objects. It would be nice to have a  
"require once" in the schema value for things like upload fields so  
that the same schema can be used for adding and editing.

This does, of course, beg the question: when we've moved everything to  
browser_views do we start thinking about moving the default classes to  
zope.app based stuff? Or do we still depend too heavily on the Zope2  
security declarations and other stuff?

>> I also understand what you mean about making a menu for this stuff.  
>> It would be nice to have some configuration for this so that we  
>> don't have to rely on actions such as AddFile, AddImage, etc. Would  
>> that be something like listing all views that provide a specific  
>> interface?
>
> No. The view registrations don't provide enough information and I'd  
> like to keep this configurable TTW.
>
> We can look up the addable types in the types tool as  
> folder_factories and Plone do. But in that case we need a way to get  
> the URL of the add view.


The lookup is pretty much what I do at the moment. I can't think of an  
easy way of doing this apart from convention which is pretty much what  
you suggest with "addFile". I suppose the next thing would be to add  
support for the '+' syntax and addMenuItem directive?

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226





More information about the Zope-CMF mailing list