[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.
>
>
>