chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Streit <mcs...@gmail.com>
Subject Re: support for adding List<Object> to cmis:Document
Date Tue, 04 Sep 2012 15:29:12 GMT
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