[Zope3-dev] A possible component architecture interpretation ofworkflow

[Garrett Smith]

I wish I could provide more systematic feedback (much to take in) --
comments below are sporadic, where thoughts occur to me.

Jim Fulton wrote:
> Here is a longish collection of thoughts on workflow that I've been
> working on for a while.  I'd like to get some feedback on them,
> before I pursue prototypes and, eventually a proposal.
...
>      The most common sort of user event is someone submitting a form.
>      Perhaps browser view directives (view, page, pages, xxxform, ...)
>      will grow button directives::
> 
>         <page
>            name="foo.html"
>            ...
>            />
> 
>            <button name="update"
>                    event=".FooUpdate"
>                    subscriber=".myupdatehandler"
>                    />
> 
>            <on event="zope.app.form.browser.Updated"
>                redirect_to="index.html" />
>            ...
>         </page>

This looks pretty cool. It would be nice to support form methods to
handle button events. E.g.

  class MyForm(SomeBaseInputForm):
      def onUpdate(self, event):
          self.update()
          notify(Updated(self))

  <page name="foo.html" class=".MyForm" ...>

      <button name="update"
          handler="onUpdate" />

      <on event="zope.app.form.browser.Canceled
                       zope.app.form.browser.Updated"
          redirect_to="index.html" />

  </page>

Very minor points:

- I use 'handler' since it's not really a subscriber.

- A form update is so common, it would be somthing provided in a base
class. 

- Multiple events are handled in a single redirect.
  
>    Generic states
> 
>      We might want to model states generically.  So, for example,
>      rather than having "draft locked" and "review locked", we might
>      have just "locked". This means we want to register views for
>      multiple interfaces.  For example, we might want to register a
>      view for locked and draft.  We can accomplish this with
> multi-adapters. 
> 
>      Let's say we want to find an edit view, 'edit.html'.  We register
>      an edit view factory for IUnlocked. This view then dispatches to
>      a multi-view:
> 
>        def UnlockedEdit(context, request):
>             return zapi.getMultiView((context, context), request,
>                                      name='edit.html')
> 
>      We should automate this with some ZCML changes.  Maybe something
>      like:
> 
>         <browser:page
>             name="edit.html"
>             for=".IReport"
>             state=".IUnlocked"
>             ...

I guess I'm struggling to see how workflow is a necessary part of
presentation. I could see something like this:

        <workflow:page
            name="edit.html"
            for=".IReport"
            state=".IUnlocked"
            ...

No doubt prototyping will help my grokkage.

>    -  WFMC compatibility.
> 
>       The WFMC reference model provides a conceptual model *not* an
>       implementation blue print.  It defines systems, such as a
>       "Workflow Enactment Services" or "Workflow Engines" not to
>       specify specific implementation components, but to provide units
>       of functionality that a workflow implementation can be expected
>       to provide.  I think that, in Zope 3, it is important to keep
>       this distinction in mind, so that we can arrive at a workflow
>       model that is well integrated with th rest of the Zope 3
>       architecture.  At a lower level, the WFMC specifies specific
>       objects, such as processes, activities and process
>       instances. These are a bit more concrete because the WFMC
>       provides interchange APIs and formats to allow
>       process-definitions to be exchanged between systems and to
>       support other forms of system inter-operation.  While we may
>       need to support these models at system boundaries to support
>       interchange, I think it would be a mistake to constrain the
>       internal implementation to follow these models to closely.

I would underscore your last sentence.

I think DC metatdata is an example of putting a 'standard' in front of
practical implementation (e.g. we dont store 'last modified by' because
it doesn't map to a DC element). It's better to add in compatibility
later.

Overall, a huge post ;-) I'm far from getting my head around this, but
no doubt the prototyping stage will be fruitful. It would be nice to
recruit some workflow gurus for feedback along the way. Wish I knew some
:-)

 --Garrett