27 Feb 13:18
Re: Local ECM Provider
Ok great! I've implemented a FileSystem provider inside a separatated plugin. The provider is handling: Create, Edit, Modify, Copy, Move, getChild, getChildren operations The metadata handling is not still implemented. I will add support for "title" and "lastModified" fields these days. The package contains a JUnit test (tha can be runned outside the eclipse frameowork using Runa As > Junit Test) The tests is also demonstrating the API usage of the resource model You can find the plugin in the svn repository at http://svn.in.nuxeo.com/pub/Apogee/src/trunk/org.nuxeo.core.resources.filesystem/ I will continue today to clean-up the core model classes and to refactor UI infrastructure.. so that these days we will have a generic viewer to use with the File System provider Bogdan Sato wrote: >Bodgan, > >Thanks to your deteild explanation, >now I figured out the ResourceModel logical model clearly :) > >The model can be modeled like this. >http://tmtec.biz/download/ResourceModel2.jpg > >Next, I'm going to make myself understood interfaces. > >Thanks, >Takenori > >-----Original Message----- >From: Bogdan Stefanescu [mailto:bstefanescu@...] >Sent: Friday, February 24, 2006 2:14 PM >To: Sato >Cc: apogee@... >Subject: Re: [Apogee] Local ECM Provider > > >Yes it's confusing. :) > > >A repository is made from nodes organized in a tree structure. >I will call these nodes “resources”. So resources can be of the >following types: > > * > > Site a folder that is the root of an ECM provider tree > > * > > Folder a parent node > > * > > File a leaf node > >There are 3 requirements imposed by Apogee: > > 1. > > Every node should be able to store a map of attributes called > meta-data. > The meta-data is describing the nature of the data contained by > the node. > > 2. > > Every node in the tree may contains data. How data is contained? > This is not defined. > ECM Providers are free to defines the data storage and the binding > to a resource tree node.. > Apogee must be able to set and retrieve data in the form of a Java > InputStream for a given a resource. > > For the local ECM provider I suggest using meta-data attributes >to define how data is contained by a node. > The “contents-uri” attribute may describe this. > > 3. > > Folder nodes may contains children and can be queried about their > children. > > >The ECM provider should be able to perform searches on meta-data attributes. >We may also use Lucene for full text search in parallel to the >repository meta-data search. >How we will perform combined search (using both Lucene and the ECM >provider search support)? >In don't know.. May be we will index any required field in a mixed >search in Lucene to avoid merging 2 search results. > > >For the work-flow and security problems I will ask my colleagues on CPS >for more information. > > >When editing a resource the UI must know what kind of data it is editing. > >We may classify data content in 2 types: > > 1. > > structured content > > This type of content includes any content described in terms of > fields of a given type. > This is true for any data stored as an object. > For example an User object may be defined as an Username field and > an Password field. > In this case we are dealing with structured content that need a > special editor to modify it. > Because such content is very dynamic (providers may have different > attributes for an "User" object or they may define objects > undefined by other providers) we need a mechanism that generate > editors that are able to edit such contents. > > 2. > > unstructured content > > Unstructured content is represented by an input stream of bytes. > It may be an image, a XHTML document, a NewsML document, a MS Word > document a binary document like a JPEG or any other type of byte > stream document. > This type of document will be edited using an adequate editor like > MS Word, XHTML Mozilla Composer etc. (depending on the content-type) > >The UI will knows how to edit a resource by querying the resource >meta-data about the content type of the underlying content. >If the content-type is seen as a structured content-type then the >resource will be queried to provide a XForms and a XML Schema document >to generate a suitable UI editor for editing its content. >(This can be done for example by defining 2 resource meta-data >properties "xforms" and "xml-schema") >I will define this when refactoring the UI infrastructure. > >Thus, we need to define what content types are structured and requires >editor generation and what contents are unstructured. >This will be defined at the UI level using eclipse extension points. >(for this we will bind content-types to editor classes. If the bound >editor is of type IDynamicEditor then a structured content is assumed) > >For example contents like “text/plain”, “text/xhtml” should be bound to >non-structured content editors while content like “apogee/user” should >be bound to a structured editor that will be generated using the xforms >provided by the ECM provider. > > >Bogdan > > > >Sato wrote: > > > >>Hi, >> >> >> >> >> >>>I will work on the file system provider and the CPS provider next weeks, >>>so you will be able to see examples of implementations in the svn... >>> >>> >>> >>> >>Great! So I will follow you. >> >> >> >> >> >>>New ECM providers should be contributed as plugins (the filesystem >>>provider is an exception since it is a demo provider.. and comes with >>>the resource core plugin) >>> >>> >>> >>> >>I see. >> >> >> >> >> >>>Objects can be of any types and are living inside a tree structure. >>> >>> >>> >>> >>... >> >> >> >> >>>In fact, underlying objects may not be real java objects. You define an >>>object using a metadata object that is a map of named attributes. >>>For example you may define an object of type "Link" that represent an >>>URL without having to store a real java object in the database. >>> >>> >>> >>> >>... >> >> >> >> >>>Note that any object stored in the database may have contents (even folders) >>> >>> >>> >>> >>... >> >> >> >> >>>I propose using some generic mechanism like using two metadata attributes: >>>"content-uri" >>>and >>>"content-type" >>> >>> >>> >>> >>... >> >> >> >> >>>As storage for binary files or text files I think you may use the file >>>system instead of storing file contents in the database. >>>For a more structured content (for example an "User" object) you can >>>store it directly in the database as an object or you may store it as an >>>XML file that is describing the object. >>> >>>Not that, in order to implement content editing, we need to dynamically >>>generate an editor suitable for the object type to be edited. >>> >>> >>> >>> >>... >> >> >> >> >>>You can store the content how you like but you should be able to provide >>>such a XML description of the content if needed. >>>For contents as XHTML files or other file types the XML instance >>>document is not required since no XForms editor will be used - XHTML, MS >>>Word or other editors will be used to edit the content >>> >>> >>> >>> >>I am a little confused ;) >> >>- objects in a tree >>- contents in a metadata >> >>An object that can be represented by XForms is a content. >>Every editable *object* is a content? >> >> >> >> >> >>>The UI will require a document instance depending on the content-type >>>attribute of the object. If it is an content type that requires editor >>>generation from XForms >>>the XML document instance will be required. The mapping between >>>content-types and editor types will be defined using eclipse extension >>>points >>> >>>This is how I see the interactin of the provider with Apogee. If you >>>have questions on this please post them. >>> >>> >>> >>> >>I see. I will ask you as needed. >> >> >> >> >> >>>Now other part is related to operations on these resources. >>> >>> >>> >>> >>... >> >> >> >> >>>Two big functionalities of an ECM system is the workflow system and the >>>security system >>> >>> >>> >>> >>... >> >> >> >> >>>Each ECM >>>platform has it's own security logic. For example CPS is implementing >>>this using roles on objects and keeping an users/groups repository. >>>The workflow system may enable some operations only if some >>>pre-requisties are met. This is not defined by apogee. >>> >>>For now we will focus on the storage layer of the local ECM provider. >>>The system security and worklow systems will be defined later (I think >>>reusing the concepts already used in CPS) >>> >>> >>> >>> >>I'd like to understand typical real world usages(workflow, security, etc). >>Could you suggest me some documents? >> >> >> >> >> >>>Resources may be searched using metadata attributes. >>>We will also use lucene for text indexing. So when adding a resource to >>>the repository we may index it's metadata and it's contents >>>using lucene. but the ecm provider must be able to perform searching too. >>>A problem is if you want to do combined searchs (lucene + native db4o >>>search) ... because this is requiring merging results. >>> >>> >>> >>> >>So Lucene provides full-text searches, >>while a Local ECM Provider provides other searches. >>Do you know what kind of searches are requested well for a Local ECM Provider? >> >>Thanks, >>Takenori >> >> >> >> >> > > > > -- -- Bogdan Stefanescu - Apogee project Team Leader Nuxeo - Open Source ECM - www.nuxeo.com Apogée - the rich client platform for ECM http://apogee.nuxeo.org/ - http://www.nuxeo.com/en
RSS Feed