chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karsten Eberding <kars...@eberding.eu>
Subject Re: support for adding List<Object> to cmis:Document
Date Tue, 04 Sep 2012 18:56:11 GMT
Mark,

I haven't done this myself, but it should work by defining the property 
as multi-valued, as done with the "multiple" setting in this example:

         <property  name="my:tags">
           <title>Tags</title>
           <type>d:category</type>
           <mandatory>false</mandatory>
           <multiple>true</multiple>
           <index  enabled="true">
             <atomic>true</atomic>
             <stored>true</stored>
             <tokenised>false</tokenised>
           </index>
         </property>

(taken from 
http://sujitpal.blogspot.de/2010/05/alfresco-developing-content-model.html)

I hope this helps

Karsten Eberding

St.-Martin-Str. 19
85604 Zorneding

Phone +49 171 3090201
Mail karsten@eberding.eu

Am 04.09.12 18:48, schrieb Mark Streit:
> Karsten
>
> Thanks for replying.  The permission question is already being addressed by
> the UI implementation so that is not an issue based on how this is being
> done.  Notes, once entered, are NOT going to be editable.  They will only
> be displayed as a "note history" - this List<>,  attached to the document
> object being retrieved.  The user can add a new note, and that simply is
> added to the existing List<>.
>
>   Your first statement:
>
> *"adding a multi-valued property for your UserNotes should be
> straightforward by defining this in your model for Alfresco."*
>
>
> Therein lies the challenge and what we are trying to figure out how to do
> correctly.  We have it shown now as simply another String (text) property
> and that is working.  We now need to change the simple String property to
> this List<UserNote>.
>
> I was hoping there might be an example we could look out or someone on the
> mailing list who has seen/done this that might point me to such a resource.
>   In this case, it is one step beyond a List<String> - it is this
> List<UserNote> concept.
>
> Thanks again for your input.
>
> On Tue, Sep 4, 2012 at 12:02 PM, Karsten Eberding <karsten@eberding.eu>wrote:
>
>> Mark,
>>
>> adding a multi-valued property for your UserNotes should be
>> straightforward by defining this in your model for Alfresco.
>>
>> But be aware that the Alfresco permission model (like most other ECM
>> systems) only manages one permission per document object. You cannot have
>> different permissions per property, and certainly not per entry in a single
>> multi-valued property. As you want to have users to be able to write to the
>> last note, but not change any previous notes, I don't think this approach
>> fits your needs.
>>
>> Of course, you could find workarounds, like managing access restrictions
>> in the client UI or changing fields through a system user as part of a
>> workflow. But this has other drawbacks, a concept with a separate object
>> per note seems to be much easier to setup.
>>
>> Just my thoughts.
>> thanks
>>
>> Karsten Eberding
>>
>> St.-Martin-Str. 19
>> 85604 Zorneding
>>
>> Phone +49 171 3090201
>> Mail karsten@eberding.eu
>>
>> Am 04.09.12 17:29, schrieb Mark Streit:
>>
>>> 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<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