[Zope-CMF] CMF Tests: 9 OK
Summary of messages to the cmf-tests list. Period Sat Jul 12 11:00:00 2008 UTC to Sun Jul 13 11:00:00 2008 UTC. There were 9 messages: 9 from CMF Tests. Tests passed OK --- Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Tests Date: Sat Jul 12 21:38:43 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-July/009299.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Tests Date: Sat Jul 12 21:40:13 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-July/009300.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Tests Date: Sat Jul 12 21:41:43 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-July/009301.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Sat Jul 12 21:43:13 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-July/009302.html Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Sat Jul 12 21:44:43 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-July/009303.html Subject: OK : CMF-2.1 Zope-2.11 Python-2.4.4 : Linux From: CMF Tests Date: Sat Jul 12 21:46:14 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-July/009304.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Sat Jul 12 21:47:44 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-July/009305.html Subject: OK : CMF-trunk Zope-2.11 Python-2.4.4 : Linux From: CMF Tests Date: Sat Jul 12 21:49:14 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-July/009306.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Tests Date: Sat Jul 12 21:50:44 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-July/009307.html ___ 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: Add forms and menus
Hi Yuppie, Martin Aspeli wrote: I see that Yuppie has been experimenting with add forms. From what I can tell, he's using a custom formlib base class and registering views as e.g. addFile.html. It also look as if he's registering that view as an action in portal_actions, in the 'folder' category. That's correct. But I have to mention that not all parts of these changes have reached the same stage of maturation. Using 'folder' category Actions is a temporary hack to generate menu items for the new add forms. I'm glad you want to help to find a better solution. Ah, good. Plone currently supports add forms for the IAdding (+) view in a somewhat ugly way (it looks to see if there's a view for IAdding with the same name as the 'factory' set in the FTI of an addable type, and if so, provides a link to it). IAdding can be a bit painful, so we're interested in supporting an approach based on simple views. Good. It's also worth noting that z3c.form (via plone.z3cform, which should be plain CMF compatible, though you may want a different default template) has support for such views in quite a generic way. The CMF version of that looks like this: http://dev.plone.org/plone/browser/plone.z3cform/trunk/plone/z3cform/add.py z3c.form is generally nicer to work with than formlib. Maybe we should discuss this in a different thread. Here a short reply: My code for the AddForm would look quite different, especially for CMF trunk, I'm curious how it would look different. Now is the time to get the correct base class behavior in plone.z3cform, before we release a new version of it. but in general that's the way to go. Since z3c.form became the standard in the Zope 3 world I'd like to see Zope 2 and CMF moving in the same direction. Unfortunately using plone.z3cform is no option for CMF because it has a different license and repository. *If* Plone wants to donate that code to the Zope Foundation or someone writes something similar (maybe five.z3cform), I'd be happy to help with CMF integration. Bah, I hate these discussions. I'm sure Daniel Nouri would be happy to relicense. Re-invention for the sake of a license is just too dumb. I'd prefer to keep the name to avoid breaking existing packages, though. Another option is to factor out a few things to a five.z3cform and have plone.z3cform import from it as appropriate. In any case, I'd like to know why you went down the portal_actions route for rendering the add links. I'm not quite sure I like the idea of having this be persistent configuration, separate to the FTI, as the two would need to be kept in sync, and in sync with the view name registered in ZCML. CMF makes a distinction between portal types and content types. Portal types are persistent wrappers around the non-persistent content types. You can define many different portal types based on one content type. Right. In CMF you add *portal type* instances, so the 'add' links should be persistent as well. The non-persistent add form has to take the portal type name as argument to create the correct portal type. I'm not sure what the right solution is, but I guess extending the type info classes will be the best approach. Also, why not try to use the Zope 3 menu concept? There's even a special add menu directive. Moving away from persistent actions is not on my todo list. And as I tried to explain above, the current portal type concept depends on persistent actions. Right, I see that. But having things in two places is obviously not very desirable either. I'd quite like to find a good approach here that can be used by both Plone and plain CMF, if possible. I hope you find one ;) How about we use a naming convention that's linked to the factory that's persisted in the FTI, i.e. we look for a view called add-factory_name and link to that if it's available. The idea is that the factory name is unique and specific to the content type. Different portal types that use the same factory would almost by necessity have the same add view. We could make this overrideable as well, with another FTI property. The assumption here is that the add menu is rendered with some custom code, i.e. it doesn't use the actions machinery or the Zope 3 browser menu concept. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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: Add forms and menus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Hi folks, I see that Yuppie has been experimenting with add forms. From what I can tell, he's using a custom formlib base class and registering views as e.g. addFile.html. It also look as if he's registering that view as an action in portal_actions, in the 'folder' category. Plone currently supports add forms for the IAdding (+) view in a somewhat ugly way (it looks to see if there's a view for IAdding with the same name as the 'factory' set in the FTI of an addable type, and if so, provides a link to it). IAdding can be a bit painful, so we're interested in supporting an approach based on simple views. It's also worth noting that z3c.form (via plone.z3cform, which should be plain CMF compatible, though you may want a different default template) has support for such views in quite a generic way. The CMF version of that looks like this: http://dev.plone.org/plone/browser/plone.z3cform/trunk/plone/z3cform/add.py z3c.form is generally nicer to work with than formlib. In any case, I'd like to know why you went down the portal_actions route for rendering the add links. I'm not quite sure I like the idea of having this be persistent configuration, separate to the FTI, as the two would need to be kept in sync, and in sync with the view name registered in ZCML. Putting the policy in the typeinfo objects seems like a much saner place to keep this stuff than embedding it in a component registry. Also, why not try to use the Zope 3 menu concept? There's even a special add menu directive. The Z3 menu stuff seems to me bound up with the needs of the never-gonna-use-it Z3MI: it is overcomplicated for little purpose, and puts too much policy into emergent behavior (ordering of component lookups, for instance). I'd quite like to find a good approach here that can be used by both Plone and plain CMF, if possible. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIegPw+gerLs4ltQ4RAhheAKCQdKEg+O/y4OM42zYJQ5vHNJSRngCfagdO rUEaTSE/XFT6sw7sUTUgrQ8= =L3iv -END PGP SIGNATURE- ___ 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: Add forms and menus
Am 13.07.2008 um 14:08 schrieb Martin Aspeli:
Thanks for restarting the discussion and thanks to Yuppie for his
implementation. We've been using it with the changes I outlined the
other week to good effect for the last couple of months.
Bah, I hate these discussions. I'm sure Daniel Nouri would be happy
to relicense. Re-invention for the sake of a license is just too dumb.
I think we all hate such discussions but that's the way it is when
derivative code gets given a different licence.
I'd prefer to keep the name to avoid breaking existing packages,
though.
Another option is to factor out a few things to a five.z3cform and
have plone.z3cform import from it as appropriate.
This is probably necessary anyway. I'm not sure whether it's right to
try and go straight to z3c.form. My understanding is that there isn't
a great deal of difference between the two libraries so hopefully an
implementation could live with both. I don't think that everyone has
moved onto z3c.form - certainly that wasn't my impression at
Europython. It would be nice to have a formlib based CMF 2.2 and I
think I now understand most of this well enough to contribut. We could
possibly onto z3c.form in 2.3 which might have replaced zope.formlib
in Zope by then.
In any case, I'd like to know why you went down the portal_actions
route for rendering the add links. I'm not quite sure I like the
idea of having this be persistent configuration, separate to the
FTI, as the two would need to be kept in sync, and in sync with
the view name registered in ZCML.
CMF makes a distinction between portal types and content types.
Portal types are persistent wrappers around the non-persistent
content types. You can define many different portal types based on
one content type.
Right.
In CMF you add *portal type* instances, so the 'add' links should
be persistent as well. The non-persistent add form has to take the
portal type name as argument to create the correct portal type.
I'm not sure what the right solution is, but I guess extending the
type info classes will be the best approach.
Also, why not try to use the Zope 3 menu concept? There's even a
special add menu directive.
Moving away from persistent actions is not on my todo list. And as
I tried to explain above, the current portal type concept depends
on persistent actions.
Right, I see that. But having things in two places is obviously not
very desirable either.
I'd quite like to find a good approach here that can be used by
both Plone and plain CMF, if possible.
I hope you find one ;)
How about we use a naming convention that's linked to the factory
that's persisted in the FTI, i.e. we look for a view called add-
factory_name and link to that if it's available.
You might as well stick with actions if you're going to do that. I've
been experimenting with the following
portal_type = self.request.form.get('portal_type')
at = getToolByName(self.context, 'portal_actions')
actions = at.listFilteredActionsFor(self.context)
addable = actions.get('add', [])
for a in addable:
if a['id'] == portal_type:
return request.response(%s/%s (%self.context.absolute_url(),
a['url']))
It's workable but so easy to break as it relies on add actions
having the same name as the portal_type. It makes much more sense to
me to have this on the type info: if I ask the type tool for the
factory, surely I can also ask it for the view?
The idea is that the factory name is unique and specific to the
content type. Different portal types that use the same factory would
almost by necessity have the same add view.
We could make this overrideable as well, with another FTI property.
The assumption here is that the add menu is rendered with some
custom code, i.e. it doesn't use the actions machinery or the Zope 3
browser menu concept.
Yes, I think that has to be the case.
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: Add forms and menus
Hi Martin!
Martin Aspeli wrote:
Martin Aspeli wrote:
It's also worth noting that z3c.form (via plone.z3cform, which should
be plain CMF compatible, though you may want a different default
template) has support for such views in quite a generic way. The
CMF version of that looks like this:
http://dev.plone.org/plone/browser/plone.z3cform/trunk/plone/z3cform/add.py
z3c.form is generally nicer to work with than formlib.
Maybe we should discuss this in a different thread. Here a short
reply: My code for the AddForm would look quite different, especially
for CMF trunk,
I'm curious how it would look different. Now is the time to get the
correct base class behavior in plone.z3cform, before we release a new
version of it.
Ok. I added some comments to the 'add' method of plone.z3cform:
def add(self, object):
container = aq_inner(self.context)
content = object
name = self.contentName
chooser = INameChooser(container)
# Ensure that construction is allowed
portal_types = getToolByName(container, 'portal_types')
fti = portal_types.getTypeInfo(content)
if fti is not None:
# Check add permission
if not fti.isConstructionAllowed(container):
raise Unauthorized(uYou are not allowed to create a %d here %
fti.getId())
Inside an add form this should always be true. If it isn't true, we'll
get an error anyway. So this check is redundant and can be removed.
# Check allowable content types
if getattr(aq_base(container), 'allowedContentTypes', None) is not
None and \
not fti.getId() in container.allowedContentTypes():
raise Unauthorized(uYou are not allowed to create a %d here %
fti.getId())
allowedContentTypes is quite expensive. I use this code instead:
#check container constraints
container_ti = portal_types.getTypeInfo(container)
portal_type = content.getPortalTypeName()
if container_ti is not None and \
not container_ti.allowType(portal_type):
raise ValueError('Disallowed subobject type: %s' % portal_type)
# check preconditions
checkObject(container, name, content)
I doubt constraints based on __setitem__ and __parent__ work in Zope 2.
if IContainerNamesContainer.providedBy(container):
# The container picks it's own names.
# We need to ask it to pick one.
name = chooser.chooseName(self.contentName or '', content)
else:
request = self.request
name = request.get('add_input_name', name)
if name is None:
name = chooser.chooseName(self.contentName or '', content)
elif name == '':
name = chooser.chooseName('', content)
else:
# Invoke the name chooser even when we have a
# name. It'll do useful things with it like converting
# the incoming unicode to an ASCII string.
name = chooser.chooseName(name, container)
if not name:
raise ValueError(Cannot add content: name chooser did not provide a
name)
All that name handling is copied from an old version of Five's
BasicAdding, which in turn is copied from old Zope 3 code. I think we
should use our own code here to make sure we understand the code and it
reflects our policy.
Creating the content I set a provisional id. In the 'add' method I just
use this line:
name = chooser.chooseName(content.getId(), content)
content.id = name
container._setObject(name, content)
content = container._getOb(name)
if fti is not None:
fti._finishConstruction(content)
CMF trunk uses events instead of _finishConstruction.
self.contentName = name
but in general that's the way to go. Since z3c.form became the
standard in the Zope 3 world I'd like to see Zope 2 and CMF moving in
the same direction. Unfortunately using plone.z3cform is no option for
CMF because it has a different license and repository. *If* Plone
wants to donate that code to the Zope Foundation or someone writes
something similar (maybe five.z3cform), I'd be happy to help with CMF
integration.
Bah, I hate these discussions. I'm sure Daniel Nouri would be happy to
relicense. Re-invention for the sake of a license is just too dumb.
I'd prefer to keep the name to avoid breaking existing packages, though.
Another option is to factor out a few things to a five.z3cform and have
plone.z3cform import from it as appropriate.
+1
plone.z3cform seems to contain Plone specific stuff. Factoring out the
generic stuff to a five.z3cform package sounds good to me.
But I don't know if everybody agrees that CMF 2.2 should depend on z3c.form.
How about we use a naming convention that's linked to the factory that's
persisted in the FTI, i.e. we look for a view
[Zope-CMF] Re: Add forms and menus
Charlie Clark wrote:
This is probably necessary anyway. I'm not sure whether it's right to
try and go straight to z3c.form. My understanding is that there isn't
a great deal of difference between the two libraries so hopefully an
implementation could live with both. I don't think that everyone has
moved onto z3c.form - certainly that wasn't my impression at
Europython. It would be nice to have a formlib based CMF 2.2 and I
think I now understand most of this well enough to contribut. We could
possibly onto z3c.form in 2.3 which might have replaced zope.formlib
in Zope by then.
I doubt that formlib will be replaced by z3c.form. Rather, it just seems
that everyone prefers to work with the latter and so the former is
becoming less relevant.
They are definitely different, and don't share any code as far as I
know, but if you know one, moving to the other is pretty trivial.
z3c.form also has good (if a bit too abundant) documentation.
Thus, if CMF hasn't yet picked a form library in a release, then you
could try to learn from Plone's mistakes and not jump on a sinking ship. :)
How about we use a naming convention that's linked to the factory
that's persisted in the FTI, i.e. we look for a view called add-
factory_name and link to that if it's available.
You might as well stick with actions if you're going to do that. I've
been experimenting with the following
portal_type = self.request.form.get('portal_type')
at = getToolByName(self.context, 'portal_actions')
actions = at.listFilteredActionsFor(self.context)
addable = actions.get('add', [])
for a in addable:
if a['id'] == portal_type:
return request.response(%s/%s (%self.context.absolute_url(),
a['url']))
It's workable but so easy to break as it relies on add actions
having the same name as the portal_type. It makes much more sense to
me to have this on the type info: if I ask the type tool for the
factory, surely I can also ask it for the view?
You mean we have an action on the FTI object with category 'add' and
name == FTI name/portal_type? That still means having to get that link
right, though (a typo in the FTI name or a rename of the FTI makes it
break), and I question whether you ever need all the other info that
actions provide. We already have ways to control add permissions and
other filters for what's addable where.
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
___
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: Add forms and menus
Hi Tres, Putting the policy in the typeinfo objects seems like a much saner place to keep this stuff than embedding it in a component registry. +1, at least if we're talking about persistent configuration (which I guess we are). Do you have a preference for what shape this should take? - A simple property 'addview' that gives a view name? - A simple property 'addview' that gives a view name in a TALES expression? - Something using FTI actions? - Something else? Also, why not try to use the Zope 3 menu concept? There's even a special add menu directive. The Z3 menu stuff seems to me bound up with the needs of the never-gonna-use-it Z3MI: it is overcomplicated for little purpose, and puts too much policy into emergent behavior (ordering of component lookups, for instance). Plone uses it to make the content menu (the green bar in the editable border) somewhat pluggable and customiseable-by-context. In hindsight, we could probably just as easily have invented our own interfaces and used that instead of the ones in zope.app.publisher, though I don't think they've done too much harm either. The ordering thing is irritating though. For add menus, however, there *may* be a purpose to using it since Zope 3 has a specific ZCML directive to declare your add action. At least we should consider it. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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: Add forms and menus
Hi Yuppie,
Ok. I added some comments to the 'add' method of plone.z3cform:
Thanks for that!
def add(self, object):
container = aq_inner(self.context)
content = object
name = self.contentName
chooser = INameChooser(container)
# Ensure that construction is allowed
portal_types = getToolByName(container, 'portal_types')
fti = portal_types.getTypeInfo(content)
if fti is not None:
# Check add permission
if not fti.isConstructionAllowed(container):
raise Unauthorized(uYou are not allowed to create a %d here %
fti.getId())
Inside an add form this should always be true. If it isn't true, we'll
get an error anyway. So this check is redundant and can be removed.
Cool.
# Check allowable content types
if getattr(aq_base(container), 'allowedContentTypes', None) is not
None and \
not fti.getId() in container.allowedContentTypes():
raise Unauthorized(uYou are not allowed to create a %d here %
fti.getId())
allowedContentTypes is quite expensive. I use this code instead:
#check container constraints
container_ti = portal_types.getTypeInfo(container)
portal_type = content.getPortalTypeName()
if container_ti is not None and \
not container_ti.allowType(portal_type):
raise ValueError('Disallowed subobject type: %s' % portal_type)
Nice!
# check preconditions
checkObject(container, name, content)
I doubt constraints based on __setitem__ and __parent__ work in Zope 2.
Well, they do in the sense that if you have them and we have this code,
we'll get an exception. They don't work generally, tough, so this may be
YAGNI. It was copied from Five's Adding implementation, so I figured it
should be kept if someone's relying on it.
if IContainerNamesContainer.providedBy(container):
# The container picks it's own names.
# We need to ask it to pick one.
name = chooser.chooseName(self.contentName or '', content)
else:
request = self.request
name = request.get('add_input_name', name)
if name is None:
name = chooser.chooseName(self.contentName or '', content)
elif name == '':
name = chooser.chooseName('', content)
else:
# Invoke the name chooser even when we have a
# name. It'll do useful things with it like converting
# the incoming unicode to an ASCII string.
name = chooser.chooseName(name, container)
if not name:
raise ValueError(Cannot add content: name chooser did not provide a
name)
All that name handling is copied from an old version of Five's
BasicAdding, which in turn is copied from old Zope 3 code. I think we
should use our own code here to make sure we understand the code and it
reflects our policy.
Yeah, that code's pretty nuts and doesn't make a lot of sense. I tried
to refactor it when I copied it over, actually, and then found that I
didn't really understand it so I left it alone.
Creating the content I set a provisional id. In the 'add' method I just
use this line:
name = chooser.chooseName(content.getId(), content)
+1
content.id = name
container._setObject(name, content)
content = container._getOb(name)
if fti is not None:
fti._finishConstruction(content)
CMF trunk uses events instead of _finishConstruction.
Ah, nice. Do you think it'd be feasible to backport this, i.e. copy the
event handler somewhere in Plone so long as Plone's still using an older
version of CMF? Or does the new event handler rely on other changes to
CMF as well?
Another option is to factor out a few things to a five.z3cform and have
plone.z3cform import from it as appropriate.
+1
plone.z3cform seems to contain Plone specific stuff. Factoring out the
generic stuff to a five.z3cform package sounds good to me.
I'm CC'ing Daniel Nouri if he has an opinion. I think it should be
unproblematic to test this stuff out in plone.z3cform and then have it
depend on a new five.z3cform and just do convenience imports where required.
But I don't know if everybody agrees that CMF 2.2 should depend on z3c.form.
CMFCore shouldn't need to. CMFDefault may want to though.
How about we use a naming convention that's linked to the factory that's
persisted in the FTI, i.e. we look for a view called
add-factory_name and link to that if it's available.
The idea is that the factory name is unique and specific to the content
type.
I sometimes use different factories for one content type, but a 1:1
relationship doesn't seem to be necessary for your proposal.
Different portal types that use the same factory would almost by
necessity have the same add view.
This is the
Re: [Zope-CMF] Re: Add forms and menus
Am 13.07.2008 um 20:21 schrieb Martin Aspeli:
I doubt that formlib will be replaced by z3c.form. Rather, it just
seems that everyone prefers to work with the latter and so the
former is becoming less relevant.
I wonder who everyone is? When I asked Maartijn Faassen as
Europython he didn't seem to be in a hurry to migrate Grok to using
z3c.form and his work on Formulator was possibly the start of a Zope
forms library of which formlib and z3c.form are the nth and n+1th
generations.
They are definitely different, and don't share any code as far as I
know, but if you know one, moving to the other is pretty trivial.
z3c.form also has good (if a bit too abundant) documentation.
I've only briefly looked at z3c.form but it seems to make abundant
reference to how zope.formlib works.
Thus, if CMF hasn't yet picked a form library in a release, then you
could try to learn from Plone's mistakes and not jump on a sinking
ship. :)
We're already using zope.formlib in the experimental browser views
edit forms. The reference to a sinking ship is totally off-target. My
own view is that sometimes it is better to wait for version 2 of a
product or library to be released before adoption. Surely Plone has
suffered from adopting some stuff too early?
How about we use a naming convention that's linked to the factory
that's persisted in the FTI, i.e. we look for a view called add-
factory_name and link to that if it's available.
You might as well stick with actions if you're going to do that.
I've been experimenting with the following
portal_type = self.request.form.get('portal_type')
at = getToolByName(self.context, 'portal_actions')
actions = at.listFilteredActionsFor(self.context)
addable = actions.get('add', [])
for a in addable:
if a['id'] == portal_type:
return request.response(%s/%s (%self.context.absolute_url(),
a['url']))
It's workable but so easy to break as it relies on add actions
having the same name as the portal_type. It makes much more sense
to me to have this on the type info: if I ask the type tool for
the factory, surely I can also ask it for the view?
You mean we have an action on the FTI object with category 'add' and
name == FTI name/portal_type? That still means having to get that
link right, though (a typo in the FTI name or a rename of the FTI
makes it break), and I question whether you ever need all the other
info that actions provide. We already have ways to control add
permissions and other filters for what's addable where.
Yes, which is why I don't favour this approach: it can work but is
likely to cause problems.
What we all want is to be able to get the add view for a particular
portal_type but we can't do this through QueryMultiAdapter because the
view has to be registered on a container. Actions are unsuitable but
provided Yuppie with a bootstrap to test the whole procedure and
highlight the deficiencies. I'm afraid I don't understand the
internals too well but isn't something like cmf:registerAddView ...
or what we're after until the Zope 3 world comes up with the right
way to do this?
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: Add forms and menus
Charlie Clark wrote: Am 13.07.2008 um 20:21 schrieb Martin Aspeli: I doubt that formlib will be replaced by z3c.form. Rather, it just seems that everyone prefers to work with the latter and so the former is becoming less relevant. I wonder who everyone is? When I asked Maartijn Faassen as Europython he didn't seem to be in a hurry to migrate Grok to using z3c.form and his work on Formulator was possibly the start of a Zope forms library of which formlib and z3c.form are the nth and n+1th generations. Well, let me put it another way then: A lot of people have expressed dissatisfaction with formlib and seem to like z3c.form better. They are definitely different, and don't share any code as far as I know, but if you know one, moving to the other is pretty trivial. z3c.form also has good (if a bit too abundant) documentation. I've only briefly looked at z3c.form but it seems to make abundant reference to how zope.formlib works. Right. z3c.form is an attempt to rectify some of the mistakes from zope.formlib and build something better. Thus, if CMF hasn't yet picked a form library in a release, then you could try to learn from Plone's mistakes and not jump on a sinking ship. :) We're already using zope.formlib in the experimental browser views edit forms. The reference to a sinking ship is totally off-target. My own view is that sometimes it is better to wait for version 2 of a product or library to be released before adoption. Surely Plone has suffered from adopting some stuff too early? *shrug* Do what you please. I'm not particularly wedded to one or the other. But having used both, I'm pretty sure that z3c.form is a better library. In many ways, z3c.form *is* version 2 of formlib. Yes, which is why I don't favour this approach: it can work but is likely to cause problems. I don't have an approach, I'm trying to find one that works. I'm not sure what problems you're referring to, though. What we all want is to be able to get the add view for a particular portal_type but we can't do this through QueryMultiAdapter because the view has to be registered on a container.' Mmmm... I'm not sure I follow here. The issue is how to render the correct link to the add view for each addable type. You loop through the addable types and then render a list of links. If by queryMultiAdapter you mean the browser view lookup, then that's something the publisher does when someone clicks the link, not something we'd do to find out what those links are. Actions are unsuitable but provided Yuppie with a bootstrap to test the whole procedure and highlight the deficiencies. Obviously. I'm afraid I don't understand the internals too well but isn't something like cmf:registerAddView ... or what we're after until the Zope 3 world comes up with the right way to do this? Zope 3 has a way, it's called browser:addMenuItem / (or something like that). However, Tres and Yuppie have pointed out reasons why doing this with global component registrations is not ideal. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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: Add forms and menus
Martin Aspeli writes: Yuppie writes: but in general that's the way to go. Since z3c.form became the standard in the Zope 3 world I'd like to see Zope 2 and CMF moving in the same direction. Unfortunately using plone.z3cform is no option for CMF because it has a different license and repository. *If* Plone wants to donate that code to the Zope Foundation or someone writes something similar (maybe five.z3cform), I'd be happy to help with CMF integration. Bah, I hate these discussions. I'm sure Daniel Nouri would be happy to relicense. Re-invention for the sake of a license is just too dumb. I'd prefer to keep the name to avoid breaking existing packages, though. Another option is to factor out a few things to a five.z3cform and have plone.z3cform import from it as appropriate. I just relicensed and moved plone.z3cform to the Zope repository: http://svn.zope.org/plone.z3cform/trunk/ Despite the plone namespace, it works fine in CMF and pure Zope 2. *Some* of the functionality (modules) is Plone or CMF specific. The default configure.zcml aims to be usable without Plone or CMF. There's a buildout.cfg in there that pulls Plone. I'd like to replace it with a Zope2-only one (and maybe move the existing buildout to another location). The tests work without Plone. Daniel ___ 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: Add forms and menus
Daniel Nouri wrote: Martin Aspeli writes: Yuppie writes: but in general that's the way to go. Since z3c.form became the standard in the Zope 3 world I'd like to see Zope 2 and CMF moving in the same direction. Unfortunately using plone.z3cform is no option for CMF because it has a different license and repository. *If* Plone wants to donate that code to the Zope Foundation or someone writes something similar (maybe five.z3cform), I'd be happy to help with CMF integration. Bah, I hate these discussions. I'm sure Daniel Nouri would be happy to relicense. Re-invention for the sake of a license is just too dumb. I'd prefer to keep the name to avoid breaking existing packages, though. Another option is to factor out a few things to a five.z3cform and have plone.z3cform import from it as appropriate. I just relicensed and moved plone.z3cform to the Zope repository: http://svn.zope.org/plone.z3cform/trunk/ Yay! Despite the plone namespace, it works fine in CMF and pure Zope 2. A namespace is just a name :). *Some* of the functionality (modules) is Plone or CMF specific. The default configure.zcml aims to be usable without Plone or CMF. There's a buildout.cfg in there that pulls Plone. I'd like to replace it with a Zope2-only one (and maybe move the existing buildout to another location). +100 The tests work without Plone. Awesome. By the way, I've collected a few conventions about maintaining software in svn.zope.org: http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-software.txt It would be nice if everything in svn.zope.org would adhere to these conventions. I'm just mentioning this since there may be some differences to Plone's conventions. ___ 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
