[
https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218929#comment-13218929
]
Anne Jessel commented on OFBIZ-4709:
------------------------------------
Thanks for restructuring the wiki page, Sascha. It will be easier to expand on
now.
I planned to add some draft design ideas today, but instead I have come up with
lots of questions. I realised I don't understand well enough how you intended
the existing JCR classes to be used. I am adding here some of my thoughts:
hopefully that will help make it all clearer to me and maybe others.
I can think of two general use cases (ignoring standard CRUD-type operations):
* I have already information that specifies which content I want. For example,
I have a PartyContent or ProductContent entity, and want the associated content.
* I need to choose specific content based on certain criteria. For example, I
want to display a list of available and current Data Sheets to the user. When
the user chooses one, I will link it to a Product by creating a ProductContent.
Initially I had in mind a general workflow as follows:
# use current entity support to find desired Content entity (or maybe just
contentId)
# pass chosen Content entity (or contentId) to a ContentFactory class method
# ContentFactory returns an object of an Interface type, with specific
implementation determined by (at least) storageTypeId.
# code that invoked ContentFactory uses methods of Interface to access actual
content and its metadata, and does not need to know whether the content and
metadata is from other Entities, or from JCR
If we do this, the design of the Interface returned by the ContentFactory will
be very important.
If the orm classes and Jackrabbit annotations are used, I'm not sure how best
to make use of Content entity in a generic way. Maybe there needs to be a
different orm.jackrabbit class, and corresponding api.*Helper, for each
ContentType? And the ContentFactory uses the contentTypeId field to work out
what class to instantiate (but only when storageTypeId is JCR).
If we store searchable metadata such as from/thruDate and contentType in JCR,
then maybe we can't always do workflow step 1 the way I was thinking. Maybe we
need also a ContentWorker that will do searches for us, and automatically knows
how to search both Entities and JCR repository?
> 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
