Differenze tra le versioni di "Inserimento dati personalizzabile: Controllo meta dati"
imported>Root |
imported>Root |
||
(3 versioni intermedie di uno stesso utente non sono mostrate) | |||
Riga 1: | Riga 1: | ||
Questo controllo permette di visualizzare/modificare i metadati associati ad un owner di meta dati, tipicamente un elemento documentale. | Questo controllo permette di visualizzare/modificare i metadati associati ad un owner di meta dati, tipicamente un elemento documentale. | ||
E' possibile utilizzare questo controllo solamente su owner di meta dati con meta dati associati, in quanto al momento il controllo non è in grado di effettuare l'associazione iniziale di meta dati all'owner. | E' possibile utilizzare questo controllo solamente su owner di meta dati con meta dati associati, in quanto al momento il controllo non è in grado di effettuare l'associazione iniziale di meta dati all'owner. | ||
==Premessa sui mapping== | ==Premessa sui mapping== | ||
Per descrivere il funzionamento della action supponiamo di avere scelto una tipologia di dati sulla quale siano stati definiti tre mapping chiamati < | Per descrivere il funzionamento della action supponiamo di avere scelto una tipologia di dati sulla quale siano stati definiti tre mapping chiamati <code>padre</code> (scalare), <code>madre</code> (scalare), <code>figli</code> (array). Ognuno di questi mapping utilizza la classe chiamata <tt>persona</tt> (quindi padre, madre e figli sono tutti <tt>persona</tt>). | ||
Supponiamo inoltre che la classe persona definisca gli attributi <tt>cognome</tt>, <tt>nome</tt>, <tt>data_nascita</tt>. | Supponiamo inoltre che la classe persona definisca gli attributi <tt>cognome</tt>, <tt>nome</tt>, <tt>data_nascita</tt>. | ||
Riga 9: | Riga 11: | ||
=== owner_class_name (input) === | === owner_class_name (input) === | ||
E' la tipologia di oggetti da gestire (classe java del DAC). Il default vale < | E' la tipologia di oggetti da gestire (classe java del DAC). Il default vale <code>it.saga.library.gestioneDocumentale.flows.DocDACElementi</code>, che si presume essere il caso di più frequente utilizzo ma è sufficiente modificare il nome per utilizzare altre tipologie di oggetti. La tipologia di oggetti specificata deve obbligatoriamente supportare la gestione dei metadati, pena un errore a runtime. | ||
=== owner_pkid (input) === | === owner_pkid (input) === | ||
Riga 15: | Riga 17: | ||
=== meta_mapping_names (input) === | === meta_mapping_names (input) === | ||
E' un array di stringhe. Se non specificato l'interfaccia mostra tutte le sezioni (o mapping) presenti nell'oggetto. E' possibile specificare una parte dei mapping (utilizzando il loro nome come definito in fase di design del mapping per la tipologia di oggetti specifica). Se si specificano nomi di mapping inesistenti l'informazione viene ignorata e non genera errori. E' possibile utilizzare, oltre al solo mapping name, anche la notazione mappingName@style, permettendo in tal modo di specificare uno stile specificamente per singolo mapping, a differenza del parametro style descritto successivamente, che opera globalmente su tutti i mapping. In presenza di tale parametro, la notazione mappingName@style ha comunque la precedenza. | E' un array di stringhe. Se non specificato l'interfaccia mostra tutte le sezioni (o mapping) presenti nell'oggetto. E' possibile specificare una parte dei mapping (utilizzando il loro nome come definito in fase di design del mapping per la tipologia di oggetti specifica). Se si specificano nomi di mapping inesistenti l'informazione viene ignorata e non genera errori. E' possibile utilizzare, oltre al solo mapping name, anche la notazione <code>mappingName@style</code>, permettendo in tal modo di specificare uno stile specificamente per singolo mapping, a differenza del parametro style descritto successivamente, che opera globalmente su tutti i mapping. In presenza di tale parametro, la notazione <code>mappingName@style</code> ha comunque la precedenza. | ||
=== style (input) === | |||
Permette di comunicare ad eventuali editor di meta dati customizzati il valore del parametri di supporto "<code>[style]</code>", utilizzabile per eventuali customizzazioni dell'editor stesso (visibilità di pannelli, abilitazione di controlli e quant'altro). | |||
=== owner_details_mode (input) === | |||
Indica se debba esserci o meno il pulsante per l'accesso all'owner dei meta dati (ad esempio all'elemento documentale). | |||
=== defaults_count (input) === | |||
Permette di specificare i valori di default da utilizzare (in override a quelli standard) durante la generazione di nuovi item di meta dati (ad esempio gli array) | |||
=== input_count (input) === | |||
Permette di specificare degli input che vanno ad influenzare in tempo reale il valore del meta dato indicato. Il valore può essere fornito da altri controlli presenti nella frame personalizzata. | |||
===scalar_to_array (input)=== | |||
Indica come la action deve comportarsi quando il workflow riceve in input un parametro di tipo scalare e lo deve applicare all'attributo di mapping di tipo array. I possibili valori sono <code>FIRST_ITEM</code> e <code>ALL_ITEMS</code> di seguito spiegati. | |||
Supponiamo che si voglia accedere al cognome dei figli <code>figli.cognome</code> e che l'oggetto specifico contenga tre figli. Se passiamo uno scalare di tipo stringa che contiene il valore <tt>Rossi</tt>, è possibile: | |||
* in caso di <code>FIRST_ITEM</code>: Solo al primo figlio verrà impostato il cognome con il valore <code>Rossi</code>. I rimanenti non verrano alterati. | |||
* in caso di <code>ALL_ITEMS</code>: A tutti i figli verrà impostato il cognome con il valore <code>Rossi</code>. | |||
Se invece viene passato un valore di tipo array verranno utilizzati tutti gli elementi di quest'ultimo fino ad esaurimento. Nel caso in cui l'array di valori contenga piu' elementi di quanti siano i figli, verranno creati tanti metadati <code>figli</code> quanti servono per esaurire completamente l'array di valori. | |||
'''''Esempio:''' Si vuole accedere a <code>figli.nome</code> con i valori <code>[ "Luca", "Marco" ]</code>. Se i metadati contengono un unico figlio, questo acquisirà nome <tt>Luca</tt> e successivamente verrà generato un nuovo metadato <code>figli</code> che acquisirà nome <tt>Marco</tt>. Eventuali attributi obbligatori verranno ignorati. Se i figli sono due i nomi verranno impostati nell'ordine ai due figli. Se invece sono tre il terzo figlio non verrà alterato.'' | |||
=== | ===array_behavior (input)=== | ||
Permette di | Permette di specificare se i valori in input agli array debbano andare a sostituire il valore precedente (<code>SET</code>) oppure se debbano essere accodati (<code>APPEND</code>). | ||
'''''Attenzione:''' L'utilizzo di <code>APPEND</code> con il controllo visuale potrebbe portare alla generazione di un numero spropositato di elementi array, dato che l'accodamento avviene ad ogni ricalcolo dei componenti visuali, per cui potenzialmente ad ogni modifica dei valori di input del controllo. L'opzione è presente per completezza ma si suggerisce di utilizzare <code>SET</code> con il controllo visuale.'' | |||
=== | ===output_count (input)=== | ||
Permette di specificare degli output che vengono prodotti reale dal meta dato indicato. Il valore può essere utilizzato da altri controlli presenti nella frame personalizzata. | |||
=== input_count | ==Parametri variabili== | ||
In funzione del parametro <code>defaults_count,</code> <code>input_count</code>, <code>output_count</code> vengono generate delle triplette di parametri come segue (<code>X</code> indica il numero progressivo) | |||
=== | ===default_X_name (input)=== | ||
Si vedano le considerazioni per <code>attr_X_name</code> descritte successivamente, applicate al concetto di valore di default per i nuovi elementi creati. Se il meta dato in attualmente a video non possiede tali attributi, il default viene ignorato. | |||
=== | ===default_X_type (input)=== | ||
Si vedano le considerazioni per <code>attr_X_type</code> descritte successivamente, applicate al concetto di valore di default per i nuovi elementi creati. | |||
=== | ===default_X_value (input)=== | ||
Si vedano le considerazioni per <code>attr_X_value</code> descritte successivamente, applicate al concetto di valore di default per i nuovi elementi creati. | |||
=== | ===in_attr_X_name (input)=== | ||
Descrive il nome completo dell'attributo che si intende accedere. Se ad esempio vogliamo accedere il cognome del padre dovremo scrivere <code>padre.cognome</code>. In realtà questa è una notazione compatta accettata dal controllo fintanto che la classe di metadati non utilizza l'erediterietà multipla. In caso di ereditarietà multipla potrebbe accadere che la classe erediti da due superclassi entrambe con l'attributo <tt>cognome</tt>. In questo caso si potrebbero verificare dei malfunzionamenti. Infatti il controllo utilizza implicitamente il nome della classe presente nel mapping (<tt>persona</tt> in questo caso). Se tale classe contiene l'attributo specificato questo viene trovato, se invece l'attributo appartiene ad una superclasse questo non viene trovato e l'input non ha effetti su tale attributo. Per risolvere questo tipo di problemi è quindi necessario scrivere il nome completo di classe <code>padre.<superclasse>.cognome</code>. Se il meta dato in attualmente a video non possiede tali attributi, l'input viene ignorato. | |||
=== | ===in_attr_X_type (input)=== | ||
Indica il tipo dati dell'attributo. Potenzialmente può essere differente dal tipo dati dell'attributo dei metadati, è solo una indicazione al workflow di come si voglia effettuare la conversione. Si suggerisce di impostare un tipo dati congruo con quello del metadato. | |||
=== | ===in_attr_X_value (input)=== | ||
Permette di inviare al controllo il valore da impostare nell'attributo. Il sistema effettua eventuali conversioni di tipo (quando possibile). | |||
=== | ===out_attr_X_name (input)=== | ||
Descrive il nome completo dell'attributo che si intende accedere. Se ad esempio vogliamo accedere il cognome del padre dovremo scrivere <code>padre.cognome</code>. In realtà questa è una notazione compatta accettata dalla action fintanto che la classe di metadati non utilizza l'erediterietà multipla. In caso di ereditarietà multipla potrebbe accadere che la classe erediti da due superclassi entrambe con l'attributo <code>cognome</code>. In questo caso si potrebbero verificare dei malfunzionamenti. Infatti la action utilizza implicitamente il nome della classe presente nel mapping (<tt>persona</tt> in questo caso. Se tale classe contiene l'attributo specificato questo viene trovato, se invece l'attributo appartiene ad una superclasse questo non viene trovato e la action non ha effetti su tale attributo. Per risolvere questo tipo di problemi è quindi necessario scrivere il nome completo di classe <code>padre.<superclasse>.cognome</code>. Se il meta dato attualmente a video non possiede tali attributi, viene prodotto il valore <code>null</code>. | |||
=== | ===out_attr_X_type (input)=== | ||
Indica il tipo dati dell'attributo. Potenzialmente può essere differente dal tipo dati dell'attributo dei metadati, è solo una indicazione al workflow di come si voglia effettuare la conversione. Si suggerisce di impostare un tipo dati congruo con quello del metadato. | |||
=== | ===out_attr_X_mode (input)=== | ||
Indica la modalità di reperimento dei dati. Sono possibili le seguenti modalità: | |||
* <code>ONLY REAL DATA</code>: I dati vengono tornati solamente se esistono come dati associati all'owner. | |||
* <code>ALLOW DUMMY DATA</code>: In mancanza di dati reali associati all'owner vengono tornati i dati presenti nella definizione della classe (solitamente <code>null</code> oppure il valore di default se definito). | |||
=== | ===out_attr_X_value (output)=== | ||
La action torna il valore dell'attributo specificato. Qualora l'attributo si riferisca ad un mapping di tipo array ed esistano più metadati nell'array (ad esempio due figli, uno di nome <tt>Luca</tt> ed uno di nome <tt>Marco</tt> verrà tornato un arry nella forma <code>[ "Luca", "Marco" ]</code>. Se <code>attr_X_type</code> specifica un tipo scalare, l'array verrà convertito in scalare (quando possibile). | |||
== Attributi di base == | == Attributi di base == | ||
Per una spiegazione dei rimanenti attributi riferirsi alla pagina [[Inserimento dati personalizzabile: Attributi base degli oggetti]] | Per una spiegazione dei rimanenti attributi riferirsi alla pagina [[Inserimento dati personalizzabile: Attributi base degli oggetti]] |
Versione attuale delle 09:41, 28 ago 2017
Questo controllo permette di visualizzare/modificare i metadati associati ad un owner di meta dati, tipicamente un elemento documentale.
E' possibile utilizzare questo controllo solamente su owner di meta dati con meta dati associati, in quanto al momento il controllo non è in grado di effettuare l'associazione iniziale di meta dati all'owner.
Premessa sui mapping
Per descrivere il funzionamento della action supponiamo di avere scelto una tipologia di dati sulla quale siano stati definiti tre mapping chiamati padre
(scalare), madre
(scalare), figli
(array). Ognuno di questi mapping utilizza la classe chiamata persona (quindi padre, madre e figli sono tutti persona).
Supponiamo inoltre che la classe persona definisca gli attributi cognome, nome, data_nascita.
Attributi specifici
owner_class_name (input)
E' la tipologia di oggetti da gestire (classe java del DAC). Il default vale it.saga.library.gestioneDocumentale.flows.DocDACElementi
, che si presume essere il caso di più frequente utilizzo ma è sufficiente modificare il nome per utilizzare altre tipologie di oggetti. La tipologia di oggetti specificata deve obbligatoriamente supportare la gestione dei metadati, pena un errore a runtime.
owner_pkid (input)
E' la chiave di accesso dell'oggetto specifico di cui si vuole gestire i metadati.
meta_mapping_names (input)
E' un array di stringhe. Se non specificato l'interfaccia mostra tutte le sezioni (o mapping) presenti nell'oggetto. E' possibile specificare una parte dei mapping (utilizzando il loro nome come definito in fase di design del mapping per la tipologia di oggetti specifica). Se si specificano nomi di mapping inesistenti l'informazione viene ignorata e non genera errori. E' possibile utilizzare, oltre al solo mapping name, anche la notazione mappingName@style
, permettendo in tal modo di specificare uno stile specificamente per singolo mapping, a differenza del parametro style descritto successivamente, che opera globalmente su tutti i mapping. In presenza di tale parametro, la notazione mappingName@style
ha comunque la precedenza.
style (input)
Permette di comunicare ad eventuali editor di meta dati customizzati il valore del parametri di supporto "[style]
", utilizzabile per eventuali customizzazioni dell'editor stesso (visibilità di pannelli, abilitazione di controlli e quant'altro).
owner_details_mode (input)
Indica se debba esserci o meno il pulsante per l'accesso all'owner dei meta dati (ad esempio all'elemento documentale).
defaults_count (input)
Permette di specificare i valori di default da utilizzare (in override a quelli standard) durante la generazione di nuovi item di meta dati (ad esempio gli array)
input_count (input)
Permette di specificare degli input che vanno ad influenzare in tempo reale il valore del meta dato indicato. Il valore può essere fornito da altri controlli presenti nella frame personalizzata.
scalar_to_array (input)
Indica come la action deve comportarsi quando il workflow riceve in input un parametro di tipo scalare e lo deve applicare all'attributo di mapping di tipo array. I possibili valori sono FIRST_ITEM
e ALL_ITEMS
di seguito spiegati.
Supponiamo che si voglia accedere al cognome dei figli figli.cognome
e che l'oggetto specifico contenga tre figli. Se passiamo uno scalare di tipo stringa che contiene il valore Rossi, è possibile:
- in caso di
FIRST_ITEM
: Solo al primo figlio verrà impostato il cognome con il valoreRossi
. I rimanenti non verrano alterati. - in caso di
ALL_ITEMS
: A tutti i figli verrà impostato il cognome con il valoreRossi
.
Se invece viene passato un valore di tipo array verranno utilizzati tutti gli elementi di quest'ultimo fino ad esaurimento. Nel caso in cui l'array di valori contenga piu' elementi di quanti siano i figli, verranno creati tanti metadati figli
quanti servono per esaurire completamente l'array di valori.
Esempio: Si vuole accedere a figli.nome
con i valori [ "Luca", "Marco" ]
. Se i metadati contengono un unico figlio, questo acquisirà nome Luca e successivamente verrà generato un nuovo metadato figli
che acquisirà nome Marco. Eventuali attributi obbligatori verranno ignorati. Se i figli sono due i nomi verranno impostati nell'ordine ai due figli. Se invece sono tre il terzo figlio non verrà alterato.
array_behavior (input)
Permette di specificare se i valori in input agli array debbano andare a sostituire il valore precedente (SET
) oppure se debbano essere accodati (APPEND
).
Attenzione: L'utilizzo di APPEND
con il controllo visuale potrebbe portare alla generazione di un numero spropositato di elementi array, dato che l'accodamento avviene ad ogni ricalcolo dei componenti visuali, per cui potenzialmente ad ogni modifica dei valori di input del controllo. L'opzione è presente per completezza ma si suggerisce di utilizzare SET
con il controllo visuale.
output_count (input)
Permette di specificare degli output che vengono prodotti reale dal meta dato indicato. Il valore può essere utilizzato da altri controlli presenti nella frame personalizzata.
Parametri variabili
In funzione del parametro defaults_count,
input_count
, output_count
vengono generate delle triplette di parametri come segue (X
indica il numero progressivo)
default_X_name (input)
Si vedano le considerazioni per attr_X_name
descritte successivamente, applicate al concetto di valore di default per i nuovi elementi creati. Se il meta dato in attualmente a video non possiede tali attributi, il default viene ignorato.
default_X_type (input)
Si vedano le considerazioni per attr_X_type
descritte successivamente, applicate al concetto di valore di default per i nuovi elementi creati.
default_X_value (input)
Si vedano le considerazioni per attr_X_value
descritte successivamente, applicate al concetto di valore di default per i nuovi elementi creati.
in_attr_X_name (input)
Descrive il nome completo dell'attributo che si intende accedere. Se ad esempio vogliamo accedere il cognome del padre dovremo scrivere padre.cognome
. In realtà questa è una notazione compatta accettata dal controllo fintanto che la classe di metadati non utilizza l'erediterietà multipla. In caso di ereditarietà multipla potrebbe accadere che la classe erediti da due superclassi entrambe con l'attributo cognome. In questo caso si potrebbero verificare dei malfunzionamenti. Infatti il controllo utilizza implicitamente il nome della classe presente nel mapping (persona in questo caso). Se tale classe contiene l'attributo specificato questo viene trovato, se invece l'attributo appartiene ad una superclasse questo non viene trovato e l'input non ha effetti su tale attributo. Per risolvere questo tipo di problemi è quindi necessario scrivere il nome completo di classe padre.<superclasse>.cognome
. Se il meta dato in attualmente a video non possiede tali attributi, l'input viene ignorato.
in_attr_X_type (input)
Indica il tipo dati dell'attributo. Potenzialmente può essere differente dal tipo dati dell'attributo dei metadati, è solo una indicazione al workflow di come si voglia effettuare la conversione. Si suggerisce di impostare un tipo dati congruo con quello del metadato.
in_attr_X_value (input)
Permette di inviare al controllo il valore da impostare nell'attributo. Il sistema effettua eventuali conversioni di tipo (quando possibile).
out_attr_X_name (input)
Descrive il nome completo dell'attributo che si intende accedere. Se ad esempio vogliamo accedere il cognome del padre dovremo scrivere padre.cognome
. In realtà questa è una notazione compatta accettata dalla action fintanto che la classe di metadati non utilizza l'erediterietà multipla. In caso di ereditarietà multipla potrebbe accadere che la classe erediti da due superclassi entrambe con l'attributo cognome
. In questo caso si potrebbero verificare dei malfunzionamenti. Infatti la action utilizza implicitamente il nome della classe presente nel mapping (persona in questo caso. Se tale classe contiene l'attributo specificato questo viene trovato, se invece l'attributo appartiene ad una superclasse questo non viene trovato e la action non ha effetti su tale attributo. Per risolvere questo tipo di problemi è quindi necessario scrivere il nome completo di classe padre.<superclasse>.cognome
. Se il meta dato attualmente a video non possiede tali attributi, viene prodotto il valore null
.
out_attr_X_type (input)
Indica il tipo dati dell'attributo. Potenzialmente può essere differente dal tipo dati dell'attributo dei metadati, è solo una indicazione al workflow di come si voglia effettuare la conversione. Si suggerisce di impostare un tipo dati congruo con quello del metadato.
out_attr_X_mode (input)
Indica la modalità di reperimento dei dati. Sono possibili le seguenti modalità:
ONLY REAL DATA
: I dati vengono tornati solamente se esistono come dati associati all'owner.ALLOW DUMMY DATA
: In mancanza di dati reali associati all'owner vengono tornati i dati presenti nella definizione della classe (solitamentenull
oppure il valore di default se definito).
out_attr_X_value (output)
La action torna il valore dell'attributo specificato. Qualora l'attributo si riferisca ad un mapping di tipo array ed esistano più metadati nell'array (ad esempio due figli, uno di nome Luca ed uno di nome Marco verrà tornato un arry nella forma [ "Luca", "Marco" ]
. Se attr_X_type
specifica un tipo scalare, l'array verrà convertito in scalare (quando possibile).
Attributi di base
Per una spiegazione dei rimanenti attributi riferirsi alla pagina Inserimento dati personalizzabile: Attributi base degli oggetti