[Zope-CMF] Zope component model and CMF

[Kent Polk]

Shane Hathaway wrote:
> On Tue, 17 Jul 2001, Kent Polk wrote:
> 
> > On 5 Jul 2001 14:20:00 -0500, Shane Hathaway wrote:
> > > http://dev.zope.org/Wikis/DevSite/Proposals/ApplyComponentModelToCMF
> >
> > ->To accomplish this, the portal root will have a __bobo_traverse__() method
> > ->looks for a traversal adapter appropriate to the content being traversed.
> > ->CMF tool that would have all of the necessary information for supplying a
> > ->traversal adapter is the portal_actions tool. Currently it looks for object
> > ->actions, workflow actions, and discussion actions to supply a list to the
> > ->actions box. In fact, in order for the proposed "memento bags" idea (see
> > ->zope-cmf@zope.org) to work with discussions, discussions will need to be
> > ->implemented with modified travers
> >
> > Would this be able to address my problem with implementing proxy
> > folderish items (a lot like your Transparent Folder behavior),
> > where each proxy client is associated with a particular proxy
> > (server)?
> 
> Yes, I think so, although if you have described the details of this
> concept before, I cannot recall them at the moment.

Basically, I have a series of tabular document objects which need
to participate in workflow. The tabular data associated with these
items is obtained via a series of sql/dtml/python methods where
the sql/dtml methods need to be instantiated and customized for
different projects, installations. Each CMF 'tabular document' of
a particular meta-type can use the same set of methods, so a folder
of these things, along with some python code is the general idea.
However, it is far easier to implement these as a CMF folderish
item (which even needs to have it's own workflow during creation)
which the tabular documents explicitly acquire behavior from.

Problem is that the CMF's way of handling URL's gets in the way of
adding the folderish item to the URL (rightfully so, IMO). My
tabular document methods can explicitly call the folderish item
(proxy) as long as the calls aren't nested, which won't really
work. Your Transparent folders comes close to solving this, but
since there are a series of these folders, I need to explicitly
acquire the proxy folder by meta-type (and preferably even run-time
configure, in case of multiple ones of the same meta-type), which
poses a problem with Transparent Folders.

->So, tentatively, traversal adapters will check for a fixed name such as talkback
->for traversal to the discussion container, and if it's not the fixed name then
->they will ask the workflow service for the name of a presentation component from
->which to look for views, then ask the skins service for presentation names from
->either the workflow presentation component or the object presentation component.
->Traversal adapters will come from the portal_actions service.

I was hoping that I could configure your traversal adaptor to
provide my proxies as a presentation component (folderish) or just
rewrite the proxies to be a regular presentation component (maybe
prefered?).

> > Will the new content view components be set up for folders also,
> > so that folderish objects can participate in being able to have
> > their view methods changed? Please, Please, Please
> 
> Yes, that's one of the points I've been hammering too.

Yeah!

> > Any idea of the timeframe? If soon, I will just suspend my hacking
> > on these things and work on other issues, like workflow with Ulrich
> 
> It's a high priority.  We're still discussing some of the details.  Here
> is something posted just this morning:
> 
> http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CMFContentTypeDesign

->For interfaces created in Python modules, we can store interfaces by reference.
->For persistent interfaces, storing by reference requires special handling. If a
->simple persistent reference is used, then the interface will be copied wheever
->the object is copied. If a named reference is used, then a name registry needs
->to be maintained, which adds a lot of complexity.

Doesn't look good for sql methods, have you thought of them as
interfaces? I'm having a little trouble identifying exactly what
'things' Jim would classify as a marker interface. BTW, equality
comparisons is how I initially though the Types tool was implemented
- I though they behaved somewhat like aliases. It kinda threw me
at first that it was still needing to use specific ids.

> > We are still trying to figure out how to implement project-centric
> > workflow for the CMF, in addition to document-centric workflow.
> 
> What are your current obstacles?  Do they consist of what you listed
> above?

The project-centric workflow stuff is mostly separate from the
obstacles mentioned. We're still struggling with basic concepts
right now. I suspect you'll be hearing more from us in the near
future with thought about how to accomplish objectives. If you have
any ideas on how to accomplish a project-centric workflow via CMF,
we'd sure like to hear them. Problems are that a project-centric
workflow needs to be able to create and manage CMF documents (which
can have their own workflow). Requires associations that we are
having trouble defining.