topic Re: Content Model : Best practices in Alfresco Archive

Content Model : Best practices

dranakan — Tue, 30 Jun 2009 13:51:03 GMT

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 to

Re: Content Model : Best practices

mrogers — Tue, 30 Jun 2009 19:00:13 GMT

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.

Re: Content Model : Best practices

dranakan — Wed, 01 Jul 2009 07:13:20 GMT

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

Re: Content Model : Best practices

mrogers — Wed, 01 Jul 2009 08:10:07 GMT

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.

Re: Content Model : Best practices

dranakan — Wed, 01 Jul 2009 09:39:16 GMT

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
   ->finance:doc (properties : idFirm, idDocument)
       ->finance:Invoices (…)
           ->finance:Invoices_Debtor
           ->finance:Invoices_Creditor (properties : BVR) 
‍‍‍‍‍‍‍

Model School


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

Comments

Re: Content Model : Best practices

dranakan — Fri, 03 Jul 2009 07:05:54 GMT

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

Re: Content Model : Best practices

jpotts — Wed, 08 Jul 2009 13:57:16 GMT

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

Re: Content Model : Best practices

dranakan — Thu, 09 Jul 2009 09:31:03 GMT

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 :

: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…:?:

Re: Content Model : Best practices

jpotts — Mon, 13 Jul 2009 14:13:27 GMT

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

Jeff

Re: Content Model : Best practices

nikes — Thu, 13 Aug 2009 05:04:24 GMT

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

Re: Content Model : Best practices

jpotts — Tue, 18 Aug 2009 12:56:12 GMT

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

Re: Content Model : Best practices

rudyanto — Wed, 23 Sep 2009 04:43:10 GMT

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

Re: Content Model : Best practices

dranakan — Wed, 23 Sep 2009 06:46:24 GMT

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 ?

Re: Content Model : Best practices

nikes — Thu, 24 Sep 2009 09:59:16 GMT

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

Re: Content Model : Best practices

rudyanto — Thu, 24 Sep 2009 16:28:59 GMT

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

Re: Content Model : Best practices

dranakan — Fri, 26 Mar 2010 14:18:54 GMT

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.

Re: Content Model : Best practices

viralshah — Tue, 06 Apr 2010 09:08:26 GMT

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.