diff options
| author | hukl <hukl@eight.local> | 2009-02-08 15:30:34 +0100 |
|---|---|---|
| committer | hukl <hukl@eight.local> | 2009-02-08 15:30:34 +0100 |
| commit | aa5835072148a372b653f5f7ef0d9370b56bea99 (patch) | |
| tree | b3951e667843c43ae983cb4bed0378e213a99f55 /doc/README_FOR_APP | |
| parent | 56306be42c3cb6bfd0501d69e0f3a1842c8f5989 (diff) | |
merged documentation
Diffstat (limited to 'doc/README_FOR_APP')
| -rw-r--r-- | doc/README_FOR_APP | 99 |
1 files changed, 38 insertions, 61 deletions
diff --git a/doc/README_FOR_APP b/doc/README_FOR_APP index ef03d13..5d280f3 100644 --- a/doc/README_FOR_APP +++ b/doc/README_FOR_APP | |||
| @@ -4,8 +4,9 @@ CCCMS | |||
| 4 | 4 | ||
| 5 | ===Nodes | 5 | ===Nodes |
| 6 | 6 | ||
| 7 | The structure of the cccms is built from Node objects which live within a nested | 7 | The whole structure of the website is built from nodes. They live within a |
| 8 | set. Therefor a given node has parents, children, descendants etc. | 8 | nested set structure. Therefor a given node has parents, children, descendants |
| 9 | etc. | ||
| 9 | 10 | ||
| 10 | The position of a node within the nested set corresponds directly to the URL | 11 | The position of a node within the nested set corresponds directly to the URL |
| 11 | under which that node is accessible: | 12 | under which that node is accessible: |
| @@ -15,7 +16,7 @@ root | |||
| 15 | \__2009 | 16 | \__2009 |
| 16 | \___ultra_important_news | 17 | \___ultra_important_news |
| 17 | 18 | ||
| 18 | => http://domain/de/updates/2009/ultra_important_news | 19 | http://domain/de/updates/2009/ultra_important_news |
| 19 | 20 | ||
| 20 | Note that the first parameter after the domain is the locale. Everything after | 21 | 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 | the locale identifier is the unique path of a given node. The unique path itself |
| @@ -28,25 +29,42 @@ 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 | 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 | lot faster then walking down the tree. |
| 30 | 31 | ||
| 32 | Nodes are really just proxy objects. They point to information but they don't | ||
| 33 | hold that information themselves. Instead they have pages associated to them. | ||
| 34 | When you want to render a particular node, you actually render a page associated | ||
| 35 | to that node. When multiple pages are attached to a node, they act as one page | ||
| 36 | with many revisions. The node itself holds the pointer to current or head | ||
| 37 | revision. | ||
| 38 | |||
| 31 | ===Pages | 39 | ===Pages |
| 32 | 40 | ||
| 33 | As the nodes only built the structure, another object is necessary to actually | 41 | Although there is really one Page class, the pages associated to one node differ |
| 34 | hold all the contents. This object is called a page and is associated to a node | 42 | slightly. Obviously there is a slight difference between the head and the other |
| 35 | via a one-to-many association. A node can have multiple pages associated to it. | 43 | revisions. While the head is always the most recent page which is publicly |
| 36 | The node is actually a proxy for the pages behind it, and the pages act as a | 44 | available, all the older revisions are only kind of a history. |
| 37 | versioned page. By default, if you retrieve a node from the database by its | 45 | |
| 38 | unique path and ask this node for a page, the node would return the most recent | 46 | Now when a user wants to modify or edit the content of the head revision he or |
| 39 | one. It is also possible to get a page from a node, supplying a revision number. | 47 | she is editing a new revision instead. This new revision is considered a draft |
| 40 | The node object would then retrieve the associated page with the corresponding | 48 | and has the current content of the head revision copied onto itself. |
| 41 | revision number. For convenience purposes, the most recent page revision, in | 49 | |
| 42 | the scope of a node, is flagged as the head of this collection. This is | 50 | ====Draft |
| 43 | primarily for making certain queries a lot easier where you only want to select | 51 | |
| 44 | upon the current pages in the db rather than on all. | 52 | A draft has an author attached to it which makes sure that only the creator of |
| 53 | that draft is able to edit it. This is a form of pessimistic locking as it | ||
| 54 | prevents more than one user from editing and saving the same page. | ||
| 55 | |||
| 56 | However, if an author should choose to abandon his draft or to let somebody else | ||
| 57 | finish it, the author can withdraw his lock. In this case, the draft has no | ||
| 58 | longer an author associated to itself which enables another user to edit this | ||
| 59 | draft. | ||
| 60 | |||
| 61 | To abandon or revert a draft, the author can also delete it entirely so that | ||
| 62 | when another user is editing, he or she would get a fresh copy from the current | ||
| 63 | head revision. | ||
| 45 | 64 | ||
| 46 | It is important to know that all the associations of a page, such as tags, | 65 | Of course a admin user can always override or remove locks on drafts. In case |
| 47 | authors etc, must be copied one a new revision of a page is created. The Page | 66 | an author created a draft but simply didn't care anymore, an admin could remove |
| 48 | class is providing a deep_copy method to make sure everything important is | 67 | that draft or the lock on it, enabling other users to edit that page again. |
| 49 | copied. | ||
| 50 | 68 | ||
| 51 | ===Tags | 69 | ===Tags |
| 52 | 70 | ||
| @@ -93,45 +111,4 @@ extract db/updates.tbz | |||
| 93 | start a script/console and execute the following commands: | 111 | start a script/console and execute the following commands: |
| 94 | 112 | ||
| 95 | i = UpdateImporter.new("#{RAILS_ROOT}/db/updates") | 113 | i = UpdateImporter.new("#{RAILS_ROOT}/db/updates") |
| 96 | i.import_xml | 114 | i.import_xml \ No newline at end of file |
| 97 | |||
| 98 | =============================================================================== | ||
| 99 | Node | ||
| 100 | |||
| 101 | The whole structure of the website is built from nodes. They live within a | ||
| 102 | nested set structure. Nodes are really just proxy objects though. They point to | ||
| 103 | information but they don't hold that information themselves. Instead they have | ||
| 104 | pages associated to them. When you want to render a particular node, you | ||
| 105 | actually render a page associated to that node. When multiple pages are attached | ||
| 106 | to a node, they act as one page with many revisions. The node itself holds the | ||
| 107 | pointer to current or head revision. | ||
| 108 | |||
| 109 | Page | ||
| 110 | |||
| 111 | Although there is really on Page class, the pages associated to one node differ | ||
| 112 | slightly. Obviously there is a slight difference between the head and the other | ||
| 113 | revisions. While the head is always the most recent page which is publicly | ||
| 114 | available, all the older revisions are only kind of a history. | ||
| 115 | |||
| 116 | Now when a user wants to modify or edit the content of the head revision he or | ||
| 117 | she is editing a new revision instead. This new revision is considered a draft | ||
| 118 | and has the current content of the head revision copied onto itself. | ||
| 119 | |||
| 120 | Draft | ||
| 121 | |||
| 122 | A draft has an author attached to it which makes sure that only the creator of | ||
| 123 | that draft is able to edit it. This is a form of pessimistic locking as it | ||
| 124 | prevents more than one user from editing and saving the same page. | ||
| 125 | |||
| 126 | However, if an author should choose to abandon his draft or to let somebody else | ||
| 127 | finish it, the author can withdraw his lock. In this case, the draft has no | ||
| 128 | longer an author associated to itself which enables another user to edit this | ||
| 129 | draft. | ||
| 130 | |||
| 131 | To abandon or revert a draft, the author can also delete it entirely so that | ||
| 132 | when another user is editing, he or she would get a fresh copy from the current | ||
| 133 | head revision. | ||
| 134 | |||
| 135 | Of course a admin user can always override or remove locks on drafts. In case | ||
| 136 | an author created a draft but simply didn't care anymore, an admin could remove | ||
| 137 | that draft or the lock on it enabling other users to edit that page again. \ No newline at end of file | ||
