[ZDP] Discussion of ZDP tool implementation
Maik Roeder
roeder@berg.net
Tue, 21 Dec 1999 20:45:47 +0100
Hi !
I am posting my answers to the email of Tom Deprez,
because the discussion is really getting interesting.
Maik
Version 0.6 21 Dec 1999 (Just the top part)
Todo:
1. Decide which activity information is public, private or
internal.
2. Start thinking about keywords and categories for documents
Discussion:
1. Discussion on State of Involvement
I wanted to drop the original design of a state of
involvement,
and make it freetext instead of creating a selection from a
list like "On holiday", "Working", and so on.
Tom Deprez <tom.deprez@village.uunet.be> asked how we can
now
create an activity view of the members. He wondered if it
would
be necessary to search through all documents and look at the
writer/editor name of the documents. He also noted that this
is
a problem without bounds, because we not only have simple
documents,
but also members who only do graphics and members which
maintain
the webpage and so on.
Positive about selection lists:
1. We can easily search all Member ZClasses with ZCatalog
and extract the information.
We have other ways to track the activity of members. If we
create
news items when members are active, then this information
can
also be kept in a ZClass and searched by a ZCatalog. This is
even
more reliable than a selection list !
Negative about selection lists:
1. People will have a restricted set of choices
We could define many choices and still not cover all
possibilities. We could also reduce it to "active",
"semi-active"
and "active", but then again we can make a selection list of
numbers from 1 to 10, where 1 means not interested at the
moment
and 10 means highly interested and working really hard. I
don't
like any of these possibilities.
Positive about free text:
1. People can explain better their current state of
involvement
Negative about free text
1. We can not easily say from free text whether a member
is active or not.
As I said, we only need to track the activity, and find a
metric for rating the involvement. We only need to discuss,
how much of these activity information is public and what
information is internal.
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.
3. Do we need a personal page anyway ?
Tom Deprez <tom.deprez@village.uunet.be> stated that members
don't need to make a personal page, because they can do this
at
www.zope.org.
4. Do people upload drafts or are they kept in the member folder
?
I intended to keep the Documents of a person inside their
member folder as long as the Writer is the Maintainer.
Tom Deprez <tom.deprez@village.uunet.be> said that writers
do write drafts locally, but when they want people to read
a draft, they upload it.
This seems to be a good idea, because once a draft is
published,
it can not vanish just because a member deleted their home
folder.
This goes well the idea of having intelligent member pages,
which is idea 1 further down.
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.
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.
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
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.
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.
Ideas:
1. Intelligent Member pages
Tom Deprez <tom.deprez@village.uunet.be> said it would be
interesting to have member pages which are not really kept by
the members themselves, put which is created automatically
from
the information of their 'member' ZClass and the search
through
all the documents.
2. Look at FlexFAQ for ideas on Comments inside Documents
I wanted to have Documents as containers which can contain a
Comments ZClass which can hold Documents of type Comment.
Tom Deprez <tom.deprez@village.uunet.be> noted that FlexFAQ
already does something similar and that we should have a
look at it.