charlie at begeistert
May 19, 2008, 9:51 AM
Post #22 of 26
(615 views)
Permalink
|
Am 02.05.2008 um 13:50 schrieb yuppie:
> 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.
Yes, thank you very much!
>>>> 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.
Thanks again. As I said, I don't think it did me any harm to go
through the process of working through adapters. It was just a bit off-
putting when working on my own objects.
>> 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.
ah, now I understand the question! With addForms we get the default
next page but not with oldstyle factories? Is that correct?
>> 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.
That's probably the easiest solution at the moment although it would
be nice to be able to declare this in the schema. I suppose two
different interfaces à la IObject and IMutableObject provide a way. I
find fiddling with the form fields too easy to mess up! I think the
only thing that's missing from this is a nicer way of getting the
portal_type. As this is configurable in the ZMI and perfectly possible
to have several types deriving from the same class and, therefore,
from the same interface. Although as with browser views this should no
longer be possible. I can't see an easy way of doing this but it seems
to me much more natural to do this in the interface rather than in the
view as it's essentially declarative work. Maybe a dedicated schema
field for CMF Types and associated hidden widget?
portal_type = CMFDefault.schema.ContentType(title=u"portal type")
>> 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.
Okay. Just going from my own experience which was take CMFDefault and
see what you can do with it. - it's actually really nice to be able to
right some very lightweight, effectively Zope 3 classes, and give them
PortalContent. So, whilst supporting legacy classes, it would also be
nice to have a couple of examples of what to do if you write your own
classes from scratch. mm, probably something I could do.
>>>> 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.
And, as I know from a later post, the IAdding interface isn't
universally popular.
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
|
1
