Show last authors
1 {{include document="XWiki.DesignClassSheet"/}}
2
3 Describes the design for the new XWiki Model module.
4
5 = Design Decisions =
6
7 These decisions are being implemented here: [[https:~/~/github.com/xwiki/xwiki-platform/compare/feature-newmodel>>https://github.com/xwiki/xwiki-platform/compare/feature-newmodel]] (was previously in [[https:~/~/github.com/xwiki-contrib/sandbox/tree/master/xwiki-model>>https://github.com/xwiki-contrib/sandbox/tree/master/xwiki-model]]).
8
9 * Notions of:
10 ** multi wiki
11 ** wiki
12 ** space
13 ** document
14 ** document metadata (language, syntax id, etc)
15 ** document objects
16 ** document classes
17 * UUIDs for al Entities
18 * Ability to have multiple references pointing to the same entity
19 ** Entity renames and deletes still allow referencing the new entity using the old reference
20 * All entities are directly adressable (ie have a reference)
21 * Nested spaces
22 * Ability to add metadata to model objects
23 * Easy to use API (typed API)
24 * Observation: Events when entities are modified/created/removed
25 * Ability to choose storage: RDBMS, file system, etc
26 * Query is done in a different module
27 * save() is deferred and saves in batch
28 * Attachments should be objects
29 - needs ability to choose storage per object definition property
30 * The Object definition notion exist (and extend Object)
31 - need editor specific to object types (for having a class editor for ex)
32 - object property can be an object
33 - ability for an object definition to extend another object definition
34 * Several objectdef per document
35 * Conflicts; an entity is modified in 2 differents sessions
36 - overwrite for the moment
37 - future: merge + exception if cannot merge
38 * Isolate modifications by thread to start with (maybe Session in some future but not sure)
39 * Be able to use old model API in // with new model API (for // run), using the old model implementation.
40 - We don't plan to be able to use the old API with the new model implementation
41 - Implement new model API using old core and throw exception when we cannot implement a feature
42 * Be able to implement new model API using JCR
43 * Global versioning
44 * An Entity can be a pointer to another Entity (e.g of use case: rename, aliases)
45 * All Entities (Document, Wiki, Space, etc) are Objects (extend Object)
46 - eg document metadata are stored as object properties
47 - bonus: that will give us an editor for entity metadata
48 - bonus: entity metadata will all have their own references
49 * save() is done in a transaction, i.e. if one DB operations fails, all are rolled-back
50
51 = Open Decisions =
52
53 * Do we want: Wiki.getSpaces(Filter)?
54 - ex: wiki.getSpaces(new NameFilter("a.*")) => all spaces starting with a
55 Answer: Yes but in a different module, not in Model. either in Query module or in another LINQ-like module.
56 * How to handle Version, Language?
57 * Notion of lazy loading for object definition properties? (eg: load an attachment object without loading the attachment content itself)
58 * Ability to version model objects
59
60 * Authentication/Authorization to be decided
61 ** Should checks be done outside of the model module?
62 ** Should we use JAAS and if so what's the relationship
63 * Ability to lock model objects to prevent modifications in some cases (when someone is already modifying them or if the wiki is in readonly mode for example)
64 * (to be continued)
65
66 * Ability to version the whole repository when a change is made (SVN-like) and hence the ability to restore the state across documents/spaces/etc
67 ** Ability to install an application and remove it simply by doing a simple rollback even when the app is made of several documents
68
69 = Implementation Details =
70
71 {{warning}}
72 What's below is just some idea, a bit oldish now but still interesting
73 {{/warning}}
74
75 Use JCR for the following interesting features:
76
77 * Referenceability of nodes, UUID
78 * Transactional
79 * Versionable (whole trees). JR283 enhances on the versioning set forth in JSR170 by specifying four versioning models, simple versioning, full versioning, activities, and configurations.
80 * Lockable
81 * Import/Export (in XML format)
82 * Can support inheritance
83 * Supports observation
84 * Utilizes JAAS for authentication. Authorization is not explicitly outlined, the specification leaves it up to the repository vendor to implement a specific permission model. While the API defines a rudimentary permission check for node operations, there is no way to set permissions based on users, groups, and roles. JSR283 greatly improves in this area.
85 ** [Pluggable security model that can maintain ACL at object level>http://whiteboardjunkie.wordpress.com/2008/11/24/where-am-i-using-jcr-and-why/]
86 * JSR 283 (JCR 2.0) further introduces the concept of shareable nodes which allows multiple paths of access to a node, providing the ability to implement faceted navigations through content
87 * JSR 283 further introduces the concept of journaled listeners which can ask the repository to re-play all events after a certain timestamp
88 * Shareable nodes.(((
89 > In JSR170, a node can only be the child node of one other node. This makes it impossible to file nodes under multiple taxonomies, i.e. defining multiple paths to get to the same node. JSR283 hence introduces the (optional) concept of shareable nodes.
90
91 This allows implementing multiple URIs for a given model object.
92 )))
93 * "Primary child item" feature. {quote}Any one of a node's child items may be specified as its primary child item. This item can be directly accessed (without knowing its name) with the method Node.getPrimaryItem(). The primary item of a particular node (if it has one) is declared in its node type.{quote}. This could allow for example a document to have a default view for displaying its content.
94
95 * Mapping:
96 ** Wiki = Workspace
97 *** We cannot have Wiki = Repository since there's no inter repository operations and we want for example the ability for a given wiki to include a document from another wiki
98 *** Allows clone nodes between wikis and support references between wikis (children wiki can have references to admin wiki documents for example)
99 *** UUID are unique per repository (and not per workspace)
100 *** A node with the same UUID in several workspaces point to the same Node
101 *** Note: one version storage per repository
102 *** Ability to call Node.update(String srcWorkspace) to replace this node by the one and its children from the srcWorkspace (same as svn update)
103 *** We can still have the ability to clone a wiki (and thus clone a workspace) to provide a working branch (for example for staging a workspace) and then later on do an update (as in svn update) to merge the changes back into the main "trunk"
104 ** Document = Node + special NodeType
105 ** Document metadata = Property
106 ** Space = Node + special NodeType
107 ** Document objects = Node + special NodeType (subnode of Document)
108 ** Document object properties = Propery
109 ** Document classes = Node + special NodeType (subnode of Document)
110 ** Document class property = Property
111 ** Attachment = Node + special NodeType (subnode of Document)
112 ** Attachment data/metadata = Property
113
114 * Advantages of using JCR:
115 ** Standardized
116 ** Existing implementations (JackRabbit, exo JCR, etc)
117 ** Ability to use existing tools that act on JCR:
118 *** [[JCR Explorer>>http://www.jcr-explorer.org/screenshots.html]]
119
120 * Idea: Use workspaces to provide editorial workflow:(((
121 > At the core of the specification is the concept of the repository. A repository contains any number of workspaces. While a simple repository usually only contains one workspace, a repository can contain any number of workspaces. A workspace is essentially a view into the repository. The same content items may appear in multiple workspaces, some content items may only be present in one workspace. Workspaces can be thought of work-in-progress areas of a repository, much like a scrapbook. Content is always created in a workspace and may then be propagated into another workspace.
122 )))
123
124 There are many potential uses for multiple workspaces. For example, one can use workspaces in a similar way to branches in a source control system (even though as we will see later, the JCR provides versioning separately). A group of content editors work locally in a workspace and when their work is completed, the finished work can be submitted into a central workspace.
125
126 Workspaces could potentially also be used to differentiate between in-progress, QA, and live environments, where changes are propagates from one workspace to the other as they go through the editorial workflow.{quote}
127
128 = References =
129
130 * XWiki:
131 ** [[Initial Model Proposal on the dev list>>http://xwiki.markmail.org/message/5elx2g47g6m4blqw?q=model+Wiki+Farm]]
132 ** [[Document Name and Factory on the dev list>>http://xwiki.markmail.org/message/ebeafpu6gvhqdunq?q=DocumentName+DocumentNameFactory]]
133
134 * JCR:
135 ** [[Various JCR links>>http://wiki.apache.org/jackrabbit/JcrLinks]]
136 ** [[JCR Primer>>http://jtoee.com/jsr-170/the_jcr_primer/]]
137 ** [[JCR 1.0 API>>http://www.day.com/maven/jsr170/javadocs/jcr-1.0/]]
138 ** [[JCR 2.0>>http://jcp.org/en/jsr/detail?id=283]]
139 ** [[JCR: A Practictioner's Perspective>>http://www.theserverside.com/tt/articles/article.tss?l=JCRPract]]
140 ** [[Content Modeling for JCR>>http://dev.day.com/microsling/content/blogs/main/contentmodels2.html]]
141 ** [[Interesting JCR blog posts>>http://whiteboardjunkie.wordpress.com/category/jcr/]]

Get Connected