Search: concept

[Pluggable security model that can maintain ACL at object level>http://whiteboardjunkie.wordpress.com/2008/11/24/where-am-i-using-jcr-and-why/] 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 JSR 283 further introduces the concept of journaled listeners which can ask the repository to re-play all events after a certain timestamp Shareable nodes.

JSR283 hence introduces the (optional) concept of shareable nodes. This allows implementing multiple URIs for a given model object.

Mapping: Wiki = Workspace 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 Allows clone nodes between wikis and support references between wikis (children wiki can have references to admin wiki documents for example) UUID are unique per repository (and not per workspace) A node with the same UUID in several workspaces point to the same Node Note: one version storage per repository Ability to call Node.update(String srcWorkspace) to replace this node by the one and its children from the srcWorkspace (same as svn update) 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" Document = Node + special NodeType Document metadata = Property Space = Node + special NodeType Document objects = Node + special NodeType (subnode of Document) Document object properties = Propery Document classes = Node + special NodeType (subnode of Document) Document class property = Property Attachment = Node + special NodeType (subnode of Document) Attachment data/metadata = Property Advantages of using JCR: Standardized Existing implementations (JackRabbit, exo JCR, etc) Ability to use existing tools that act on JCR: JCR Explorer Idea: Use workspaces to provide editorial workflow: At the core of the specification is the concept of the repository. A repository contains any number of workspaces.

. ** [Pluggable security model that can maintain ACL at object level>http://whiteboardjunkie.wordpress.com/2008/11/24/where-am-i-using-jcr-and-why/] * 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 * JSR 283 further introduces the concept of journaled listeners which can ask the repository to re-play all events after a certain timestamp * Shareable nodes.((( > In JSR170, a node can only be the child node of one other node.

JSR283 hence introduces the (optional) concept of shareable nodes. This allows implementing multiple URIs for a given model object. ))) * "Primary child item" feature.

* Mapping: ** Wiki = Workspace *** 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 *** Allows clone nodes between wikis and support references between wikis (children wiki can have references to admin wiki documents for example) *** UUID are unique per repository (and not per workspace) *** A node with the same UUID in several workspaces point to the same Node *** Note: one version storage per repository *** Ability to call Node.update(String srcWorkspace) to replace this node by the one and its children from the srcWorkspace (same as svn update) *** 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" ** Document = Node + special NodeType ** Document metadata = Property ** Space = Node + special NodeType ** Document objects = Node + special NodeType (subnode of Document) ** Document object properties = Propery ** Document classes = Node + special NodeType (subnode of Document) ** Document class property = Property ** Attachment = Node + special NodeType (subnode of Document) ** Attachment data/metadata = Property * Advantages of using JCR: ** Standardized ** Existing implementations (JackRabbit, exo JCR, etc) ** Ability to use existing tools that act on JCR: *** [[JCR Explorer>>http://www.jcr-explorer.org/screenshots.html]] * Idea: Use workspaces to provide editorial workflow:((( > At the core of the specification is the concept of the repository. A repository contains any number of workspaces.

. == Proposal == {{html clean="false" wiki="true"}} * Component-oriented architecture using a Component Manager * Each component group (set of components for implementing a concept) is separated in its own build module and generates a JAR * Make the component 100% independent of the Component Manager used * Register the Component Manager using a Servlet Context Listener * Question: Should we use existing components from the Component Manager implementation?

. */ Iterator<Patch> getUpdatesFrom(PatchId from) Iterator<Patch> getAllPatches() /** This method is inclusive: from and to patches are included */ Iterator<Patch> getDelta(PatchId fromPatch, PatchId toPatch) /** do we need to introduce a concept of dependencies between patches? */ Iterator<Patch> getDependencies(PatchId) /** a patch can be signed using a key, that is registered beforehand to the service: * see the registerKey method.

I wonder if we cannot somehow merge the concepts together. I guess I'd need to see some examples for this.

I wonder if we cannot somehow merge the concepts together. I guess I'd need to see some examples for this.

Solution n°1 : Richer HTML (not used) This concept is to replace (in a lazy way) initial HTML by a richer HTML.

So, a new strategy, based on targeting content instead of documents is described by the following: a way to provide a reference to a field in an object in a document will be devised (for example, expanding the DocumentName concept) Annotation model changes to store such a reference to a field (or to the document itself in which case it means 'document content') annotation API changes as follows: where the renderAnnotatedContent can be replaced, in case of a HTML only based approach (as in the above solution), by a or syntax could default to XHTML, etc. on the client, when using the annotations one would need to mark the source (object field, document content, etc) of a piece of XHTML and the fact that it can be annotated.

=== ==== Solution n°1 : Richer HTML (not used) ==== This concept is to replace (in a lazy way) initial HTML by a richer HTML.

So, a new strategy, based on targeting content instead of documents is described by the following: * a way to provide a reference to a field in an object in a document will be devised (for example, expanding the DocumentName concept) * Annotation model changes to store such a reference to a field (or to the document itself in which case it means 'document content') * annotation API changes as follows: {{code}}void addAnnotation(String reference, Annotation ann) String renderAnnotatedContent(String reference, Set<Annotation>, String syntax) Set<Annotation> getAnnotations(String reference){{/code}} where the renderAnnotatedContent can be replaced, in case of a HTML only based approach (as in the above solution), by a {{code}}String getAnnotatedHTML(String reference, Set<Annotation> annotations){{/code}} or syntax could default to XHTML, etc

Note: could reuse the "Types" concept here maybe, with a built-in type "SPAM" that would automatically check some keywords against subject/body content ??

Note: could reuse the "Types" concept here maybe, with a built-in type "SPAM" that would automatically check some keywords against subject/body content ??