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

[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
   ->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

One model by theme
No enterprise-wide root type
Like 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 aspects
One 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