Differenze tra le versioni di "Modifica interattiva metadati"

Da wiki.maggioli.it.
Jump to navigation Jump to search
imported>Root
imported>Root
 
(Una versione intermedia di uno stesso utente non è mostrata)
Riga 11: Riga 11:


===owner_class_name (input)===
===owner_class_name (input)===
E' la tipologia di oggetti da gestire (classe java del DAC). Il default vale <tt>it.saga.library.gestioneDocumentale.flows.DocDACElementi</tt>, 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.
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)===
E' la chiave di accesso dell'oggetto specifico di cui si vuole gestire i metadati.
E' la chiave di accesso dell'oggetto specifico di cui si vuole gestire i metadati.


===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' 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).


==Considerazioni==
==Considerazioni==
Una volta che l'utente preme il pulsante di conferma la action causa l'aggiornamento dei meta dati sul database e termina, facando così avanzare il motore di workflow sull'azione successiva. Se invece si preme il tasto di annullamente eventuali modifiche vengono perse. Non esiste uno stato intermedio che permetta di chiudere l'interfaccia mantenendo eventuali modifiche in corso senza fare avanzare il workflow.
Una volta che l'utente preme il pulsante di conferma la action causa l'aggiornamento dei meta dati sul database e termina, facando così avanzare il motore di workflow sull'azione successiva. Se invece si preme il tasto di annullamente eventuali modifiche vengono perse. Non esiste uno stato intermedio che permetta di chiudere l'interfaccia mantenendo eventuali modifiche in corso senza fare avanzare il workflow.

Versione attuale delle 09:44, 28 ago 2017

Questa azione permette di visualizzare all'utente la maschera di modifica dei metadati associati ad un generico oggetto (che supporti i metadati). E' possibile specificare la tipologia dell'oggetto, il suo identificativo e le sezioni visibili dei metadati che si vogliono esporre alla modifica.

Parametri

Segue la lista dei parametri della action con la loro funzione.

title (input)

Rappresenta il titolo della action nella lista delle attività e anche il titolo della finestra di editing quando viene aperta all'utente.

note (input)

Rappresenta le note della action nella lista delle attività.

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

Considerazioni

Una volta che l'utente preme il pulsante di conferma la action causa l'aggiornamento dei meta dati sul database e termina, facando così avanzare il motore di workflow sull'azione successiva. Se invece si preme il tasto di annullamente eventuali modifiche vengono perse. Non esiste uno stato intermedio che permetta di chiudere l'interfaccia mantenendo eventuali modifiche in corso senza fare avanzare il workflow.