1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
=CCCMS
==Setup
* git clone git://github.com/hukl/cccms.git
* git submodule init
* git submodule update
* create a database.yml in /db
* rake db:migrate
* untar db/updates.tbz
* rake cccms:create_admin_user (admin:foobar)
* rake cccms:import_updates
* rake cccms:create_home_page
* ./script/server to start the webserver
==Documentation
User stories in doc/success_stories.txt
execute: rake doc:app on the command line to get a html api documentation in
doc/app
==General
===Nodes
The whole structure of the website is built from nodes. They live within a
nested set structure. Therefor a given node has parents, children, descendants
etc.
The position of a node within the nested set corresponds directly to the URL
under which that node is accessible:
root
\__updates
\__2009
\___ultra_important_news
http://domain/de/updates/2009/ultra_important_news
Note that the first parameter after the domain is the locale. Everything after
the locale identifier is the unique path of a given node. The unique path itself
is generated from the slugs of the ancestors of a node. The last part of the
unique path is taken from the slug of the node.
Once a node is added to the nested set or moved within, the unique path of that
node is generated from all its ancestors up to the root node. The computed path
is then saved on the node object itself, allowing the system to retrieve a
node simply by looking for the right url in the unique_path column. This is a
lot faster then walking down the tree.
Nodes are really just proxy objects. They point to information but they don't
hold that information themselves. Instead they have pages associated to them.
When you want to render a particular node, you actually render a page associated
to that node. When multiple pages are attached to a node, they act as one page
with many revisions. The node itself holds the pointer to current or head
revision.
===Pages
Although there is really one Page class, the pages associated to one node differ
slightly. Obviously there is a slight difference between the head and the other
revisions. While the head is always the most recent page which is publicly
available, all the older revisions are only kind of a history.
Now when a user wants to modify or edit the content of the head revision he or
she is editing a new revision instead. This new revision is considered a draft
and has the current content of the head revision copied onto itself.
====Draft
A draft has an author attached to it which makes sure that only the creator of
that draft is able to edit it. This is a form of pessimistic locking as it
prevents more than one user from editing and saving the same page.
However, if an author should choose to abandon his draft or to let somebody else
finish it, the author can withdraw his lock. In this case, the draft has no
longer an author associated to itself which enables another user to edit this
draft.
To abandon or revert a draft, the author can also delete it entirely so that
when another user is editing, he or she would get a fresh copy from the current
head revision.
Of course a admin user can always override or remove locks on drafts. In case
an author created a draft but simply didn't care anymore, an admin could remove
that draft or the lock on it, enabling other users to edit that page again.
===Tags
Pages of course come with meta data attatched to them. Tags are one kind of
meta data. They can be understood and used as keywords, categories, tags or any
similar concept.
===Templates
Althought there is only one, simple and unified, template for editing pages, it
is possible to select from different templates for public display. This
selection of templates allows slight alterations of the layout. For example one
template would display every attribute of a page (like date, author, abstract)
while another template would hide this information away. One would show the tags
of a page, another wouldn't.
===Aggregation
Keywords and other meta data can be used to aggregate any ammount of pages
into the body of another page.
<aggregate
tags="update pressemitteilung"
limit="20"
order_by="published_at"
order_direction="DESC"
/>
===Permissions
The permission system is geared towards our use-case which means you won't find
the standard create/update/destroy derived permissions.
Every user without having any permissions is allowed to perform non-destructive
tasks that won't affect the frontend (published pages). What am I talking about?
Bob has no permissions whatsoever still he is allowed to edit a #Page anywhere,
because this action will only create a new revision of the #Page which is not
immediately published. He won't be able to manipulate a #Node in any way
(unique_name, slug, ordering, structure) because this would affect the frontend
without further notice.
Having a #Permission on a #Node makes Bob an admin for this #Node and all it's
children. Now Bob can do pretty much anything on these nodes including such fun
things as:
- Create/Update/Delete a #Node
- Reorder children of the #Node
- Rejecting a draft and telling the author to get his/her spelling right.
- Clear a stale lock on a #Node
|
