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.

Alfresco Data Dictionary

andrea_girardi

Salve a tutti,

la mia domanda e` di natura teorica, nel senso che, leggendo la documentazione ho visto che ci sono varie tipologie di oggetti che possono essere utilizzati per modellare i propri contenuti ma, trovandomi ora a doverli utilizzare, mi trovo un po' in difficoltà`, probabilmente perché non ho ancora ben capito come funzionino e quale sia giusto utilizzare.

Io avrei dovrei importare dei dati presenti su un db e, per semplicità, supponiamo io abbia una sola tabella con i seguenti campi:

News(news_id, titolo, subject, summary, body, image_name, author, date_creation)

A questo punto la cosa che cercherei di fare e` creare un type in alfresco per rappresentare il mio record nel DB esterno. Pero`, mi chiedo, e` più` giusto creare type, un content type o un aspect? Qualcuno può` spiegarmi come scegliere il tipo oggetto per rappresentare il mio dato?

Grazie per la disponibilità e la pazienza

Andrea

Find more posts tagged with

Comments

openpj

A questo punto la cosa che cercherei di fare e` creare un type in alfresco per rappresentare il mio record nel DB esterno. Pero`, mi chiedo, e` più` giusto creare type, un content type o un aspect? Qualcuno può` spiegarmi come scegliere il tipo oggetto per rappresentare il mio dato?

Questo dipende da come deve essere rappresentato il tuo modello dati, tipicamente in un repository ECM si vuole non solo importare dei dati, ma relazionarli e gestirli in modo che non si debba più ragionare con un modello relazionale, ma con un modello strutturato con nodi, associazioni e azioni.

Prima di partire ad implementare, potrebbe essere utile analizzare gli altri oggetti coinvolti.

Di seguito le mie domande:

Quali altri oggetti di dominio devono essere importati nel repository?
Quali sono i legami tra i diversi oggetti di dominio?
Quali processamenti (conversioni, trasformazioni, etc..) devono essere attivati sui contenuti?

andrea_girardi

Grazie per la risposta,

la cosa che non mi e` chiara e` la seguente: io ho dei content da caricare nel mio archivio (intesi come articoli che verranno visualizzati poi nello share o in una webapplication) a cui ho aggiunto delle proprieta` estendendo il modello (la sorgente dei dati e` un archivio MS SQL Server).

Ovviamente gli articoli non sono gli unici dati che devo caricare perché` lo schema dei dati e` più complesso, mi servono infatti dei parametri aggiuntivi quali Autore, e molte altre informazioni strutturate in tabelle con chiavi esterne. La mia domanda e`, devo mettere tutto dentro lo stesso "type" oppure ha senso creare una struttura simile a quella presente nel DB Sql Server? Cioe`, ha senso mantenere una struttura molto simile al DB Relazionale sorgente dei dati oppure e` una cosa sbagliata da fare in un ECM?

Il mio dubbio deriva dal fatto che mi risulta ancora un po' non familiare poter navigare come in un file system all'interno del repository. Mi rendo conto che un repository e` adatto a contenere oggetti ma se ho degli elementi che non sono propriamente oggetti ma rappresentano delle strutture dati, perché creare un oggetto fisico nel repository?

Spero di essere chiaro, anche se non e` così semplice visto che la cosa proprio non mi e` chiara

Grazie per la pazienza!

Grazie,
Andrea

openpj

Ovviamente gli articoli non sono gli unici dati che devo caricare perché` lo schema dei dati e` più complesso, mi servono infatti dei parametri aggiuntivi quali Autore, e molte altre informazioni strutturate in tabelle con chiavi esterne. La mia domanda e`, devo mettere tutto dentro lo stesso "type" oppure ha senso creare una struttura simile a quella presente nel DB Sql Server? Cioe`, ha senso mantenere una struttura molto simile al DB Relazionale sorgente dei dati oppure e` una cosa sbagliata da fare in un ECM?

Puoi mettere tutto dentro un unico type, se effettivamente poi questo gruppo di metadati non vengono utilizzati anche da altri type. Se hai dei type in comune tra tutte le tipologie di contenuto allora la cosa migliore da fare è quella di definire un aspect al cui interno definire il gruppo di proprietà ed associazioni che vuoi aggiungere o togliere dinamicamente sulle istanze di contenuto.

In generale inoltre l'ECM può essere utilizzato anche per gestire solo records, esattamente come un database, quindi se hai anche dei dati di sola anagrafica, puoi strutturarli esattamente come un database, ma le associazioni tra i contenuti in un prodotto ECM le potrai definire tramite il motore della associazioni e non tramite foreign key.

Il mio dubbio deriva dal fatto che mi risulta ancora un po' non familiare poter navigare come in un file system all'interno del repository. Mi rendo conto che un repository e` adatto a contenere oggetti ma se ho degli elementi che non sono propriamente oggetti ma rappresentano delle strutture dati, perché creare un oggetto fisico nel repository?

Ti ho risposto precedentemente, in Alfresco puoi anche modellare un type senza necessità che esista il file binario su file system, basta creare un type che estenda il tipo sys:base.