[Zope-PTK] Tabular object workflows

[Kent Polk]

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? :^)