topic Re: Aspects and Constraints in Alfresco Archive

Aspects and Constraints

tim1 — Wed, 15 Feb 2012 19:29:13 GMT

Hello,I have been working on a content model for our organization and have a few questions regarding what may be best-practices. These concepts could possibly be best practices in the realm of OOP but not in content modeling in Alfresco. This first set of questions will help guide me in the next rou

Re: Aspects and Constraints

jpotts — Wed, 15 Feb 2012 20:03:05 GMT

Your constraint looks fine except for that "caseSensitive" parameter. If that's allowed it is something new that I didn't know existed. Did you find that documented/used somewhere or did you make that up?

Your aspect looks fine except that the constraint reference needs to include the "my:" namespace.

BTW, hopefully you'll come up with a more unique/descriptive namespace!

An aspect cannot be applied to an entity multiple times. When you apply an aspect you are saying, "This type now also includes these properties and associations," so to do it more than once doesn't really make sense.

If you want to denote that a given entity is relevant to multiple role types, you should make myersonType multi-value and then add the relevant values to the list. Each value will be subject to the constraint.

Jeff

Re: Aspects and Constraints

tim1 — Wed, 15 Feb 2012 21:02:35 GMT

Thanks for the quick reply Jeff. It is MUCH appreciated.

I found the 'caseSensitive' in a post revolving around constraints. I used it as a template for my pseudo model. I don't know if it is a valid parameter or not, however seeing it made me think that any applications consuming the API should use the value consistently.

I do have a custom namespace, however, it is not much more fun than my: but it is certainly much more unique, and descriptive as well.

I did consider your solution with the use of the multi-valued parameter initially, however, what I seem to need is multiple Person(s) to be associated with a document - Each with their own unique ID, Name, and role (personType).

The reason I would like to stick with Aspects, is we have MANY different types of documents and some will be relevant to this example and some will not. We will be putting about 7 million documents per year in the repository, so I'm trying to be as efficient with space as I can.

That being said, would adding multi-valued parameters to each of the aspect's properties make sense? I can see parallel arrays in my mind if this were to be implemented… Is there a better way to achieve this? I tend to think that this is a common use case.

Thanks for the assistance Jeff. I appreciate your postings and everything you share with the community.

-Tim

Re: Aspects and Constraints

jpotts — Thu, 16 Feb 2012 15:03:35 GMT

Does the person's name, ID, or type change for a given relationship between that person and a document? If not, maybe you should be using associations that relate the document to a person object where that person object is either cmerson with an aspect added with your specialized properties or a new person object that you define.

The drawback to using associations is that they cannot be easily queried. So if that is a requirement, it would be better to use the parallel arrays approach.

Incidentally, if you do go with parallel arrays and you create a component to edit them, you might consider contributing that as an add-on. It's a common request.

Jeff

Re: Aspects and Constraints

tim1 — Thu, 16 Feb 2012 19:48:23 GMT

I apologize for verbose mode; I wanted to answer your questions as completely as possible.

The person's relationship to documents will never change as their roles are mutually exclusive. I did think about associations however that would force me to keep and maintain a 'Person', correct? If so, this is something we would like to avoid.

If I were to go the parallel array route, can you think of any Alfresco specific reasons how or why the arrays could become unsynchronized… (other than the obvious incorrect crud operation completed programmatically)?

If I could query Alfresco for the data as well as align the property value indexes up, then I could find a document with the Person aspect where ‘John Doe’ with an ID of 12345 and a personType of ‘Employee’ where are all are found in the same ordinal position of their respective arrays, this may be an option. It sounds a little complicated to me though. This leads me to the next concept: small and flexible types rather than Aspects.

The code below may be slightly off topic; however, understanding of my questions surrounding Aspects is relevant to answer this next one below.

Perhaps a solution is to modify the model like the one below? It appears that this could account for document with a list of any type of entity containing an ID, a name, and a type as defined by the ‘entity_entityTypeConstraint’ constraint.


<types>
   <type name="my:companyForm">
      <title>Form</title>
      <parent>cm:content</parent>
      <archive>true</archive>
      <properties>
         <property name="my:date">
            <title>Effective Date</title>
            <type>d:datetime</type>
         </property>
         <property name="my:entityList">
            <title>Entities</title>
            <type>my:Entity</type>
            <multi-value>true</multi-value>
         </property>
      </properties>
      <mandatory-aspects>
         <aspect>cm:auditable</aspect>
         <aspect>cm:generalclassifiable</aspect>
      </mandatory-aspects>
   </type>
   
   <type name="my:Entity">
      <title>Entity</title>
      <properties>
         <property name="my:entityId">
            <title>Code</title>
            <type>d:long</type>
         </property>
         <property name="my:entityName">
            <title>Name</title>
            <type>d:text</type>
         </property>
         <property name="my:entityType">
            <title>EntityType</title>
            <type>d:text</type>
            <constraints>
               <constraint ref="my:entity_entityTypeConstraint" type="LIST"/>
            </constraints>
         </property>
      </properties>
      <mandatory-aspects>
         <aspect>cm:auditable</aspect>
         <aspect>cm:generalclassifiable</aspect>
      </mandatory-aspects>
   </type>
   
   <!– EntityType Constraint–>
   <constraints>
      <constraint name="my:entity_entityTypeConstraint" type="LIST">
         <parameter name="allowedValues">
            <list>
               <value>Employee</value>
               <value>Consultant</value>
               <value>Vendor</value>
               <value>Corporation</value>
               <value>Network Ops Center</value>
               <value>Location</value>
               <value>Other</value>
            </list>
         </parameter>
      </constraint>
   </constraints>
   <aspects>

   </aspects>
</types>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Is this a valid model? Is this model easily queryable? Is the LIST (Multi-Valued) param of ‘Entity’ valid?

Many thanks for the help.

-Tim

Re: Aspects and Constraints

mjf — Wed, 13 Feb 2013 20:25:41 GMT

Hi Tim,

I know this was a while ago, but did you ever get an answer to this or come up with a solution, either through inbuilt content model functionality or via a custom development route?

I'm looking to implement a content model property structure with repeating property groups and there doesn't seem to be an easy way to do this out of the box (despite it being a common feature of a number of metadata models).