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
136
137
|
CCCMS
==General
===Nodes
The structure of the cccms is built from Node objects which live within a nested
set. 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.
===Pages
As the nodes only built the structure, another object is necessary to actually
hold all the contents. This object is called a page and is associated to a node
via a one-to-many association. A node can have multiple pages associated to it.
The node is actually a proxy for the pages behind it, and the pages act as a
versioned page. By default, if you retrieve a node from the database by its
unique path and ask this node for a page, the node would return the most recent
one. It is also possible to get a page from a node, supplying a revision number.
The node object would then retrieve the associated page with the corresponding
revision number. For convenience purposes, the most recent page revision, in
the scope of a node, is flagged as the head of this collection. This is
primarily for making certain queries a lot easier where you only want to select
upon the current pages in the db rather than on all.
It is important to know that all the associations of a page, such as tags,
authors etc, must be copied one a new revision of a page is created. The Page
class is providing a deep_copy method to make sure everything important is
copied.
===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"
/>
git clone ssh://git@svn.medienhaus.udk-berlin.de/usr/local/git/cccms
git checkout --track -b poc1 origin/poc1
git submodule init
git submodule update
===============================================================================
Import all Updates from the old ccc.de site:
extract db/updates.tbz
start a script/console and execute the following commands:
i = UpdateImporter.new("#{RAILS_ROOT}/db/updates")
i.import_xml
===============================================================================
Node
The whole structure of the website is built from nodes. They live within a
nested set structure. Nodes are really just proxy objects though. 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.
Page
Although there is really on 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.
|
