Re: [Zope-CMF] Re: [dev] newstyle content creation
Am 13.05.2008 um 23:39 schrieb yuppie: If a new style factory is specified in the FTI a view of that name is looked up on the adding view of the container. This is from plone.app.contentmenu.menu.FactoriesSubMenuItem: addingview = queryMultiAdapter((addContext, self.request), name='+') if addingview is not None: addview = queryMultiAdapter((addingview, self.request), name=fti.factory) if addview is not None: return '%s/+/%s' % (baseUrl, fti.factory,) That means view name and factory name have to be the same. The portal type is not passed to the view, so it has to be hardcoded inside the view. Not very flexible, but if factory and view are only used for one hardcoded portal type it works. Any more thoughts on this? I agree with you that the hardcoded approach above isn't nice but can't think of a nice way to square the circle where the add forms are registered for the container and not the new object. Is it possible to do something with actions? Either by defining an additional category such as add on the objects themselves? That would be easy enough from the object's perspective but would conflict with the current lookup on the folder category. This shouldn't be too bad as this could be replaced by looking at the allowed_content_types. But I guess this might have the same complexity and performance problems as relying on IAdding. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
Re: [Zope-CMF] Re: [dev] newstyle content creation
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. Done quite a lot of Add Forms based on your work and we ended up extended the base view to implement form_fields and require the sub classes to provide the portal_type and the schema or list of fields. @property def form_fields(self): fields = form.FormFields( TextLine( __name__='portal_type', default=self.portal_type) ) # allow sub-classes to pass in sequences of schema if isinstance(list, self.schema): for s in self.schema: fields += form.FormFields(s) else: fields += form.FormFields(self.schema) return fields I'm not sure if it's overkill to be able to handle a list of fields but we've found it makes views a lot easier to work with. What do you think? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
Re: [Zope-CMF] Re: [dev] newstyle content creation
Am 19.05.2008 um 18:51 schrieb Charlie Clark: 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=uportal type) Obviously that won't work but it seems it should be possible to add the portal_type logic to the base form as this should be true for all add forms for CMF objects, shouldn't it? in ContentAddFormBase def setUpWidgets(self, ignore_request=False): super(ContentAddFormBase, self).setUpWidgets(ignore_request=ignore_request) self.widgets['portal_type'].hide = True def form_fields(self): fields = form.FormFields( TextLine( __name__='portal_type', default=self.portal_type) ) return fields add forms now simply need to define their portal_type and extend the fields: portal_type = uTextbody @property def form_fields(self): fields = (super(TextAdd, self).form_fields() + form.FormFields(ITextbody)) return fields I'm not sure if it's good style to do this using properties but it seems to work for and I find it less of a source of copy and paste errors. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
[Zope-CMF] Re: [dev] newstyle content creation
Charlie Clark wrote: [..] 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? Alternatively, support for portal_type specification at runtime (and anything else for that matter) could be handled as a behavior in the sense of http://pypi.python.org/pypi/plone.behavior/ maybe? Just a thought ... Raphael ___ 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
Re: [Zope-CMF] Re: [dev] newstyle content creation
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=uportal 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@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] newstyle content creation
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
Re: [Zope-CMF] Re: [dev] newstyle content creation
Am 25.04.2008 um 19:23 schrieb Charlie Clark: 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. I've been successfully able to implement my own add Views for some of my own objects and it definitely makes sense to have let contentAddView do the work. For my objects I don't seem to need anything specific in the view so always implementing a method such has _create or maybe _handle_add doesn't make sense. Maybe a lookup to see if such a method is implemented for adapting any additional adaptation? if hasattr(self, adapt_form_to_object): self.adapt_form_to_object 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. Ha, should have looked more closely at the code! You're automatically generating names as required. Maybe the lookup should also cope with forms where an id is supplied just as you've done with filenames? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
[Zope-CMF] Re: [dev] newstyle content creation
Hi! Charlie Clark wrote: Okay. Had a quick look your implementation and I think I understand it! 8-) Had trouble with createAndAdd and finishCreate but now I understand them. Shouldn't there be default finishCreate in the ContentAddFormBase so that it's obvious we have to overwrite it? 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. 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 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. 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
Re: [Zope-CMF] Re: [dev] newstyle content creation
Am 23.04.2008 um 11:27 schrieb Wichert Akkerman:
BTW. regarding formlib I've been bashing my head (checkout those
bruises!) for weeks on how to add a thumbnail of an existing image to
an edit form. Do I need to develop a special widget which will call
the appropriate method?
Perhaps collective.namedfile has a suitable widget.
Couldn't find anything but I've come up with something that works in
the meantime. I suspect this is fundamentally wrong but it's the best
I can up with
img tal:attributes=src string:${context/context/absolute_url} /
Is this okay or am I likely to get bitten by aquisition or something
equally nasty?!
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
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
Re: [Zope-CMF] Re: [dev] newstyle content creation
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 ___ 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
[Zope-CMF] Re: [dev] newstyle content creation
Martin Aspeli wrote: Today I checked in a formlib based add view for File objects[3]. Have you looked at z3c.form at all? There's a package called plone.z3cform that provides Zope 2 integration for this (it shouldn't be Plone specific beyond that). I'm only asking since people seem to be going in this direction. I know. These are the reasons why I chose zope.formlib: - Zope 2 ships with zope.formlib, not with z3c.form - zope.formlib is already used for CMF edit forms - the work done for the zope.formlib based version is not lost if we switch to z3c.form, converting the forms should be easy The checked in add form borrows one pattern from z3c.form: It doesn't depend on IAdding, the view is registered for the container. 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
Re: [Zope-CMF] Re: [dev] newstyle content creation
Am 22.04.2008 um 23:54 schrieb Martin Aspeli: Have you looked at z3c.form at all? There's a package called plone.z3cform that provides Zope 2 integration for this (it shouldn't be Plone specific beyond that). I'm only asking since people seem to be going in this direction. As Yuppie says a lot of work has already been done using formlib. And while using the latest and greatest (yes, I know z3c.form has been around for a while) might be desirable, I don't think there are enough developers actively working on the CMF to keep pace. But from what I understand of the packages - the migration to z3c.form from formlib shouldn't be as demanding as moving to formlib in the first place but it would make sense to complete the move to formlib first and replacing the add view of Folders was probably the most demanding bit of what's left. Regarding plone.z3cform - doesn't the licence preclude inclusion within the CMF? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
Re: [Zope-CMF] Re: [dev] newstyle content creation
Am 22.04.2008 um 17:24 schrieb yuppie: Yes. Missing is the integration in the CMFDefault add menu. For now the new 'add_file' action is used for showing the link to 'addFile.html'. I hope to have some time for this (and a new table-free version of main_template.pt) on Friday. Where exactly is the CMFDefault add menu? Sorry, if the question is stupid but I didn't think we could use zope3 menu directives? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
[Zope-CMF] Re: [dev] newstyle content creation
Charlie Clark wrote: Am 22.04.2008 um 17:24 schrieb yuppie: Yes. Missing is the integration in the CMFDefault add menu. For now the new 'add_file' action is used for showing the link to 'addFile.html'. I hope to have some time for this (and a new table-free version of main_template.pt) on Friday. Where exactly is the CMFDefault add menu? Sorry, if the question is stupid but I didn't think we could use zope3 menu directives? Sorry for using misleading terms. I was referring to 'folder_factories'. 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
Re: [Zope-CMF] Re: [dev] newstyle content creation
Am 23.04.2008 um 11:12 schrieb yuppie: Charlie Clark wrote: Am 22.04.2008 um 17:24 schrieb yuppie: Yes. Missing is the integration in the CMFDefault add menu. For now the new 'add_file' action is used for showing the link to 'addFile.html'. I hope to have some time for this (and a new table-free version of main_template.pt) on Friday. Where exactly is the CMFDefault add menu? Sorry, if the question is stupid but I didn't think we could use zope3 menu directives? Sorry for using misleading terms. I was referring to 'folder_factories'. ah, so clicking on add brings up the tried and trusty page for adding objects to folders? Only then do we get to the appropriate add_view? Would it be a good idea to move this to a menu item like object_actions? Got the code for this. BTW. regarding formlib I've been bashing my head (checkout those bruises!) for weeks on how to add a thumbnail of an existing image to an edit form. Do I need to develop a special widget which will call the appropriate method? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
Re: [Zope-CMF] Re: [dev] newstyle content creation
Previously Charlie Clark wrote: Am 23.04.2008 um 11:12 schrieb yuppie: Charlie Clark wrote: Am 22.04.2008 um 17:24 schrieb yuppie: Yes. Missing is the integration in the CMFDefault add menu. For now the new 'add_file' action is used for showing the link to 'addFile.html'. I hope to have some time for this (and a new table-free version of main_template.pt) on Friday. Where exactly is the CMFDefault add menu? Sorry, if the question is stupid but I didn't think we could use zope3 menu directives? Sorry for using misleading terms. I was referring to 'folder_factories'. ah, so clicking on add brings up the tried and trusty page for adding objects to folders? Only then do we get to the appropriate add_view? Would it be a good idea to move this to a menu item like object_actions? Got the code for this. BTW. regarding formlib I've been bashing my head (checkout those bruises!) for weeks on how to add a thumbnail of an existing image to an edit form. Do I need to develop a special widget which will call the appropriate method? Perhaps collective.namedfile has a suitable widget. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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
[Zope-CMF] Re: [dev] newstyle content creation
Hi! Charlie Clark wrote: Am 23.04.2008 um 11:12 schrieb yuppie: Charlie Clark wrote: Am 22.04.2008 um 17:24 schrieb yuppie: Yes. Missing is the integration in the CMFDefault add menu. For now the new 'add_file' action is used for showing the link to 'addFile.html'. I hope to have some time for this (and a new table-free version of main_template.pt) on Friday. Where exactly is the CMFDefault add menu? Sorry, if the question is stupid but I didn't think we could use zope3 menu directives? Sorry for using misleading terms. I was referring to 'folder_factories'. ah, so clicking on add brings up the tried and trusty page for adding objects to folders? Yes. Only then do we get to the appropriate add_view? No. As I said: That part is still missing. 'folder_factories' provides the old add procedure, the new alternative for 'File' content is available as action in the menu. Would it be a good idea to move this to a menu item like object_actions? Got the code for this. Maybe. Does your code use the type infos or additional actions (attached to the type infos or stored in the actions tool) to get the data? Do your actions provide a way to specify the object id (as possible in folder_factories) or how do you choose the ids? 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
Re: [Zope-CMF] Re: [dev] newstyle content creation
Am 23.04.2008 um 15:10 schrieb yuppie: ah, so clicking on add brings up the tried and trusty page for adding objects to folders? Yes. Only then do we get to the appropriate add_view? No. As I said: That part is still missing. 'folder_factories' provides the old add procedure, the new alternative for 'File' content is available as action in the menu. I'll check it out later then. Would it be a good idea to move this to a menu item like object_actions? Got the code for this. Maybe. Does your code use the type infos or additional actions (attached to the type infos or stored in the actions tool) to get the data? Do your actions provide a way to specify the object id (as possible in folder_factories) or how do you choose the ids? Currently have a very basic vocabulary listing possible types. Have been abusing invokeFactory to create my objects and autogenerate content ids. For some reason couldn't get the redirect from the TypeInfo so had to enforce the redirect manually. Would probably want to extend this to redirect to an add form for the relevant object and this is probably where I'll need the most help. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
Re: [Zope-CMF] Re: [dev] newstyle content creation
Am 23.04.2008 um 15:10 schrieb yuppie: No. As I said: That part is still missing. 'folder_factories' provides the old add procedure, the new alternative for 'File' content is available as action in the menu. Would it be a good idea to move this to a menu item like object_actions? Got the code for this. Maybe. Does your code use the type infos or additional actions (attached to the type infos or stored in the actions tool) to get the data? Do your actions provide a way to specify the object id (as possible in folder_factories) or how do you choose the ids? Okay. Had a quick look your implementation and I think I understand it! 8-) Had trouble with createAndAdd and finishCreate but now I understand them. Shouldn't there be default finishCreate in the ContentAddFormBase so that it's obvious we have to overwrite it? 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. 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? BTW. got bitten by the five.localsitemanager dependency with my 2.10 install. I've just reread the posts on this and I didn't quite understand them. Things worked fine, of course, when I dropped CMFCore/ src/five into my lib/python folder but I'm guessing this is something that's going to be phased out and that we're expecting users to be able to install the package separately themselves. Is this assumption correct? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
Re: [Zope-CMF] Re: [dev] newstyle content creation
On Apr 23, 2008, at 17:46 , Charlie Clark wrote: BTW. got bitten by the five.localsitemanager dependency with my 2.10 install. I've just reread the posts on this and I didn't quite understand them. Things worked fine, of course, when I dropped CMFCore/src/five into my lib/python folder but I'm guessing this is something that's going to be phased out and that we're expecting users to be able to install the package separately themselves. Is this assumption correct? This is correct. If I remember correctly you can just easy_install it. You can also get it from SVN and link it into your instance's lib/ python folder. jens ___ 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
[Zope-CMF] Re: [dev] newstyle content creation
Charlie Clark wrote: Am 22.04.2008 um 14:27 schrieb yuppie: Today I checked in a formlib based add view for File objects[3]. There is a new Add File action available if you use the Experimental CMFDefault Browser Views extension profile. Any feedback is welcome. Not sure if this makes Bug #161664[4] obsolete. This is excellent news! I have been struggling considerably with invokeFactory() on a recent project. Does this mean we can develop add_forms analogue to Zope 3? Yes. Similar code as used for creating File objects should work for any content. But ContentAddFormBase is new and not very well tested, so you might find some bugs. Note that the add view is registered for the container interface, not IAdding. zope.formlib still uses IAdding by default, but z3c.form doesn't. And do I get the goodies just with an svn update? Yes. Missing is the integration in the CMFDefault add menu. For now the new 'add_file' action is used for showing the link to 'addFile.html'. 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
