chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Potts <jeffpott...@gmail.com>
Subject Re: support for adding List<Object> to cmis:Document
Date Wed, 05 Sep 2012 13:52:56 GMT
I see what you are trying to do now. Instead of typing a property as a more fundamental type,
like d:text, you want to type it as a complex type, in your case acme:userNote.

I believe this is possible, but I've never tried it or seen it done. You'll have to do much
more than declare it in your content model XML. You'll have to write some Java classes so
that Alfresco knows how to index that property and how to persist it in the database. I don't
know of any examples of this, other than what's in the source code (you could follow the pattern
of what's been done for "d:text" and any other types in the dictionary model).

In any case, this is off-topic for Chemistry Dev. You might want to ask your question in the
Alfresco Content Modeling forum:
https://forums.alfresco.com/en/viewforum.php?f=5

Jeff

On Sep 4, 2012, at 10:29 AM, Mark Streit wrote:

> Jeff
> 
> I did read your updated version of the Alfresco Content Model paper (SomeCo)  http://ecmarchitect.com/images/articles/alfresco-content/content-article-2ed.pdf
.  
> 
> I saw the model that you have for modeling the "whitepaper" concept.  I don't think anything
short of being able to add a multi-valued property like the List<UserNote> concept will
work for our application.  I have doubts that SharePoint, as an ECM choice, can even support
this anyway and would guess Alfresco might be the closest at being able to do this given its
configuration capability as you describe in your paper.
> 
> Do I understand correctly that no matter what we did, the UserNote object would have
to be a subclass of cmis:Document ?  Perhaps I am not understanding.
> 
> The current model we have been using successfully looks like this (where userNote is
actually just a text (String) property type:
> 
>     <types>
>         <!-- Enterprise-wide generic document type -->
>         <type name="acme:doc">
>             <title>ACME Document</title>
>             <parent>cm:content</parent>
>             <properties>
>                 <property name="acme:documentDisplayName">
>                     <type>d:text</type>
>                 </property>
>                 <property name="acme:documentType">
>                     <type>d:text</type>
>                 </property>
>                 <property name="acme:userID">
>                     <type>d:text</type>
>                 </property>
>                 <property name="acme:category">
>                     <type>d:text</type>
>                 </property>
>                 <property name="acme:subCategory">
>                     <type>d:text</type>
>                 </property>
>                 <property name="acme:expirationDate">
>                     <type>d:date</type>
>                 </property>
>                 <property name="acme:userNotes">
>                     <type>d:text</type>
>                 </property>
>                 <property name="acme:keyWords">
>                     <type>d:text</type>
>                 </property>
>             </properties>
> 
> 
> It is the following element definition above:
> 
>                <property name="acme:userNotes">
> 
>                     <type>d:text</type>
> 
>                 </property>
> 
> 
> Where we want the actual <type> to be definable as a List<UserNote> 
> 
> 1) we have to be able to define UserNote (obviously we can model as simple Java bean)
> 
> 2) we need to be able to have this acme:doc defined such that it can include the List<>
construct
> 
> I am guessing this may not be feasible?
> 
> Thanks..
> 
> 
> 
> Mark
> 
> On Aug 31, 2012 2:31 PM, "Mark Streit" <mcs130@gmail.com> wrote:
> 
> Hi Jeff
> 
> Thanks for the quick response (seems to be common on this list which is really appreciated).
> 
> I see what you are saying.  Not sure if it is quite along the idea the team was thinking
of for this application.  The notion of being able to model a UserNote object and hold a List<>
of them as part of the single cmis:Document instance was really the desired approach.
> 
> The custom web front end being developed presents 2 of the 4 items, say 
> 
> categoryCode, type=String
> subCategoryCode, type=String
> 
> as drop downs the user selects from - we control the values with a configuration file.
 When the document is added or updated, these properties are then set and saved to the back-end
ECM via openCMIS (only one objectId for the Document is involved).  This has worked just fine.

> 
> Now the UI design has been altered to allow a free-form text input field...input text
box allows the user to enter a "note". The intent is to to add this note to a persistent list
of notes that rides around on the cmis:Document instance - when the save button is pressed,
the note is added to the list.  There is also a history link let's say, where the user clicks
- and a this now, non-editable, list pops up showing the history.
>   
> Does that help better illustrate?
> 
> Thanks again.
> 
> 
> On Fri, Aug 31, 2012 at 1:03 PM, Jeff Potts <jeffpotts01@gmail.com> wrote:
> Mark,
> 
> You could use relationships in repositories that support it to associate documents with
N notes. For repositories that don't support it, a note could be a cmis:document and you could
track cmis:objectId's of notes in a multi-value property on the cmis:document (more likely
a child type of cmis:document) instances related to those notes.
> 
> Does that make sense or am I missing your intent?
> 
> Jeff
> 
> On Aug 31, 2012, at 10:45 AM, Mark Streit wrote:
> 
> > I have seen a few threads on a similar topic so pardon if this is
> > duplicated.
> >
> > First off, I know that this is completely dependent on the ECM product
> > supporting this.  2 ECM products are being considered - SharePoint 2010 (or
> > possibly 2013) and Alfresco 4
> >
> > Second this an all Java implementation from the client side.  Here is the
> > scenario.
> >
> > We can currently add properties to *cmis:Document* .... let's say for
> > simplicity, we add:
> >
> > categoryCode, type=String
> > subCategoryCode, type=String
> > displayName, type=String
> > employeeID, type=String
> >
> >
> > This works fine in both products - in one case, AF4, you extend the model
> > with an XML configuration file whereas in Sharepoint, you can use the
> > Library Admin page to add fields of various types to the current document
> > model.  So far, so good.
> >
> > Now, we have a use case, where we need these same 4 properties, PLUS a
> > List<UserNote> where:
> >
> > UserNote:
> >
> > id, type=long
> > date, type=Calendar
> > noteText, type=String
> >
> >
> > As I see it we have to 1) define the UserNote object in the ECM backend
> > somehow and 2) add this List<UserNote> property to the cmis:Document.  What
> > they are looking to do is to keep the history of these notes made by the
> > user on this Document whenever they retrieve it to edit, etc.  Not trying
> > to reproduce version control as much as attaching these ad-hoc notes
> > managed on the Document.
> >
> > My 2 questions are:
> >
> >
> >   - Can the CMIS APIs support this use case?
> >   - If so, can anyone suggest an example or point to document showing
> >   something similar to this?
> >
> >
> > Thanks in advance for any insight or suggestions.
> >
> > --
> > Mark
> > * *
> 
> 
> 
> 
> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message