[ZDP] Fw: Returned mail: User unknown
Tom Deprez
Tom Deprez" <tom.deprez@village.uunet.be
Tue, 21 Dec 1999 21:48:45 +0100
> > 2. Design of Member ZClass
> >
> > I suggested the following structure for the Zope Web page:
> >
> > 1. /ZDP/Members
> >
> > A folder where we keep all the members, like Member1
> > and Member2 and so on.
> >
> > 2. /ZDP/Members/Member1/
> >
> > A folder of Member1, which does not yet have a
> > MemberInfo
> > ZClass, and maybe does not want one, maybe because he
> > does
> > not like being tracked ?
> >
> > 3. /ZDP/Members/Member2/
> >
> > Member folder of Member2
> >
> > 4. /ZDP/Members/Member2/MemberInfo
> >
> > Member2 has already created the MemberInfo service,
> > because
> > he wants to make his personal information visible to
> > the other members.
> >
> > 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
>
> ...
>
> > 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?
>
> >
> > 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.
>
> > 6. Why all these ZClasses ?
> >
> > Tom Deprez <tom.deprez@village.uunet.be> asked why we need
> > all these ZClasses. Aren't boolean properties for the
> > Document Container enough ?
> >
> > Tom pointed out the following positive things about
> > Boolean properties:
> >
> > 1. Showing a Document with it's properties is easier
> >
> > For example to show a Draft with some checkboxes
> > below where the member checks an editing checkbox,
> > which would do the same thing.
> > 2. People don't have to create ZClasses
> >
> > Instead of creating ZClasses people only have to check
> > checkboxes.
> >
> > Tom also noted that documents must be a ZClass type of
> > container because they need to hold the comment ZClasses.
> > Tom wants to simplify things to the following:
> >
> > 1. DocumentFolder ZClass with properties :
> > - Boolean NeedsEditor
> > - Boolean NeedsApprover
> > - String CurrentApprover
>
> and all the other properties which are proposed.
>
> > 2. Content inside the DocumentFolder
> > 3. Comment ZClass inside the DocumentFolder
> > - name
> > - email
> > - content
> >
> > Tom sais, that according to some checked boxes, others can't
> > be choosen, and thus we can change some checkboxes to
> > radiobuttons.
> > Tom also noted that we need to keep the
> > editor/writer/maintainer
> > name, because this will help us when we make a search engine.
> > For example when we search all documents on which person X
> > has
> > worked and so on.
> >
>
> > Why we need all these ZClasses
> > ------------------------------
> >
> > We need Reader, Writer, Editor and Approver ZClasses. These
> > ZClasses are easy to store inside a DocumentFolder when
> > needed. The ZClasses not only contain properties like
> > NeedsReader, but also provide some services which manipulate
> > our domain objects.
> >
> > The Reader, Writer, Editor and Approver ZClasses know how
> > to manipulated the Documents. Documents can be XMLDocuments,
> > DTML-Documents, FAQs, Snippets, and so on. These domain
> > objects are thin objects, because they only have some
> > normal attributes and the rest are just aquired attributes.
> > The domain objects don't know what do do with themselves.
> > We manipulate them with special ZClasses like Reader, Writer,
> > Editor and Approver because the domain objects are dumb.
>
> Ah, this is something I didn't know.
>
> > 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 :-).
>
> Tom.
>
>
>