[ 
https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216687#comment-13216687
 ] 

Jacques Le Roux commented on OFBIZ-4709:
----------------------------------------

To be fair, in my mind I was not referring to Anne's specific problem. But to 
her generic solution (Content.storageTypeId) mixed with a proposition based on 
Sascha's initial proposition of using a ContentFactory (he spoke about 
*ContentWorkerFactory). This to instantiate the respective "DataSource types".

In other words we would use a ContentFactory Interface (or Abstract Class) to 
delegate the work to concrete classes DbContentFactory or JcrContentFactory, ...

But indeed it's maybe easier to cut up the steam with a contentTypeId="JCR". I 
just wonder if it will not be to much confusing because it's no really a 
content type but a family of content types. Hence the Content.storageTypeId, 
where we could also decide of the JackRabbit Persistence Manager:
storageTypeId = OFBizDB (standard)
storageTypeId = jackrabbitDerbyPersistenceManager (
storageTypeId = jackrabbitPostgreSQLPersistenceManager
storageTypeId = jackrabbitMySqlPersistenceManager
storageTypeId = jackrabbitBundleFsPersistenceManager 
storageTypeId = jackrabbitinMemPersistenceManager 
storageTypeId = jackrabbitSimpleDbPersistenceManager 
etc.

Just ideas threw out at this stage, I feel it misses more thoughts and maybe 
mixed to aspects (type and persistence). Also I'm far to undersand all the JCR 
aspects. I will begin by reviewing ExampleJackrabbitShowContentData today...

BTW maybe we/I should not continue to pollute Anne's topic and to create 
another Jira or rather continue to discuss this on dev ML?

My 2cts
                
> Support jcr-stored file content within Applications
> ---------------------------------------------------
>
>                 Key: OFBIZ-4709
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-4709
>             Project: OFBiz
>          Issue Type: Sub-task
>          Components: ALL APPLICATIONS
>    Affects Versions: SVN trunk
>            Reporter: Anne Jessel
>            Assignee: Sascha Rodekamp
>
> My current requirements:
> * store uploaded documents (pdf and scans), mainly for legal compliance 
> reasons
> * old document versions should be accessible
> * documents should be associated with existing entities. So far I've 
> identified a need to associate with Product, Party, OrderHeader, 
> ShipmentItem, probably InventoryItemDetail and maybe WorkEffort. I would not 
> be surprised if we discover more as this project proceeds.
> * documents may have a type and a purpose, though sometimes I'm not sure of 
> the difference. For example, type: drivers_licence might be purpose: 
> identification, and/or purpose: permission_to_drive, while type: 
> shipping_label would be purpose: shipping_label
> * many documents have an expiry date (e.g. drivers licence)
> * a document may become invalid before its expiry date (e.g. because the law 
> changed)
> * a specific version of a document may need to be associated with an entity. 
> For example, a licence agreement document accessed via a Product should 
> always be the latest version. However the version of that document actually 
> shipped with the product should be associated with the ShipmentItem.
> * a single document might be associated with more than one entity type: see 
> the example in the previous point
> Not all documents require all of the above. For example, there are some 
> documents where we don't need to track which version was used when, and some 
> without expiry dates.
> I'm thinking of using the from/thruDate pattern to handle expiry related 
> needs. I'd like to put as much information into the jcr path as possible, so 
> less needs to go into entities, as per Sascha's suggestion on the dev ML. 
> However (at least) from/thruDate and which version of a document was actually 
> used where will presumably need to be stored in an entity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to