[Zope3-dev] factoryFromClass: for_container

[Gary Poster]

On Monday 15 April 2002 02:34 pm, Jim Fulton wrote:
> Gary Poster wrote:
> > The zcml for adding content factories should add a for_container so that
> > ...etc.
> Can we get this turned into a proposal at:
>
> http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Propo
>sals
>
> ???

Will do.

> Could you explain what a "creation marker" is? I don't follow this.

I bally-hooed pre-creation views a bit from March 28-April 3, based on 
http://lists.zope.org/pipermail/zope3-dev/2002-March/001232.html (and thread)
http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CreateFileFromFormInput
http://collector.zope.org/Zope3-dev/52
and IRC conversations on zope3-dev

The idea is that one should be able to collect data for instantiation of an 
object before the object is created at all, and use the view machinery to do 
so--what I called a "pre-creation view".  I implemented this by having marker 
interfaces for addables in the zmi; the "create" traverse namespace returns 
an addable with the appropriate marker interface, and then the view machinery 
finds a view registered for the special creation view marker interface.  
Ideally this will be automated better in the future: one person suggested 
simple string interfaces as a way to automate this.  For now, it seemed like 
an accepted way to proceed with useful functionality that could be polished 
later.

After positive feedback and nobody saying no, I implemented it on a 
(sub-)branch, developed the JobBoard to use it on a branch, and eventually 
merged it all, again with positive feedback and no negative feedback.  

> > If for_container is not specified, IContainer is assumed.
> >
> > This would allow addables to be cleanly associated with a container
> > interface, so that things like the JobBoard example, for instance, would
> > easily have only the one appropriate addable available to them; and so
> > that addables like Job would not appear in the standard addables list for
> > a basic container.
>
> I'm not sure that Job Boards would want to use this at all. Some containers
> don't need or want to be as flexible as folders.

Certainly, not everything is a full-fledged container, and maybe you are 
right in this instance.  However, the pre-creation views can handle this 
automatically, without Job Boards having to add any extra code, and it seems 
like an easy way to accomplish the task.

> > I think this should also be used for the services
> > "factoryFromClass"--this would allow ObjectHub plugins (or any other
> > service plugins) to use the addable/factory system, for instance. The
> > default for_container value for the service version would be
> > IServiceManager, or ILocalServiceManager, using my naming system from a
> > previous email.
>
> I agree that there's some generalization lurking here. I'd like to
> understand your generalization better.
>
> BTW, another way to approach this is to have containers say which kinds of
> things they are willing to contain, by specifying an interface that their
> items must support. Maybe this is related to what you are proposing.

Yes...maybe both directions would be worthwhile.  On first blush, I think I 
like my direction better if only one is chosen, though, since it could be 
controlled only in zcml.  Requiring an interface that contained items must 
implement would require intrusiveness in the python code of content objects, 
and Zope3 has been amazingly unintrusive so far.

> > It would also make sense to go ahead and implement the creation_markers
> > system for service factories and addables as well, I think.  That will be
> > virtually a non-task.
> >
> > If I haven't heard any negatives or alternate suggestions on this in a
> > couple of days then I'll proceed, both in adding for_container and in
> > renaming creator_markers.
>
> I think we need more than a couple days of silence before making a change
> this extensive.

Understood.  And as to the pre-creation views, of course I will accept the 
reponsibility for undoing this work if I misunderstood or unintentionally 
abused the process.  I hope I did not do so.

> In any case, please make this a proposal so we have a more permanent record
> of the discussion.
>
> Jim

OK.

Thanks.

Gary