Package org.hippoecm.hst.content.beans.manager

Interface ObjectBeanPersistenceManager

  • All Superinterfaces:
    ObjectBeanManager
    All Known Subinterfaces:
    WorkflowPersistenceManager
    public interface ObjectBeanPersistenceManager
extends ObjectBeanManager
    ObjectBeanPersistenceManager is the primary interface for HST-2-Persistence-aware application components.

    An implementation of this interface should be able to convert content nodes to objects, and vice versa. Also it should have knowledges on how to create, update or remove a content node with node type and absolute path.

    If the content models are not complex and so just simple node structures are enough for the requirements, then an implementation for this interface can probably provide an automatic bi-directional mappings.

    However, in most real cases, the content models are very sophisticated, so they need careful workflow management to fulfill real requirements such as faceted selection, virtual nodes, approval or publishing management. Therefore, this sophisticated management should be implemented properly in separated classes.

    Some sophisticated JCR repository engine already have their own workflow knowledges on how to create, update and remove content nodes based on node types. Or, some domain specific content-based application should know the knowledges on their own content models. In these cases, they can provide an implementation for this interface.

    • Method Detail

      • createAndReturn

        String createAndReturn​(String absPath,
                       String nodeTypeName,
                       String name,
                       boolean autoCreateFolders)
                throws ObjectBeanPersistenceException
        Creates content node(s) with the specified node type at the specified absolute path.

        The absolute path could be regarded differently according to physical implementations. For example, an implementation can regard the path as a simple one to create a simple JCR node. On the other hand, a sophisticated implementation can regard the path as an input for a workflow-enabled document/folder path.

        If autoCreateFolders is true, then folders will be automatically created.

        Parameters:
        absPath - the absolute node path
        nodeTypeName - the node type name of the content object
        name - the content node name
        autoCreateFolders - the flag to create folders
        Returns:
        the absolute path of the created node
        Throws:
        ObjectBeanPersistenceException

      • update

        void update​(Object content)
     throws ObjectBeanPersistenceException
        Updates the content node which is mapped to the object.

        An implementation can provide binding the content object to the physical JCR node(s) and updates. An implementation can provide automatic content binding, or another requires pre-registered ContentNodeBinder map to do real bindings. It probably depends on the functionalities of underlying repository.

        Note: It is recommended as best practice and more semantically correct to always invoke save() to commit the changes to the repository after successful update(Object) call. In the future, the commit or rollback semantics could be more dependent on whether save() or refresh()/refresh(boolean) is really invoked.

        Parameters:
        content -
        Throws:
        ObjectBeanPersistenceException

      • update

        void update​(Object content,
            ContentNodeBinder customContentNodeBinder)
     throws ObjectBeanPersistenceException
        Updates the content node which is mapped to the object by the customContentNodeBinder provided by client.

        Unlike update(Object), the implementation should not try to do automatic or predefined bindings. Instead, it should invoke customContentNodeBinder to do bindings.

        Therefore, if a developer wants to customize the bindings, the developer should provide a customContentNodeBinder.

        Note: It is recommended as best practice and more semantically correct to always invoke save() to commit the changes to the repository after successful update(Object, ContentNodeBinder) call. In the future, the commit or rollback semantics could be more dependent on whether save() or refresh()/refresh(boolean) is really invoked.

        Parameters:
        content -
        customContentNodeBinder -
        Throws:
        ObjectBeanPersistenceException