Hi Charlie!
Charlie Clark wrote:
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.
Did some more refactoring. If your factory can handle all the input,
ContentAddFormBase's 'create' method should be sufficient. If not, you
need a 'create' method like the one in FileAddView.
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.
Sorry. Added a small explanation in the module docstring.
Regarding naming: I suppose the easiest thing is to add an id field to
the add form for none file objects.
That's an option if you don't want automatically generated IDs. My
question was how to integrate oldstyle factories that don't have an add
form into an add menu.
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.
In my own code I use some modified widgets that support
self.widgets['foo'].required=True to override required=False of the field.
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?
First priority for existing content classes is backwards compatibility.
I prefer to keep them as they are and to use adapters to make them work
with Zope3 style code.
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?
The IAdding view ('+' syntax) and Zope 3 menus are special code for the
Zope 3 app ZMI. I don't plan to add support for that.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
