Differenze tra le versioni di "Inserimento dati personalizzabile: Controllo meta dati"
imported>Root |
imported>Root |
||
Riga 17: | Riga 17: | ||
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 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 === | === 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). | 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 === | === 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 === | === 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_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 <tt>FIRST_ITEM</tt> e <tt>ALL_ITEMS</tt> di seguito spiegati. | |||
Supponiamo che si voglia accedere al cognome dei figli <tt>figli.cognome</tt> 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 <tt>FIRST_ITEM</tt>: Solo al primo figlio verrà impostato il cognome con il valore <tt>Rossi</tt>. I rimanenti non verrano alterati. | |||
* in caso di <tt>ALL_ITEMS</tt>: A tutti i figli verrà impostato il cognome con il valore <tt>Rossi</tt>. | |||
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 <tt>figli</tt> quanti servono per esaurire completamente l'array di valori. | |||
'''Esempio:''' Si vuole accedere a <tt>figli.nome</tt> con i valori <tt>[ "Luca", "Marco" ]</tt>. Se i metadati contengono un unico figlio, questo acquisirà nome <tt>Luca</tt> e successivamente verrà generato un nuovo metadato <tt>figli</tt> 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=== | ||
=== | ===output_count (input)=== | ||
Indica il numero di attributi che si intende accedere con questa action. | |||
=== output_count | ==Parametri variabili== | ||
In funzione del parametro <tt>defauls_count</tt>, <tt>input_count</tt>, <tt>output_count</tt> vengono generate delle triplette di parametri come segue (<tt>X</tt> 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. | |||
==== | ==== 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 <tt>padre.cognome</tt>. 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 <tt>padre.<superclasse>.cognome</tt>. | |||
===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). | |||
===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 <tt>padre.cognome</tt>. 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 <tt>cognome</tt>. 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 <tt>padre.<superclasse>.cognome</tt>. | |||
===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. | |||
===attr_X_mode (input)=== | |||
Indica la modalità di reperimento dei dati. Sono possibili le seguenti modalità: | |||
* <tt>ONLY REAL DATA</tt>: I dati vengono tornati solamente se esistono come dati associati all'owner. | |||
* <tt>ALLOW DUMMY DATA</tt>: In mancanza di dati reali associati all'owner vengono tornati i dati presenti nella definizione della classe (solitamente <tt>null</tt> oppure il valore di default se definito). | |||
=== 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 <tt>[ "Luca", "Marco" ]</tt>. Se <tt>attr_X_type</tt> 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 delle 09:17, 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 valore Rossi. I rimanenti non verrano alterati.
- in caso di ALL_ITEMS: A tutti i figli verrà impostato il cognome con il valore Rossi.
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
output_count (input)
Indica il numero di attributi che si intende accedere con questa action.
Parametri variabili
In funzione del parametro defauls_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.
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.
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).
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.
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.
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 (solitamente null oppure il valore di default se definito).
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