[ZDP] Discussion of ZDP tool implementation

[Maik Roeder]

Hi !


We are diving deeper into the realms of ZClass intrinsics
in this discussion...

> >            Tom Deprez <tom.deprez@village.uunet.be> asked whether we
> > need   a folder per member, when we can just add one ZCclass per
> > member  inside the Members folder.
> 
> With this I mean :
> 
> 1. /ZDP/Members/Tom
> 
> Tom is an instance of ZClass MemberInfo
> 
> 2. /ZDP/Members/Maik
> 
> Maik is an instance of ZClass MemberInfo

This is possible. The Member ZClass would have to inherit
Objectmanager, so members can manage objects inside the 
member folder. I think we already agreed on this issue.

> >         5. Why place extra ZClasses in a DocumentFolder as services ?
> >
> >            I wanted to give a Maintainer the possibility to place some
> >            services inside the DocumentFolder ZClass. For example a
> > Maintainer
> >            can place a Comments ZClass inside a Draft DocumentFolder.
> >            Or a Maintainer can place a Writers ZClass in a
> > DocumentFolder
> >            to call for Writers.
> 
> So, you want to say that when only a 'Comments' ZClass is inside a
> documentfolder, comments can be given?

Yes. Placing a Comments ZClass info a DocumentFolder means that an author
wants to have comments. He really just wants to raise awareness. There
are perhaps situations, in which an author does not want to hear comments
on a document. Perhaps if the document is very drafty.
 
> >            Tom Deprez <tom.deprez@village.uunet.be> pointed out that it
> >            would be enough to just keep a Boolean NeedsComments property
> >            in the DocumentFolder ZClass. He also said that these
> > ZClasses
> >            only contain one Property, which does not justify their
> >            existence.
> >
> >            We would need to make a Comments folder anyway when we want
> >            to keep the comments on this document. hen it is a good idea
> >            to make this Comments folder a ZClass that is CatalogAware,
> >            so we can easily search for Documents which need Comments.
> >            When there are enough comments for the moment, a Maintainer
> >            can still switch off the NeedsComments properties of the
> >            Comments ZClass.
> 
> mmm, you can also iterate the whole ZDP site for document folders which have
> the NeedsComment property checked.

There are different possible implementations. I just don't want
to produce fat domain objects. The power of objects is that you can break
the coupling which is inert to the application-centric, document-centric
thinking with fat domain objects. 

(I am not saying that I fully understand the postings of Jim Salmons,
as I am not an expert in role-based executable business modelling,
but very much of my thinking is influenced by the following Email
from August 1999 by Jim Salmons on the ZDP mailing list:
http://lists.zope.org/pipermail/zdp/1999-August/000601.html
)

> >            What is special about our Documents is that they are contained
> >            in a DocumentFolder, which has not been part of the problem
> >            domain, because we did not bother in outr problem description,
> >            that Documents can consist of multiple parts with additional
> >            graphics and so on. DocumentFolders are a construct of the
> >            solution domain, where they help us in keeping all the different
> >            parts that make a document together.
> >
> >            So, we place the possible Actions into special ZClasses,called
> >            Reader, Writer, Editor and Approver, which are only executable
> >            by Persons who have special Roles. The Person who has a Role can
> >            execute the actions to change the real state of the domain objects.
> >            Actions also change states which are maintained in the ZClasses,
> >            which are really just wrappers on the domain objects.
> 
> I don't know if I can follow your description here, also I'm not sure how
> this can be implemented, but I think you know :-).

Let's look at an example:

When a Member with the Role Editor wants to work on a Draft, he just signs in.
   - The NeedsEditor Property of the Editor ZClass is deactivated. 
   - The Editor's name is being added to the list of editors
   - An Email is sent to the Maintainer of the Document 

We have a DocumentFolder in which the Maintainer of a Draft 
work has placed an Editor ZClass. This means the Maintainer
wants to allure Editors for editing the Document.

When an Editor signs in, he executes an Action. This Action
triggers a method of a ZClass. The Method works through
different Tasks. The first Task is changing a Property
of the ZClass, the second is adding the Editor's name to
a list od Editors, and the final Task is sending an Email
to the Maintainer of the Document.

You can see that an Editor ZClass already has many things to
do. I wouldn't want to put all these Services into the DocumentFolder.
In the end, you also would have to place all the services for
the Reader, Writer and Approver ZClasses into the DocumentFolder
ZClass. 

I am not sure about one thing here: Would it be a good idea
for the DocumentFolder to inherit from Reader, Writer, Editor
and Approver ZClasses ? This way, all the services would
always be there potentially, and we would not need to 
bother about placing the ZClasses _inside_ a DocumentFolder.

Comments are welcome !

Maik