Re: [Zope-CMF] Re: Add forms and menus
Hi, maybe it's a little late to join this discussion. i read the thread and want to point some of my thoughts here. imo its a bad idea to depend on static zcml configuration for factory types. martin did a nice approach in his portlets engine with a name traverser when calling a generic adding view. i took this idea and the adding mechanism of devilstick works this way as well and depends on the fti too. so a call of foo/add/portal_type returns an add view for requested type. doing it this way would even work if someone renames a portal_type for some reason without the needs to modify or overwrite any existing zcml, because the traverser simply tries to read the fti of ``portal_type``. to make custom add views available there could be a new attribute in the fti which contains the name of a custom add view to look up. the traverser could then first lookup if a custom add view was set (this has to be configured static with zcml anyway) and looks it up by its name or returns the default add view. as an alternative this could also be done by aliases. im not sure if it is desirable to alter the IAdding mechanism with something like a simple view. at least i see no reason for implementing 'yet another adding mechanism'. in the end a quick question. isn't the portal_factory itself obsolete if a clean adding mechanism is working then and the only thing to maintain further the fti stuff? i did not studied z3c.form yet, so no statement to this from my side. regards robert ___ 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
hi martin, Am Montag, den 14.07.2008, 21:31 +0100 schrieb Martin Aspeli: Hi Robert, maybe it's a little late to join this discussion. i read the thread and want to point some of my thoughts here. imo its a bad idea to depend on static zcml configuration for factory types. martin did a nice approach in his portlets engine with a name traverser when calling a generic adding view. I'm not quite sure I follow here. The portlets machinery just looks up the add view in a utility that stores its name, and then invokes it. There's a custom analog to IAdding called +portlet to keep the namespace separate. you post i.e. /++contextportlets++plone.rightcolumn/+/portlets.Login as action for adding a portlet and let your ITraversable implementations perform what to do in plone.app.portlets.browser.traversal.py. thats imo a nice approach i took this idea and the adding mechanism of devilstick works this way as well and depends on the fti too. so a call of foo/add/portal_type returns an add view for requested type. How's that different to foo/+/factory-name ? not that much. i only wanted to say that there might be no need to register a seperate addview/form for every portal type. having the type name it should be possible to get the schema interface of the requested type, so it's possible to provide a generic addview/form. this interface lookup, and addview/form instanciation might be done then in a traverser, that's the most 'zopeish' solution imo. doing it this way would even work if someone renames a portal_type for some reason without the needs to modify or overwrite any existing zcml, because the traverser simply tries to read the fti of ``portal_type``. Mmm right. Local components work here too, of course. to make custom add views available there could be a new attribute in the fti which contains the name of a custom add view to look up. the traverser could then first lookup if a custom add view was set (this has to be configured static with zcml anyway) and looks it up by its name or returns the default add view. as an alternative this could also be done by aliases. I'm not sure you need the traverser, though, if you have a standard way to generate the list of URLs for the add view, but maybe I'm missing something? im not sure if it is desirable to alter the IAdding mechanism with something like a simple view. at least i see no reason for implementing 'yet another adding mechanism'. Having the add view be a view for a view (i.e. the context of the real add view is not a content object) is sometimes quite painful. until someone got the clue :). yes you're right here, constructs like ``aq_inner(self.context.context)`` and similar simply look ugly. but on the other hand, if you kick this construct, you have to provide another mechanism which is responsible to finally add what has to be added. if this is more elegant then...? in the end a quick question. isn't the portal_factory itself obsolete if a clean adding mechanism is working then and the only thing to maintain further the fti stuff? Plone's portal_factory has nothing to do with this, but yes, we want to rip the damned thing out. great Martin robert ___ 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
Hi, Am Dienstag, den 15.07.2008, 08:53 +0100 schrieb Martin Aspeli: Hi Robert, imo its a bad idea to depend on static zcml configuration for factory types. martin did a nice approach in his portlets engine with a name traverser when calling a generic adding view. I'm not quite sure I follow here. The portlets machinery just looks up the add view in a utility that stores its name, and then invokes it. There's a custom analog to IAdding called +portlet to keep the namespace separate. you post i.e. /++contextportlets++plone.rightcolumn/+/portlets.Login as action for adding a portlet and let your ITraversable implementations perform what to do in plone.app.portlets.browser.traversal.py. thats imo a nice approach Ah, I get you. Actually, the ++contextportlets++plone.rightcolumn bit is a namespace traversal adapter that addresses a particular portlet manager (which is basically an ordered container); + is an IAdding view (actually, an IPortletAdding view) registered for the portlet manager container. portlets.Login is the name of the add view for a particular portlet. So, this approach is identical to (and borrowed from) the old Zope 3/ZMI approach that you have an add view that is a statically registered view for IAdding. The adding view is *not* generic. Each portlet registers its own add view. We have a formlib-based base class though. i know, but the fact that portlets have it's own add view has nothing to do with the fact that the traverser is responsible for the magic. Now, I think this is fine for portlets, since it's relatively easy to register this add view (there's a single ZCML directive to register all portlet-related information), and portlets are not like portal types (there's no persistent FTI that can be cloned). i took this idea and the adding mechanism of devilstick works this way as well and depends on the fti too. so a call of foo/add/portal_type returns an add view for requested type. How's that different to foo/+/factory-name ? not that much. i only wanted to say that there might be no need to register a seperate addview/form for every portal type. having the type name it should be possible to get the schema interface of the requested type, so it's possible to provide a generic addview/form. Right. That's probably a reasonable default (and is, in effect, what Dexterity does as well, although it registers add views as local adapter factories that know their portal_type). this interface lookup, and addview/form instanciation might be done then in a traverser, that's the most 'zopeish' solution imo. This is quite an interesting approach, actually. After traversal, what is self.context in the add form? Is it the form, or the 'addview' traverser thing? depends on what your traverser returns :). consider such an url and the default formlib behaviour: foo/+/Folder '+' is the IAdding implementation, which is actually nothing else than a 'factory', but without creating anything like the old behaviour of the portal_factory. now it's possible to register an IPublishTraverse implementation for this specific IAdding implementation (could also be anything else than IAdding if you want to get rid of it). this traverser then does the FTI lookup, the schema interface lookup und creates and returns the addform. in this step you can modify the context of addform as needed. here is how its done in devilstick: http://dev.plone.org/collective/browser/devilstick/devilstick.browser/trunk/devilstick/browser/traversal.py line 71+ so, to follow your intention, there would be some browserpage altering the factory. for this factory then an IPublishTraverse implementation is registered. inside the traverser you can do something like context = aq_inner(self.context.context) form = getMultiAdapter((context, self.request), IMyFancyAddFormWithoutIAdding, name='whatever') return form.__of__(context) this ensures the right context in the right acquisition chain. Having the add view be a view for a view (i.e. the context of the real add view is not a content object) is sometimes quite painful. until someone got the clue :). yes you're right here, constructs like ``aq_inner(self.context.context)`` and similar simply look ugly. but on the other hand, if you kick this construct, you have to provide another mechanism which is responsible to finally add what has to be added. if this is more elegant then...? The final 'add' operation can be done by a base class for the view. That's how Yuppie's formlib thing works, and how z3c.form prefers to work. self.context.context can be majorly painful, though. For example, look at http://dev.plone.org/plone/browser/plone.app.vocabularies/trunk/plone/app/vocabularies/workflow.py. Here, we need to acquire something, but since the context may be the IAdding view, we have to do this
Re: [Zope-CMF] Re: Add forms and menus
Am Dienstag, den 15.07.2008, 12:43 +0200 schrieb yuppie: Robert Niederreiter wrote: i took this idea and the adding mechanism of devilstick works this way as well and depends on the fti too. so a call of foo/add/portal_type returns an add view for requested type. How's that different to foo/+/factory-name ? not that much. i only wanted to say that there might be no need to register a seperate addview/form for every portal type. having the type name it should be possible to get the schema interface of the requested type, so it's possible to provide a generic addview/form. Right. That's probably a reasonable default (and is, in effect, what Dexterity does as well, although it registers add views as local adapter factories that know their portal_type). this interface lookup, and addview/form instanciation might be done then in a traverser, that's the most 'zopeish' solution imo. This is quite an interesting approach, actually. After traversal, what is self.context in the add form? Is it the form, or the 'addview' traverser thing? depends on what your traverser returns :). consider such an url and the default formlib behaviour: foo/+/Folder '+' is the IAdding implementation, which is actually nothing else than a 'factory', but without creating anything like the old behaviour of the portal_factory. now it's possible to register an IPublishTraverse implementation for this specific IAdding implementation (could also be anything else than IAdding if you want to get rid of it). this traverser then does the FTI lookup, the schema interface lookup und creates and returns the addform. in this step you can modify the context of addform as needed. here is how its done in devilstick: http://dev.plone.org/collective/browser/devilstick/devilstick.browser/trunk/devilstick/browser/traversal.py line 71+ I like pretty URLs, and 'foo/+/MyPortalType' looks much prettier than the URLs needed with my approach: foo/AddViewName?form.portal_type=MyPortalType Your proposal has some advantages. On the other hand this requires to create CMF specific code and patterns in a place where a more generic solution also works. it does not if you call a formfactory inside the traverser, so it's hoohable for CMF, Plone or whatever even with different formlib implementations. like: formfactory = getAdapter(context, IFormFactory, name='factoryNameFromFti') return factory() which handles all the magic in there. just a thought. Would anyone volunteer to implement this (including unit tests) if we decide to choose that approach? Cheers, Yuppie robert ___ 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 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 Dienstag, den 15.07.2008, 22:34 +0100 schrieb Martin Aspeli: Daniel Nouri wrote: Daniel Nouri writes: Robert Niederreiter writes: yuppie writes: I like pretty URLs, and 'foo/+/MyPortalType' looks much prettier than the URLs needed with my approach: foo/AddViewName?form.portal_type=MyPortalType Your proposal has some advantages. On the other hand this requires to create CMF specific code and patterns in a place where a more generic solution also works. it does not if you call a formfactory inside the traverser, so it's hoohable for CMF, Plone or whatever even with different formlib implementations. like: formfactory = getAdapter(context, IFormFactory, name='factoryNameFromFti') return factory() which handles all the magic in there. just a thought. If I understand this correctly, it should be more like: formfactory = getMultiAdapter((context, request), IAddForm, name='factoryNameFromFti') My suggestion is rubbish. First, it should be 'form', not 'formfactory'. Then, I realize it's not the same pattern since your factory is supposed to do some work before it passes on control (I believe?) whereas mine is the add form class itself. right. it was meant as a step in between to fit yuppies suggestion on beeing generic at this point. Both patterns require the same amount of registrations. As many for IFormFactory as for IAddForm. What's worse is that the implementations will have a hard time to work reusably without the portal type name, which they're registered with. What about the traverser does this: try: view = getMultiAdapter((context, request), IAddForm, name=factory_name) except ComponentLookupError, e: view = getMultiAdapter((context, request), IAddForm) view.factory_name = factory_name return view() In this case, the adapter/form would actually have a chance to work for more than one portal type. How does this sound? even better. It still feels a bit fishy to me. I don't really see why you need a traverser *unless* you're trying to have a single add form implementation that covers multiple types. i.e. if you have one content type, i.e. a folder, but you want to use exactly this type with different workflows, names, icons, then this makes indeed sence. here you might simply add another fti, and its done. adding such a type is then either invoked like @@add/Folder or @@add/AnotherFtiForFolder, but both return the same form. You may of course have that, and maybe it's helpful to let people write that, but I think most people would prefer to write plain add views that use the standard z3c.form patterns. its possible anyway, isn't it? the advantage is that there's one way how adding works in general. and the discussion is still about implementing a generic adding mechanism in CMF. as i pointed in a previous post, there should be the possibility to do customization. so as convention it might be done this way. * lookup fti for ``portal_type`` * have a look if theres a custom view set. * if so, do lookup with this name * if not, try lookup with ``portal_type`` as name * finally do general lookup if others failed. thats also why i tried to introduce IFormFactory, because the traverser might not need to know too much. but thats maybe a bit too far...? For something like Dexterity, where we explicitly want to support generic content with a schema that varies according to runtime configuration, this is more of an issue. But even there, the intention is that whilst the framework has a few hooks like this so that it works with content that's more malleable, it doesn't force you to use unconventional patterns if you do something yourself on the filesystem. the goal should be the various IFormFactory hooks, so you might not need to change the way you write addforms in general, but to provide a specific IFormFactory implementation for a specific framework. (dexterity, devilstick, archetypes, whatever). as an alternative the magic could be done in the traverser directly, but then there must be different traversers for each framework and different 'add' browserpages where those traversers could be bound to. this would then look like this for invoking: @@+cmf/``portal_type`` @@+ds/``portal_type`` @@+dx/``portal_type`` @@+at/``portal_type`` ... which of them to call in the add dropdown must be stored then i the fti. In the case above, you end up having to register your form as a particular adapter rather than a browser view. That's fairly unnatural, and also doesn't necessarily deal with things like security settings. It makes the add view quite different to write than the edit view, too. all the forms can be registered as browserpages anyway (and should
Re: [Zope-CMF] Re: Add forms and menus
Hi,
So, let me try to summarise what I think we're saying here:
- My type has a form like:
class MyAddForm(CMFBaseAddForm):
fields = form.Fields(IMyType)
portal_type = 'My type'
- The base form knows to look at self.factory_name to look up the
factory when it does the create() call.
- The base add form implements ICMFAddForm
- I register the form as a normal browser:page /, with the
convention that the name is the same as the factory name
- The FTI has an 'addview' property, which by convention is set to
string:${folder/absolute_url}/@@add/${portal_type}
- The @@add view looks like
class AddView(BrowserView):
implements(IPublishTraverse)
def publishTraverse(self, request, name):
portal_types = getToolByName(self.context, 'portal_types')
fti = getattr(portal_types, name)
factory = fti.factory
addview = getMultiAdapter((self.context, request), ICMFAddForm,
name=factory)
addview.portal_type = name
return addview
A few things to note about this:
- The traverser doesn't call the view, it just returns it (the
publisher will call it when it needs to)
- We don't look up a default, unnamed add form view. This doesn't make
any sense unless we really can generalise all forms; frameworks like
Dexterity may have a way to do this and thus may be able to have their
own versions of @@add, but I don't think this something we should do at
the CMF level.
+/-
i would provide a default add form anyway. consider how archetypes
works. you never write an addform (especially because there are
none :)). for most of the usecases default sequencial add forms fit
quite fine. so for most usecases even the registration for the add form
is lost code lines.
to provide this, the CMFBaseAddForm simply has to provide one more
property.
class CMFBaseAddForm(BrowserView):
@property
def fields(self):
portal_types = getToolByName(self.context, 'portal_types')
fti = getattr(portal_types, self.portal_type)
return form.Fields(fti.schema)
the publishTraverse function of AddView then would do something like:
...
factory = fti.factory
try:
addview = getMultiAdapter((self.context, request),
ICMFAddForm,
name=factory)
except ComponentLookupError, e:
addview = getMultiAdapter((self.context, request),
ICMFAddForm,
name=u'cmfdefaultadd')
...
- This doesn't require any more registrations than the simple add form
browser view.
see above. this registration would be then the first possible
customization step if desired.
- If I don't want to use this idiom, I could change that TALES
expression to something like string:${folder/absolute_url}/@@add-my-stuff
I quite like this approach now. ;-)
great :)
Martin
Robert
___
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 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 Mittwoch, den 16.07.2008, 13:04 + schrieb Martin Aspeli: Robert Niederreiter [EMAIL PROTECTED] writes: +/- i would provide a default add form anyway. consider how archetypes works. Not necessarily an example to follow, though, is it. :) you never write an addform (especially because there are none :)). for most of the usecases default sequencial add forms fit quite fine. so for most usecases even the registration for the add form is lost code lines. I'm not so sure about that, because ... to provide this, the CMFBaseAddForm simply has to provide one more property. class CMFBaseAddForm(BrowserView): @property def fields(self): portal_types = getToolByName(self.context, 'portal_types') fti = getattr(portal_types, self.portal_type) return form.Fields(fti.schema) Here you assumption is that that schema is saved on and returnable from the FTI. This is a pretty fundamental change to the way CMF and CMF types work. First of all, it requires that the FTI can know the schema, which will probably mean storing the dotted name of the schema somewhere or inferring it from something else (a class, or the factory - the IFactory interface actually has some support for this). Now, I'm not actually against this. Dexterity works in this very manner (it has a lookup_schema() method that works a bit like the schema property above, and can source the schema from a number of different places including TTW-only configuration, a filesystem file or a real filesystem interface via a dotted name). If some of that could be pushed down to CMF, then of course that'd be great - less code to be kept in Dexterity. But I'm not sure CMF wants to swallow that much of an architectural change at this stage. it's not that big architectual change. everything else discussed is possible anyway. i would rather call it a feature than a design change (since the change happens anyway). we discuss the generic adding approach, we further discuss what has to be considered to be generic. 2 more properties on the fti (addforminterface, schemainterface), both are optional, but provide then the discussed and requested flexibility for different type implementations. if we do not consider this questions at this state, again the result will be stupid and ugly subclassing and incompatibility and bad readable code and overrides.zcml (which is one thing i really hate!). Also note that defaulting to form.Fields(fti.schema) is probably not enough. Many forms, at least, will require custom widgets, and settings like groups and so on. Dexterity has a way for the schema interface to give hints for how it will be rendered (using tagged values) and a (fairly hairy) algorithm for including them, but I won't actually recommend that pattern for general purpose filesystem code (it's necessary for the case where you have pluggable UI that source schema fields from multiple sources - again something that's probably not in scope for base CMF). right, therefor you always have the possibility to write your own form implementation. If we want to be true to the tradition of Zope 3 and its simplified content types metaphor, then I think we should assume that a type consists of: - a class - a schema interface - an add form/view - an edit form/view plus the FTI to install it into the CMF site. I wouldn't try to be too clever and generalise away any of these. i don't try to generalize, i try to simplify. and i think such default behaviour is benefit in any way. i simply wonder why people should write code for default behaviour when there can be a default implementation. i only want to point here to the plone portlets engine. why is it necessary to provide 4 (!) classes, a template and a zcml configuration for 1 portlet? thats imo too much, especially because people are familiar with and love the 'write-less-do-more' mentality, and adherence to a tradition is not automatically more productive or easier to understand. Robert Martin ___ 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 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 Mittwoch, den 16.07.2008, 15:57 + schrieb Martin Aspeli: Daniel Nouri [EMAIL PROTECTED] writes: Robert Niederreiter writes: Am Mittwoch, den 16.07.2008, 16:24 +0200 schrieb Daniel Nouri: Where would we need overrides.zcml? in the case where ICMFAddForm is no longer my interface to look up. then i have to overwrite the traverser. Why would ICMFAddForm no longer be the interface to look up? It's the the only type of add form that promises to do something meaningful with the 'portal_type' attribute that's set on it in the traverser. And even if it weren't - we shouldn't hardcode the traversal adapter. We should make this a convenient implementation option. The actual URL of the add view should configurable via a TALES expression, which means that it can be written without the @@add bit. sure Martin ___ 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 -- Robert Niederreiter IT-Architecture Engineering Aflingerstraße 7 A-6176 Völs +43 699 160 20 192 +43 512 89 00 77 Squarewave Computing WEB APPLICATIONS, ZOPE, PLONE, HOSTING BlueDynamics Allianceproduction: concept, development, design http://squarewave.at consulting: analysis, coaching, training http://bluedynamics.com management: projects, process, community ___ 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
-- Robert Niederreiter IT-Architecture Engineering Aflingerstraße 7 A-6176 Völs +43 699 160 20 192 +43 512 89 00 77 Squarewave Computing WEB APPLICATIONS, ZOPE, PLONE, HOSTING BlueDynamics Allianceproduction: concept, development, design http://squarewave.at consulting: analysis, coaching, training http://bluedynamics.com management: projects, process, community ___ 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 Donnerstag, den 17.07.2008, 13:03 +0200 schrieb Charlie Clark: Am 16.07.2008 um 17:24 schrieb Martin Aspeli: I think it's a fairly big shift to assume that the FTI has knowledge of the schema of the type. It's not necessarily a *bad* idea (at least I don't think so, since this is basically how Dexterity works :-), but right now, FTI doesn't have any notion of a schema. With this change, you're effectively dictating (or strongly suggesting) that all CMF types have a schema and that this is the basis for forms, and suggesting that forms aren't registered as independent views but rather inferred from this schema. Indeed. It is reasonable to expect a subclass to provide a set of FormFields but this is not the same as a schema. We have found being able to handle portal_type and schema or fields ie. an instance FormFields() in the super class to avoid repeated use of the somewhat cumbersome FormFields(TextLine(__name__...)) code. we discuss the generic adding approach, we further discuss what has to be considered to be generic. I'm just not sure that generic is so good. If it's easy to make add- and edit- views (probably with convenience classes for CMFish container adding behavior) and obvious how to register them, then do you need more framework? At least not in CMFCore. Explicit is always better than implicit. This stuff really isn't a lot of work but it provides clarity and helps people understand what's going on and I think this is essential for any framework. Less magic is more power. ;-) sorry, but implementing something like: class Addform(AddformBase) fields = form.Fields(ISchema) and registering it then like: browser:page for=* name=myfactoryname class=.foo.Addform allowed_interface=Procucts.CMFCore.browser.interfaces.ICMFAddForm permission=add.whatever / ..does not give the newbee more clue on whats going on than write it not at all. robert 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 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] Generic Setup metadata.xml
Hi, When providing a metadata.xml file, GenericSetup's registerProfile directive crashes if dependencies/dependencies is provided as empty tag with a key error (GS v 1.4.1) ___ 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] Generic Setup metadata.xml
https://bugs.launchpad.net/zope-cmf/+bug/255301 regards robert Am Mittwoch, den 06.08.2008, 12:46 +0200 schrieb Wichert Akkerman: Previously Robert Niederreiter wrote: When providing a metadata.xml file, GenericSetup's registerProfile directive crashes if dependencies/dependencies is provided as empty tag with a key error (GS v 1.4.1) Can you submit a bugreport to launchpad? Wichert. ___ 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] [dev] add view traversal
Hi, o +1 on 'container/@@add/typename' this is my suggestion as well regards, robert ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
