What is best practice to implement documents model ?

[ribz33]

Hi,

im wondering about what is best way to implement documents model in Alfresco.

Is it better to create one type per document or make generic document type and use aspects ?

I will try to give a simple example:
We can imagine 2 documents types :
:arrow:  "report" with for instance this custom properties :
    - domain
    - origin

:arrow:  "letter" :
    - receiver society
    - receiver person

To implement this model what is best practice ? make 2 different types or 2 aspects ?

Strenght for types are :
    - its better in interface, user choose type, and see dedicated properties
    - its available from all spaces
    - (and i think its more logical)

Weakness for types are :
    - I cant change type in interface if i did mistake, i need to delete and recreate document.
    - I cant choose appropriate type with FTP, CIFS, Webdav and dont change it later!
    - if i create new type in model i cant delete it after, because i will have integrity errors on repository.


Strenght for aspects are :
    - user can change aspect
    - with rules it can be automatised on some space
    - we can use CIFS, etc.

Weakness for aspects are :
    - need a voluntary action of user to specify generic document in interface and its difficult to make it automatic most of time

There is probably more things to tell about this… (discussion is open)

I dont find all satisfaction in two approach…

I want to find best practice to implement model on Alfresco, and make implementation as clever as possible.

You are all free to give your opinion and your experience about it…

[michael_kiske]

Hi.

I'm also working with types and aspects. The best way I have found to do it is assigning properties to aspects and making new content type with aspects instead of properties. That way, you can create different types of contents that share some properties of the model, and logically don't inherit the type of content.

HTH.

Michael

[rdanner]

Hi,

im wondering about what is best way to implement documents model in Alfresco.

Is it better to create one type per document or make generic document type and use aspects ?

I will try to give a simple example:
We can imagine 2 documents types :
:arrow:  "report" with for instance this custom properties :
    - domain
    - origin

:arrow:  "letter" :
    - receiver society
    - receiver person

To implement this model what is best practice ? make 2 different types or 2 aspects ?

Strenght for types are :
    - its better in interface, user choose type, and see dedicated properties
    - its available from all spaces
    - (and i think its more logical)

Weakness for types are :
    - I cant change type in interface if i did mistake, i need to delete and recreate document.
    - I cant choose appropriate type with FTP, CIFS, Webdav and dont change it later!
    - if i create new type in model i cant delete it after, because i will have integrity errors on repository.


Strenght for aspects are :
    - user can change aspect
    - with rules it can be automatised on some space
    - we can use CIFS, etc.

Weakness for aspects are :
    - need a voluntary action of user to specify generic document in interface and its difficult to make it automatic most of time

There is probably more things to tell about this… (discussion is open)

I dont find all satisfaction in two approach…

I want to find best practice to implement model on Alfresco, and make implementation as clever as possible.

You are all free to give your opinion and your experience about it…

It's hard to give advice on a model – it really depends on the problem you are trying to solve.  Here's some simple advice, not sure it will help.

I think you want to take a similar approach to that of OOP.   Use aspects for cross cutting concerns (where many types can reuse the same properties and behavior)  and types when you are trying to express a class of something.  Don't go crazy with types in your repository. Avoid deep hierachies of types, its usually a indication that your model is wrong.

Keep it simple and it will be easier to maintain in the long run.