diff options
| author | hukl <hukl@eight.local> | 2009-02-02 20:53:40 +0100 |
|---|---|---|
| committer | hukl <hukl@eight.local> | 2009-02-02 20:53:40 +0100 |
| commit | 9c793dd8b3adc8adb8d541b88a1f547e18937d14 (patch) | |
| tree | 806d18b081c410e511ee7e3dbf4e8a9234fded18 | |
| parent | 5a8c9154d504c5376e807716c0cfcb76ef766d88 (diff) | |
more concept text
| -rw-r--r-- | doc/README_FOR_APP | 52 |
1 files changed, 45 insertions, 7 deletions
diff --git a/doc/README_FOR_APP b/doc/README_FOR_APP index 9b76357..9f7133a 100644 --- a/doc/README_FOR_APP +++ b/doc/README_FOR_APP | |||
| @@ -1,14 +1,52 @@ | |||
| 1 | CCCMS | 1 | CCCMS |
| 2 | 2 | ||
| 3 | ==General | ||
| 3 | 4 | ||
| 4 | The basic structure of the cccms is built from Nodes. Nodes live within a | 5 | ===Nodes |
| 5 | nested set. When a arbitrary url is entered it is dispatched to the | ||
| 6 | ContentController action render_page. Based on the url parameters the | ||
| 7 | render_page action retrieves the corresponding Node from the database. Rather | ||
| 8 | than walking through the tree of the nested set to find the node, the Node is | ||
| 9 | retrieved directly by its unique_name which matches the url parameters. | ||
| 10 | 6 | ||
| 11 | So much for now yeah | 7 | The structure of the cccms is built from Node objects which live within a nested |
| 8 | set. Therefor a given node has parents, children, descendants etc. | ||
| 9 | |||
| 10 | The position of a node within the nested set corresponds directly to the URL | ||
| 11 | under which that node is accessible: | ||
| 12 | |||
| 13 | root | ||
| 14 | \__updates | ||
| 15 | \__2009 | ||
| 16 | \___ultra_important_news | ||
| 17 | |||
| 18 | => http://domain/de/updates/2009/ultra_important_news | ||
| 19 | |||
| 20 | Note that the first parameter after the domain is the locale. Everything after | ||
| 21 | the locale identifier is the unique path of a given node. The unique path itself | ||
| 22 | is generated from the slugs of the ancestors of a node. The last part of the | ||
| 23 | unique path is taken from the slug of the node. | ||
| 24 | |||
| 25 | Once a node is added to the nested set or moved within, the unique path of that | ||
| 26 | node is generated from all its ancestors up to the root node. The computed path | ||
| 27 | is then saved on the node object itself, allowing the system to retrieve a | ||
| 28 | node simply by looking for the right url in the unique_path column. This is a | ||
| 29 | lot faster then walking down the tree. | ||
| 30 | |||
| 31 | ===Pages | ||
| 32 | |||
| 33 | As the nodes only built the structure, another object is necessary to actually | ||
| 34 | hold all the contents. This object is called a page and is associated to a node | ||
| 35 | via a one-to-many association. A node can have multiple pages associated to it. | ||
| 36 | The node is actually a proxy for the pages behind it, and the pages act as a | ||
| 37 | versioned page. By default, if you retrieve a node from the database by its | ||
| 38 | unique path and ask this node for a page, the node would return the most recent | ||
| 39 | one. It is also possible to get a page from a node, supplying a revision number. | ||
| 40 | The node object would then retrieve the associated page with the corresponding | ||
| 41 | revision number. For convenience purposes, the most recent page revision, in | ||
| 42 | the scope of a node, is flagged as the head of this collection. This is | ||
| 43 | primarily for making certain queries a lot easier where you only want to select | ||
| 44 | upon the current pages in the db rather than on all. | ||
| 45 | |||
| 46 | It is important to know that all the associations of a page, such as tags, | ||
| 47 | authors etc, must be copied one a new revision of a page is created. The Page | ||
| 48 | class is providing a deep_copy method to make sure everything important is | ||
| 49 | copied. | ||
| 12 | 50 | ||
| 13 | 51 | ||
| 14 | git clone ssh://git@svn.medienhaus.udk-berlin.de/usr/local/git/cccms | 52 | git clone ssh://git@svn.medienhaus.udk-berlin.de/usr/local/git/cccms |
