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
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 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
[Zope-CMF] Generic Setup metadata.xml
Hi, When providing a metadata.xml file, GenericSetup's registerProfile directive crashes if 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] 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: ..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
Re: [Zope-CMF] Re: Add forms and menus
5-, but also harder to understand for newbees since someone needs much more base knowledge to adopt it. imo this should be considered a little more when improving things. to keep not always the simplicity at framework side but rather in using it from the developers and integrators pov which was much about the success of plone. but thats beyond this thread. 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 -- 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 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
Am Mittwoch, den 16.07.2008, 16:24 +0200 schrieb Daniel Nouri: > Robert Niederreiter writes: > > 2 more properties on the fti (addforminterface, schemainterface), both > > are optional, but provide then the discussed and requested flexibility > > for different type implementations. > > If you copy a FTI, you can probably reuse the add and edit forms > available for the type you're copying. > > If you're using a different schema, you'll write filesystem code anyway. > In which case it's easy enough to register another add and edit form. > This will also avoid redundancy with the proposed addforminterface and > schemainterface FTI properties in the case of custom add and edit forms. > And it'll make it obvious to the developer where to hook in to customize > the default forms. > > > 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!). > > As soon as whatever default form that's provided by the framework > doesn't work for you, you're back to "stupid and ugly subclassing", > which I don't think has to be stupid and ugly at all. In fact, I > believe that using subclassing or utility functions in these forms will > lead to more understandable code here. > > 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. > > > 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 -- 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 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, 11:33 +0200 schrieb Robert Niederreiter:
> 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 , 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')
>...
even here could be one more place for generalizing.
addiface = getattr(fti, 'addinginterface', ICMFAddForm)
and then lookup addview with addiface.
>
> > - 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
___
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,
> 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 , 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 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/+/' looks much prettier than > >>>> the URLs needed with my approach: > >>>> > >>>>foo/?form.portal_type= > >>>> > >>>> 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
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/+/ ? > >>> 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/+/' looks much prettier than > the URLs needed with my approach: > >foo/?form.portal_type= > > 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
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/+/ ? > > > > 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
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/+/ ? 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, 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
