Wiki source code of XWiki Model 2.0

Last modified by Vincent Massol on 2024/02/26 17:54

version	line-number	content
9.1	1	{{include document="XWiki.DesignClassSheet"/}}
3.1	2
9.1	3	Describes the design for the new XWiki Model module.
3.1	4
9.1	5	= Design Decisions =
3.1	6
13.3	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]]).
10.1	8
5.3	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
9.1	17	* UUIDs for al Entities
10.2	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
9.1	20	* All entities are directly adressable (ie have a reference)
3.1	21	* Nested spaces
	22	* Ability to add metadata to model objects
4.2	23	* Easy to use API (typed API)
9.1	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
5.5	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
5.8	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)
3.1	64	* (to be continued)
	65
7.1	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
9.1	69	= Implementation Details =
4.1	70
12.2	71	{{warning}}
	72	What's below is just some idea, a bit oldish now but still interesting
	73	{{/warning}}
8.9	74
8.7	75	Use JCR for the following interesting features:
12.2	76
8.7	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
9.1	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	)))
8.7	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.
4.1	94
5.2	95	* Mapping:
8.4	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
8.2	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)
8.4	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"
5.24	104	** Document = Node + special NodeType
5.2	105	** Document metadata = Property
5.24	106	** Space = Node + special NodeType
	107	** Document objects = Node + special NodeType (subnode of Document)
5.2	108	** Document object properties = Propery
5.24	109	** Document classes = Node + special NodeType (subnode of Document)
5.2	110	** Document class property = Property
5.24	111	** Attachment = Node + special NodeType (subnode of Document)
5.3	112	** Attachment data/metadata = Property
4.4	113
5.6	114	* Advantages of using JCR:
	115	** Standardized
	116	** Existing implementations (JackRabbit, exo JCR, etc)
	117	** Ability to use existing tools that act on JCR:
9.1	118	*** [[JCR Explorer>>http://www.jcr-explorer.org/screenshots.html]]
5.6	119
9.1	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	)))
5.22	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
9.1	128	= References =
5.9	129
5.5	130	* XWiki:
9.1	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]]
3.1	133
5.5	134	* JCR:
9.1	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/]]

Wiki source code of XWiki Model 2.0

About

About

Support

Platform

User Guide

Admin Guide

Developer Guide

Projects

XWiki

Extensions

Other

Contribute

Status

Practices

Under the Hood

Get Involved

Get Connected