[Zope-PTK] Tabular object workflows

[Tres Seaver]

Kent Polk wrote:
> 
> Sorry if there wa a problem here, but I read this through Ty's
> mail/news gateway and since I didn't receive a response I was
> thinking that either it got lost or I didn't frame my questions
> well enough for someone to know what I was talking about.
> 
> Do you have any more thoughts on how to intend to implement drop-in
> workflows yet? I mention this because I have several workflow
> objects ready to start moving to zope and wanted to be compatible
> with where the CMS is headed.
> 
> One thing I am thinking about implementing that might be generally
> useful to us and possibly to someone else would be to workflow a
> tabular object, such as a spreadsheet.  This tabular object could
> use the current workflow concepts for now.  As mentioned below,
> I'll probably store the table data in sql, but it would be nice to
> fit it in a Results object stored in the zodb (see my comments on
> Tabula-like behavior in another message).
> 
> Thanks
> 
> On 14 Feb 2001 20:03:51 GMT, Kent Polk wrote:
> >On 13 Feb 2001 12:00:02 -0600, Shane Hathaway wrote:
> >>> Shane:
> >>> > It sounds like you want users to have "mini-portals".  Right?  Could you
> >>> > elaborate on the reason?
> >>>
> >>> Sigve:
> >>> You are perfectly right! The reason is quite simple. I am developing a
> >>> site for a "community", which consists of several sub-communities that
> >>> each want their own look and feel. These sub-communities should be members
> >>> of other communities.  The scope of news and events should be selectable,
> >>> so that important news should show up in the posted communitys "parent".
> >>
> >>What about the possibility of creating a new portal object for each
> >>user, then setting the request_varname for each portal_skins object to
> >>something like "sub_portal_skin"?  That way the user could vary the
> >>primary skin and the personal skin independently.
> >>
> >>Note that a portal object is, in fact, little more than a "skinnable
> >>portal folder".
> >
> >You lost me here.
> >By 'portal object', you don't mean a portal (new) instance, do you?
> >
> >What I want to do is to have several sub 'portal skins' that are
> >oriented toward managing different workflows. I'll get back to this
> >in a minute because I have a preceding question.
> >
> >Workflow objects...  I have several workflow objects somewhat
> >developed that currently reside outside of the PTKwhatever, because
> >I haven't figured out exactly where they fit. We're getting awfully
> >close to subworkflows here... These objects basically resemble a
> >tabular document with a lot of metadata and state information in
> >them. Currently the core tabular data is organized frighteningly
> >similar to a ZRDB.Results object. However,  I haven't decided how
> >I'm actually going to store the table data (probably SQL), but it's
> >convenient for now. most of my subworkflows will be oriented around
> >one of the tabular-looking objects.
> >
> >What I expect to do is to implement these tabular objects using
> >one of the PTKBase document classes somewhat as a template. AND,
> >I would like for all of these tabularish workflow thingies to use
> >the same base view interface where you could view these objects in
> >a heirarchical fashion (as subworkflows).
> >
> >Now (back to the original question) should I be looking to implement
> >this tabularish workflow view as a separate portal or just as a
> >separate skin for the current portal? I would hope for a separate
> >skin, because they are all related. Essentially one parent object
> >that represnets a project, and children which represent all of the
> >separate workflow tasks for that parent.
> >
> >Is it time yet to discuss subworkflows? :^)

Kent,

I owe you a longer response on this, but am a bit bandwidth-
constrained at the moment :)

The short answer is:  not quite yet.  We will ship CMF 1.0
without the highly-configurable, state-machine-driven workflow
tool which I have described in the past.  We are planning on
an iterative release process (likely with 4-6 week iterations)
following "1.0", and haven't yet decided how to roll that
tool out.

In the meantime, please have a look at the 'portal_workflow'
interface (in PTKBase/interfaces), and see if you think it
could serve as a wrapper around the kinds of workflows which
would scratch your itch.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@digicool.com
Digital Creations     "Zope Dealers"       http://www.zope.org