Thinking about the concept of roles is really the best
conceptual input to the docs i heard so far.
Yes, i have the instant feeling, that your list of
roles is highly significant. That should be taken
into account when going into the newbies documentation ...
thanks alot for this contrib !!!!
regards, hussayn
Tony Collen wrote:
On Mon, 27 Jan 2003, SAXESS - Hussayn Dabbous wrote:
therefore we started this "newbies competence center" approach.
i personnaly whish, that eventually the whole cocoon documentation
will be better separated into developers issues and users issues,
where my definition (biased from the discussions) is a bit fuzzy:
user: *uses* the given infrastructure as is
developer: *creates* his own add ons to given infrastructure
Hrmm... this gives me an idea, tell me if you follow along:
Cocoon was developed with SoC in mind. You have the content separated
from the style, and you have the logic of the site separated from the
content.
So, instead of trying to define what a user is and what a developer is, we
should define the different roles that a person would have when using or
developing with Cocoon.
For instance, with a typical installation of Cocoon, we could define the
following roles:
- Content Creator. This person authors XML for the site to be
transformed. This role works when most of the content is static.
However, if a lot of the data is being pulled out of a database, they
would be in charge of something like data entry into the database, etc.
- Graphic/Web designer. This person is in charge of the style of
the site. Not only do they come up with how the site looks through the
design of the final HTML, but they also write the XSL to transform the
content into the desired format. Sometimes this person is also the
content creator.
- Administrator. In charge of the servlet container, and
modifying the main sitemap. Monitors logs, and able to identify
when a component would need to be cacheable, poolable, etc. Sometimes
this role can further be separated out into servlet container admin and
sitemap admin.
- Programmer. I think this is what we now call "developer" --
this person is capable of developing custom components, e.g. Generators,
XSPs, etc. This person might also code the Flow layer logic. But maybe
not.
Ideally, all of these roles work together in order to get things done, but
they only have to worry about their specific role.
Now that we have defined roles, its easy to classify the documentation we
have now. Obviously, the content creator doesn't have to worry about
performance issues, so perhaps that info would go into the Administrator
section. Likewise for information about logging. Conversely, people
writing a custom generator obviously fall into the Programmer category,
and they would probably know not to have to stumble into the
"Administrator" section.
To sum up, Cocoon was developed with SoC in mind. IMHO, the current
documentation managed to comingle the concerns, so we ended up with 4 or 5
different places that something could go. If we mirror the SoC model in
the documentation, I think we'll end up with some successful and useful
docs.
Regards,
Tony
--
Cocoon: Internet Glue (A Cocoon Weblog)
http://manero.org/weblog/
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
--
Dr. Hussayn Dabbous
SAXESS Software Design GmbH
Neuenhöfer Allee 125
50935 Köln
Telefon: +49-221-56011-0
Fax: +49-221-56011-20
E-Mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
