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.

Content Model : Best practices

dranakan

Hello

I am creating my CustomModel but I am not sure to use the best method. Jeff Potts advise to not create unnecessary content model depth… but I don't know where is the limit…

In my logic, I want to create a Tree where a use inheritance to share the common properties. I also regroup documents together.
For example, if I want to store some Invoices (Debtor and Creditor where in Creditor I want to store the "BVR" which is a code reference). This is for a compagny having many firms (that's why idFirm). My tree is like this :

->cm:content 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ->me:doc
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ->me: Invoices (properties : idFirm, idInvoice)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ->me:Invoices_Debtor
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ->me:Invoices_Creditor (properties : BVR) 
(me:doc is child of cm:content, …)‍‍‍‍‍‍

Is it a good way to represent this like this ? Or should I create under me:doc directly two types (Invoices_Debtor and Invoices_Creditor) which have each an idFirmInvoice_x et idInvoice_x ?

Can I also create mother types with no property to regroup the types ? For exemples in a school : I have some notes (final notes and half years notes) is it a good way to do like this :

->cm:content 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ->me:doc
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ->me:school
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ->me:notes (properties : year)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ->me:finalExam
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ->me:halfYear (properties : month)
(me:doc is child of cm:content, …)‍‍‍‍‍‍‍

Here I have regrouped the notes under school which have no properties. If I have a new type of document concerning school, I can easy put it under me:school and my model keep a logical structure in Tree.
Have you best pratices to create a updatable in time content model ?

Thanks

Find more posts tagged with

Comments

mrogers

My rule of thumb for Java inheritance is a maximum of 3. I think the same thinking could be applied to content models.

Roughly some sort of abstract thing, some sort of real thing and some sorts of specialised things.

Of course rules are there to be broken and there will be exceptions, but that's where I'd start.

So for your case.
So you will have some sort of base document with whatever global properties are important to all documents in your company. Possibly an aspect or a document type relating to invoices. And then your two specialised types for Debtor and Creditor.

dranakan

Thank you Mrogers for your advises.

To resume :

Example 1
For the main document (child of cm:content), the best is to add properties that could be uses by specialised documents either if these properties are not used. If I recreate my example (a big compagny with many firms and also schools) before…

->cm:content
   ->me:doc (properties : idDocument, idFirm, year)  //idFirm used for Finances document and year for school documents
       ->me: Invoices (…)
         ->me:Invoices_Debtor
         ->me:Invoices_Creditor (properties : BVR) 
       ->me:notes (…)
         ->me:finalExam
         ->me:halfYearExam (properties : month)‍‍‍‍‍‍‍‍

Comments :

Using global properties not used by a specialised document take place for nothing in the database…Exemple 2
Now I will try to use aspects to give properties to documents…

->cm:content
   ->me:doc (properties : idDocument)  //idFirm will be used for Finances document and year just for school documents
        ->me:Invoices_Debtor
        ->me:Invoices_Creditor
        ->me:finalExam
        ->me:halfYear

Aspects :
   ->me:invoice (idFirm, Bvr)
   ->me:school (properties : year, month, …)
‍‍‍‍‍‍‍‍‍‍‍

In this method I also have empty properties (aspect contains all properties for specialised documents), but it's limited… But, when a user create a document, he always needs to add an aspect… :!: [size=85] UPDATE : This is wrong. As say after by Jeff Potts, we can make the aspect mandatory for that type so that the users/coders won't have to worry about making sure it is always added.
[/size]

What could be the best choices (example 1 or 2 (or other))?
Have you find a example like this which have a lot a different documents ?

Thanks

mrogers

Either approach will work.

I'd be tempted to start with the the inheritance rather than the aspects.
What you need to do is anticipate/guess how this will grow in future and flesh out your model more.

If and when you add more properties and find for example some base properties are irrelevant then that indicates that your model is wrong. I'd also explore your edge cases. So how would you model an invoice for a school? Is there any connection between school.year and invoice.idFirm.

dranakan

Thank you

>>Is there any connection between school.year and invoice.idFirm?
There are not…

I would have one general model to use when I deploy on a school (notes, …), on a compagny (Finance, …), and also other type of customers.
It is perhaps better for me to have differents models (one for each domain (school, finance, …). But with that, I cannot have an enterprise-wide root type. But it is very usefull to have ?

Model Finance

->cm:content
&nbsp;&nbsp; ->finance:doc (properties : idFirm, idDocument)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ->finance:Invoices (…)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ->finance:Invoices_Debtor
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ->finance:Invoices_Creditor (properties : BVR) 
‍‍‍‍‍‍‍

Model School

->cm:content
&nbsp;&nbsp; ->school:doc (properties : idDocument)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ->school:notes (properties : year)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ->school:finalExam
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ->school:halfYear (properties : month)
‍‍‍‍‍‍‍

Comments

One model by themeNo enterprise-wide root typeLike the example in the first post, but with this separation in two model, the depth is one level more (depth can generate poor performance)

dranakan

Hello,

Does anyone see a disadvantage (or problem) to not use an entreprise-wide root type but an wide root type by theme (one for school, finance, …) :?:

Here you can find advises from Jeff Potts (about the enterprisewide
root type) :

Consider implementing an enterprisewide
root type. Although the need for a common ancestor
type is lessened through the use of aspects, it still might be a good idea to define an enterprisewide
root content type from which all other content types in the repository inherit if for no other
reason than it gives content managers a “catchall”
type to use when no other type will do.

Source : http://ecmarchitect.com/images/articles/alfresco-content/content-article.pdf

Does someone have a example of the creation of a wide content model :?:
In the models files, is it possible to define a global property and reuse it in the different types ? How do you do that :?:

:arrow: Advises/comments about the creation of the content model (in the previous post) are welcome.
Thanks

jpotts

I see no reason to have two separate models in this case. It's more XML to manage and duplicates property definitions across the two models (idDocument). If you anticipate the school and finance models to grow very large over time maybe it makes sense. In that case, consider having a third "common" model that would have your enterprise-wide type with idDocument, and then import it into the school and finance models so those types can extend from the root type.

It looks to me like everything in your model has at least one common property, idDocument, so I do think you should have a common root type. Yes, it adds a level of depth but I think it is worth it.

On the invoices, I'd also use a common invoice type and then sub types for each of the specific invoice types. Again, it adds a level of depth but for good reason.

Other comments regarding points earlier in the thread:
- Don't worry about always having to add an aspect to a certain type. You can make the aspect mandatory for that type so that the users/coders won't have to worry about making sure it is always added.
- Yes, you can use types that have no properties. That's good for grouping descendants or even just for use as a "marker" so that you can easily find instances of that type with queries.

Hope that helps,

Jeff

dranakan

Thanks you Jeff 🙂

I will do these changements (I have add other types to have a best global view) :

->cm:content
   ->me:doc (properties : idDocument)
       ->me:financial (properties : idFirm)
           ->me:Invoices (properties : idCustomer (mandatory Aspect))
                ->me:Invoices_Debtor
                ->me:Invoices_Creditor (properties : BVR)
           ->me:Salary (properties : idEmploy (mandatory Aspect))
           ->me:Orders (properties : idEmploy (mandatory Aspect), idCustomer (mandatory Aspect))
           ->me:…
       ->me:school
           ->me:notes (properties : year)
                ->me:finalExam
                ->me:halfYear (properties : month)
       ->me:…

Aspects :
   ->me:customer (idCustomer)
   ->me:employ(idEmploy)

me:doc is child of cm:content, …)
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

:arrow: Comments :

Here, aspects are not used like "able to…" but like global properties. IdCustomer or IdEmploy could be used for other types. BVR is not in aspect because it is used only by Invoice_Creditor.Depth is higher thant other examples (could be not a problem)If a user create is own rapport (about school for example) the property idDocument will be not used, but most of documents will used this property. :arrow: Questions:

see no reason to have two separate models in this case

Would be it cleaner to create 3 models ? Than having one file.xlm with all inside. I don't know if there is some impact on performance…:?:

One for the general with : type doc, all contraints and aspectsOne for financial (import general)One for School (import general)…

jpotts

Yes, if you are going to have three different content models, put them in three different XML files.

Jeff

nikes

jpotts,

I have a common property in various content types. In some types it is mandatory but in others common property is not mandatory.

What do you suggest in this case?

dranakan,

Sorry for adding my question in your thread.

Thanks,
Nikesh

jpotts

Can you put the property in an aspect and then make the aspect mandatory on the types where it makes sense? Having the property in an aspect gives you the flexibility to add the property only to certain types. Making it a mandatory aspect gives you the ability to require the property for certain types. If you make the property mandatory, then any time it is present, it will be required.

However, if you are trying to sometimes have the property and sometimes not, and when it exists, make it mandatory sometimes and optional other times, I'm not sure you can do that. I don't think you can, for example, extend a type and relax the mandatory property restrictions of the parent. If this is what you're trying to do, it's going to take more digging.

Jeff

rudyanto

Hi everyone,

Do you know how to add dynamic content to constraints? I have already known how to define static contents in constraints as list of values. But my project requirement is to give dynamic contraints (list of values) to a metadata. The end users can add the lov (list of values) by theirselves. I think they could fill the list of values via data dictionary.

Sorry to add this question to Dranakan's thread. I hope you have solutions on this because I think you are already an expert in content model regarding your high level question.

Best Regards,
Rudyanto

dranakan

Hello,

Nikes, Rudyanto, this is the good place to ask questions about Content Model. Don't be sorry 🙂

Do you know how to add dynamic content to constraints? I have already known how to define static contents in constraints as list of values. But my project requirement is to give dynamic contraints (list of values) to a metadata. The end users can add the lov (list of values) by theirselves. I think they could fill the list of values via data dictionary.

Rudyanto : I have no idea to this solution… Someone has an idea about dynamic content to constraints ?

nikes

Thanks dranakan

Rudyanto, you can refer following topic:

http://forums.alfresco.com/en/viewtopic.php?f=4&t=11687

You have to create table and column in your database. So whatever value you add or edit in your column in database, it would get reflected in your propertsheet drop-down, and yes….no restart required..!!

I used following jars while compiling….
alfresco-repository-3.2.jar
myfaces-api-1.1.5.jar
commons-logging-1.1.jar
alfresco-web-client-3.2.jar

Hope it will help.

Nikesh

rudyanto

Thanks Nikes & Dranakan

Also I have found other solutions on this:
http://blogs.alfresco.com/wp/jbarmash/2008/08/18/implementing-cascading-dropdowns-for-editing-properties/

It seems that core alfresco 3.2 haven't provide this Dynamic Data-Driven Drop Downs.

Hope that Alfresco 3.3 will adopt this feature.

Best Regards,
Rudyanto

dranakan

Hello,

I have some types of documents (Orders, Salary, notes, invoices …) and I would like to attach other file with them. For exemple, I want to add a "picture" to an "Order". This annexe are related to the type.

For exemple an "Order" is identified by (firmNb, documentNb, and the type : order). I would to "annexe" a new document to this "Order".

1) We could create a child (new type) of "Order" called "Order_annexe" and add new field like annexeId. But I should do that for other type (Salary, notes, …)

2) Creation of a new type "annexe" and use the "sg:relatedto" : We could give link to the parent ("Order") the new annexe and give link to the "annexe" to the "Order".

3) We could create an aspect : "isAnnexe" with a field annexeNb. After that, if we want to annexe a file to an "Order", we create a new "Order" with same key (firmNb, documentNb) and we add the aspect and give a number to annexNb.

What could be the best between 2 and 3 ? (or other ideas?)

Thanks.

viralshah

What you need is to define associations in your custom model. You will also need to decide whether you need normal association or child association. If the child document should not exist without the paret document, go for child association.