Hi,
I'm pasting a pile at the bottom of this. It's an intro to user
documentation. May or may not be useful for your situation. It's not
complete either because I tossed a section in the middle of it that
concerns parameters and never completed the thought. There area couple
paragraphs that might be worth something. I suggest a speed read.
> We have a number of student groups who have selected more or less nifty
> web related projects as their Final Year piece. Some of them decided to
> use midgard as the application server. In fact, I have pointed them to
> all sorts of other options (cocoon, zope, ariadne, ezpublish,
> php-only,...), because there is no standard answer what to use for which
> purpose, but those who will go for midgard have good reasons for their
> choice.
I hope you give them all As! :)
> midgard server for these students, because our sysadmins and tech
> support stuff is totally occupied with other very urgent problems. Just
> a few questions about what would you recommend:
If you go from source, I added Marius' rewrite of Azman's old install
document to cvs as part of the Midgard 1.4 manual. Someone did test the
doc and I believe Marius will make a couple edits.
> 1. Old admin site or asgard? (We do need sitegroups)
I'm partial to Asgard.
> 3. I have actually always used an installation --without-sitegroups, but
> I do understand all principle ideas about sitegroups.
What I'm pasting probably applies to gaining an understanding of the
concepts. Mostly just introductory level.
Ron
BTW, this is written for Asgard
--------------------Intro to User Docs-------------
Introduction
Midgard is a content management and publishing solution. It's the sum
of many applications that produce an environment for designing Web
applications and serving content. Administrating a Midgard server and
designing applications requires an understanding of these parts. This
document examines the parts within the scope of the requirements and
solutions that define the application titled MOVE which is a Web news
reporting site with many contributers. The practicle aspects, code and
step-by-step instructions, are intended to familiarize users with
concepts. While it is not the intent of this study to build an
application through a series of step-by-step instructions this does
happen. It's most important to understand the Midgard principles that
make MOVE a well designed application. Theoretical concepts are
treated with analogies that compare the objects of Midgard to those of
a building.
The MOVE entry page serves articles, headlines, author bylines,
images, story abstracts, and links to full stories. This is a
relatively simple set of requirements. But what happens when the MOVE
stock holders tell the publisher to extend the publication by allowing
visitors to select localized news sources? Because Midgard
applications are built with objects that can be shared, it's possible
to reuse and extend the objects which controls redundancy. If the MOVE
Page tree is designed so it can fulfill the requirements of additional
and related publications, it's a waste of resources to duplicate it.
The first concept to understand is SiteGroups.
For the moment, consider SiteGroups (SG) to be buildings and the Page
tree to be the internal phone service for a building. Obviously the
phone service must be shared throughout the entire building. The look
or color of the rooms is managed with the Style system. The Midgard
Style system is extendible which means that while the building
exterior is painted with one color the interior rooms can be treated
with distinct colors that meet their requirements. Of course well
painted buildings and rooms must be furnished. Imagine one of the
suites within the building to be occupied by a book store. The shelves
are Topics that hold books which are Articles. Because the
Topic/Article tree is shareable, it's reasonable to have duplicate
copies of books located in many different rooms or in another suite
within the building. This is all fine except for the fact that one
book store in a building isn't necessarily an interesting proposition.
The stockholders want a greater return on their investment.
Accomodating the stockholder request will not create redundancy
because Midgard objects can be shared. If the Page tree is the phone
service and telephone communications are required in a newly occupied
suite, the requirement is fulfilled by connecting a new phone system
to the existing telephone network.
Consider http://www.move.com as the primary publication. The publisher
is required to serve localized news for many communities. The solution
is to attach parameters to Hosts and fetch the parameter which
declares the requirement. If a client living in Paris, France wants
the weather report from MPLS, MN the client indicates which weather
report they're interested in recieving. The client's selection sets
the parameter. If the client hasn't set a parameter, the default
weather report based on a parameter for the host they request is
served. If the request is for http://www.move.com/fr/ the weather
parameter will retrieve weather for France. Of course this scenario
requires client account where their choices are stored.
The move-root page has three page-elements titled columnists, news,
and page-init. The news page-element does two things, it retrieves all
the articles within a specific topic and it calls a code-snippet that
produces a weather report. If the new publication requires the same
news articles and the same weather report, the work of writing the
code for this page is already done. If the current news page-element
doesn't retrieve the necesarry information, then the Page tree can be
extended by adding a new element that retrieves the correct data. In
general, the pages within the tree contain PHP scripts that are
designed to retrieve data. If an existing Page already gathers the
required data then a new page which performs the same task useless.
The challenge of filling every suite of the building returns us to
considering SGs to be buildings with an infrastructure of objects that
can be shared within the building but cannot be shared with other
buildings or SGs. As important as it is to share objects, it's equaly
important to control what resources users can access and edit. At the
level of the building or SG, the user either has a key and can enter
or they're denied access.
Upon gaining access to the building, users can read everything. They
can walk the hallways, peer through the windows of the internal suites
and see all the contents. While the user key unlocks the entry door
for the building, the key must be ground to open locks that lead to
suites where the person needs to edit an object. This is done by
making the "person" a member of the Group that owns the objects. In
Midgard terminology, authentication permits read access to all objects
owned by the root and its sub-groups. Write permissions are determined
by which objects are owned by specific groups. Using MOVE as an
example, when the person is a member of the group "columnsists"
they're able to edit records which are owned by that group. Unlike
normal users the head of building maintainance, root Group
administrator, has a master key that grants write permissions to every
object in the building.
Using MOVE as an example, assume that all articles are owned by the
group news and that columnists and news reporters are all lumped into
this group. This is all fine and dandy except that a rogue columnnist,
opinion writer, has edited news report articles by interjecting their
opinions into them. While the damage is done, an additional layer of
control can be designed to prevent further problems. Based on this
experience, the publishers have defined a new set of requirements that
state; no person shall have write priveleges to articles that they're
not responsible for. The MOVE root administrator proposes a solution
to the requirement that states; every person will have their own
group, be a member of that group, the Topic/Article tree will be a
mirror of the Group tree where Group X owns Topic X and consequently
all articles within the Topic.
Beyond studying the fundamental concepts of Midgard, the goal is to
build a series of small documented example sites that demonstrate
Midgard functions that are interesting to Web masters. Users are
encouraged to incorporate the samples and code from these studies into
their projects. A document titled "Requirements for MOVE" is included
as a sample article in the MOVE site. In addition to defining the MOVE
requirements it demonstrates one method for defining projects prior to
writing code.
If you're the root administrator of a Midgard server the first step in
building new Hosts is to create a SiteGroup that will own the Host and
its objects. After building and successfully testing the SiteGroup and
Host, you'll then study the relationship between Midgard and Apache
and the process of dynamic page building. References to concepts that
are beyond the scope of this document, but are examined in the Midgard
developer documentation, are provided throughout this study.
_________________________________________________________________
Managing Write Permissions and Object Trees
The first requirement for building new hosts is to have a SG that owns
the Page tree and its objects. Within the SG are Groups that own the
Host, Style, Topic, and Snippet object trees. These groups have
members or persons that inherit the right to edit objects that are
owned by the Group. For instance if the Style tree is owned by group
"style", then any member of the Group "style" can edit documents
within the "style" element tree. A SG can be thought of as a virtual
database that restricts user access to records that are owned by the
SG. All users must, with the exception of the Midgard root
administrator, specify a SG when loging into the administration site.
An example of the usefulness of SGs is an ISP that must prevent
distinct customers from reading each other's records. SiteGroups can
own more than one Host.
The Midgard Administrator, root, is the only person, account, that has
the authority to build new SGs. Within Asgard the steps to build the
new SG move are:
* login as root
* username; admin
* password; ******** (root administrator password)
* select Sitegroup from the top menu
* select Create Sitegroup
The Create Sitegroup interface includes three fields; name, realm, and
admingroup. For the purpose of this study, specify the name "move" in
each of the three fields. After submitting the form, the root
administrator relogs into Asgard as the administrator for the Group
move:
* username; admin*move
* password; ******** (root administrator password)
Specifying admin*move when logging in and then creating the Person,
Host, Style, and Topic objects causes ownership of these objects to be
assigned to the Group move. If "*move" isn't specified in the username
login field, all the objects created will belong to SG0 and
consequently they can be read by the world. While there are cases when
objects should belong to SG0 i.e. sample styles, example sites, this
is not the purpose of the MOVE study.
Assuming that the Midgard root administrator is adding a SG and Host
which is being developed by another Web developer, the task of adding
additional Group and Person records becomes the responsibility of a
MOVE administrator. Any person that's a member of the Group "move" can
log into Asgard by specifying username+move. To fulfill this scenario
the next task is to add a person record and then assign that record
membership to the move group. From the administration interface, as
admin*move:
* select; Group/Person,
* select; move
* select; List all persons
* select; New Person
* fill in required fields
* submit the form
The next task is to add this person to the move group which makes the
person an administrator of the Group move which of course is owned the
the SG move.
* select Group/Person
* select move (SG)
* from the "Members" window, select the person record that you added
* submit the form
The requirement that determines the design strategy for Group and
Person objects is; to deny and grant write permissions within the
Page, Topic, Style, and Snippet object trees. Each Person must have
write privileges to the object trees they're responsible for while
being denied write authority within all other objects. It's likely
that the MOVE administrator does not want an opinion writer to edit
the PHP code of the move-root page-element "columnists".
News reporters and opinion writers are treated as distinct categories,
so the Topic/Article tree requires seperate Topics for each of them.
They're logically named "news_reporters" and "columnists". Because
ownership of Topic nodes can only be assigned to Groups, each writer
requires their own Group. To ease the MOVE administrators job of
maintaining order within the Topic/Article tree each writer has a
Topic that's assigned the same name as their Group, i.e. a Group name
"guerizec" is certain to have a member who's name is "guerizec" so
within the Topic tree there will be a Topic named "guerizec" which of
course is owned by the like named Group.
_________________________________________________________________
Building the Host
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
