nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Aspects and Constraints

tim1

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 round of questions. So, thanks for the help in advance.

I have created an example model with constraints and aspects (only).

1. Can an Aspect's property have a constraint like the model below?
2. Can the same aspect be applied to an entity multiple times? For example, a document is relevant to several people in the organization. Using the model above, is it possible (or recommended, or discouraged…) to apply the aspect multiple times, each with a different ‘Person Type’ property?

Here is the example:

<!– PersonType Constraint–>
<constraints>
   <constraint name="my:person_personTypeConstraint" type="LIST">
      <parameter name="allowedValues">
         <list>
            <value>Employee</value>
            <value>Consultant</value>
            <value>Vendor</value>
            <value>Other</value>
         </list>
      </parameter>
      <parameter name="caseSensitive">
         <value>true</value>
      </parameter>
   </constraint>
</constraints>


<!– Person Aspect –>
<aspects>
   <aspect name="my:Person">
      <title>Person</title>
      <properties>
         <property name="my:personId">
            <title>Person ID</title>
            <type>d:long</type>
         </property>
         <property name="my:personName">
            <title>Name</title>
            <type>d:text</type>
         </property>
         <property name="my:personType">
            <title>Person Type</title>
            <type>d:text</type>
            <constraints>
               <constraint ref="person_personTypeConstraint" type="LIST"/>
            </constraints>
         </property>
      </properties>
   </aspect>
</aspects>‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Thanks!
-Tim

Find more posts tagged with

Comments

jpotts

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 my

ersonType multi-value and then add the relevant values to the list. Each value will be subject to the constraint.

Jeff

tim1

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

jpotts

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 cm

erson 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

tim1

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

mjf

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).