Access to add and change pages is restricted. See: https://cwiki.apache.org/confluence/display/OFBIZ/Wiki+access

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Jackrabbit Branch Development

In this section I want to summarize the process of the content repository integration.

All development takes place in the jackrabbit branch.

Information about JCR and Jackrabbit

Motivation - Why we want to integrate Jackrabbit / a JCR Interface in OFBiz

  • When we have an external content Repository it's easy to connect third party tools to the repository (i.e. CMS Systems)
  • If we have a generic JCR implementation we can simply add different content repositories
  • Content Repositories allow easier maintenance of complex content structures, as contents are no longer stored in different tables (Content, Resource, ElectronicText ...).
  • Content Repositories can provide revisioning of contents and content modifications

What has been done

  • Created a new independent JCR module in the framework
  • Start the Jackrabbit Container on ofbiz startup
  • Created a Repository Factory
  • Created a Jackrabbit - Ofbiz architecture proposal:
  • (Implementation of the proposal is done and will be committed after review)  done @Rev: *1094250:
    • * You can create new repository nodes
      * Nodes are represented in a tree structure
      * Nodes can store Text (Text, HTML, FTL ....) and File content
      * There is a separate tree to store files and text content because the repository don't allow to mix them up, but this absolutely transparent for the user
      * Each new node is linked to a content entity
      * The link in the content entity can be used for maintainable reasons (permission checks, user specific content, content status etc.)
      * Everything can be tested under Examples --> Jackrabbit Sandbox
  • Jackrabbit Node Structure for (i18n) text content and files: 
  • JCR contents and nodes are always be revisioned
  • ---------------------------------------
  • Code refactoring, now using Jackrabbit OCM (ObjectContentMapping) to store Content Objects in the repository. Which makes it much easier to store different content objects, and we are flexible to add as much content fields, information as we want.
  • New Class Diagramm: 

Ofbiz Jackrabbit architecture description

TODO: Update

In the next few lines I would like to describe the architecture diagram and explain why I did choose this way to integrate Jackrabbit in OFBiz.

The design is split into two parts. The framework implementation, which contains some abstract classes and interfaces which have to be implemented to made JCR available in OFBiz. The application side represents the concrete Jackrabbit implementation.

I chose this separation to specify an independent framework side which could handle every JCR implementation (not only Jackrabbit). The concrete Jackrabbit implementation is found in the application (content) area because this part combines OFBiz (Database, Structure) with Jackrabbit. The framework shouldn’t now something about content types or content structures this information is related to the application site.

Framework side – An interface to JCR implementations

OfbizRepositoryMapping <<interface>>

The OfbizRepositoryMapping is the connection between any JCR implementation and OFBiz.

JcrHelpAbstract

This abstract class is the top class for the content operations. For now we differentiate between file and “normal” text content, because files and text contents are stored in different ways in the repository. In the future there might be more specialisation.

The class contains methods which have the same implementation in both cases. Furthermore the JcrHelperAbstract has a relation to the OfbizRepositoryMapping. It doesn’t matter which JCR implementation we use since the JcrHelpers always work with the right one.

JcrFileHelperAbstract, JcrTextHelperAbstract

Theses classes represent the methods for either the file or the text content. We have one Object for files and one for text because they need different implementation of methods and to give a user a clear separation between the different content types.

JcrFileHelperInterface, JcrTextHelperInterface

These classes seem obsolete, but imagine you have more than one JCR implementation. If you use one of the JcrHelper implementations you can simply implement against the interfaces. Should you start using another JCR implementation there is not that much to change. The code becomes much more maintainable.

Note: Adding methods is a little bit more work because they have to be added in the abstract class and in the interface as well, but the maintainable reason was more important.

 Application side

 OfbizRepositoryMappingJackrabbit

Is the concrete implementation for the connection between OFBiz and Jackrabbit. The class defines the structure of the content in the repository (See tree structure image).

JcrFileHelperJackrabbit, JcrTextHelperJackrabbit

They extend an abstract helper class and implement the interface. The helper classes use the OfbizRepositoryMappingJackrabbit methods to work with the repository. The helper classes also have methods for permission checking and handle tasks which are not directly related to the content repository.

JcrEvents, JcrWorker, JcrServices

These are classes can instantiate the helper objects and work with them.-

Still to be done

Ideas

  • Propagate and enforce OfBiz permissions, roles and users to JCR
  • Expose the JCR part via WebDAV (and/or some RESTish service)
  • JCR contents shall always be revisioned
  • Prevent duplication of properties between OfBiz and JCR
  • Explore Content Addressable Storage CAS options to prevent duplicate contents
  • Use this opportunity to create a simple workflow for OfBiz CMS Contents (or externalize to a CMS that provides a workflow)
  • No labels