cancel
Showing results for 
Search instead for 
Did you mean: 

Content Model : Best practices

dranakan
Champ on-the-rise
Champ on-the-rise
Hello Smiley Happy

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 
                 ->me:doc
                               ->me: Invoices (properties : idFirm, idInvoice)
                                             ->me:Invoices_Debtor
                                             ->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 
                 ->me:doc
                               ->me:school
                                             ->me:notes (properties : year)
                                                      ->me:finalExam
                                                      ->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
16 REPLIES 16

jpotts
World-Class Innovator
World-Class Innovator
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
Champ in-the-making
Champ in-the-making
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
Champ on-the-rise
Champ on-the-rise
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
Champ on-the-rise
Champ on-the-rise
Thanks dranakan  Smiley Happy

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
Champ in-the-making
Champ in-the-making
Thanks Nikes & Dranakan  Smiley Very Happy

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

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
Champ on-the-rise
Champ on-the-rise
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
Champ in-the-making
Champ in-the-making
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.