Editing Regole sviluppo

[[File:Help modello oggetto.png|Help modello oggetto.png]]

[[File:Help modello oggetto 2.png|Help modello oggetto 2.png]]

[[File:Help modello oggetto 3.png|Help modello oggetto 3.png]]

[[File:Help regole sviluppo .png||]]



Quando si devono realizzare degli sviluppi specifici, bisogna organizzarsi affinchè questi siano più perenni possibili a fronte dei cambi di versione. La prima parte di questo documento dettaglia i modi di agire.

Indipendentemente da questo primo punto, è possibile che ci si ponga una domanda di organizzazione tecnica dei dossier in cui gli sviluppi vengono fatti. Questo quesito viene affrontato nella seconda parte della documentazione.

== Protezione delle modifiche fatte ==

Il software permette di inglobare degli sviluppi specifici all'interno dello standard, principalmente modificando ad un livello di dettaglio alcuni elementi dello standard per rispondere ad esigenze che lo standard non copre.

Per facilitare la manutenzione di questi specifici perennizzandoli finc quando è possibile, vanno rispettate un certo numero di regole. Queste regole sono 5 e sono riportate qui sotto. Il loro rispetto permetterà di limitare al massimo i problemi in caso di patch o di aggiornamento.

Ma prima di cominciare, occorre sapere che esistono dei limiti insuperabili. A prescindere dalla sofisticazione del sistema dei codici attività, vi sono degli sviluppi che è meglio realizzare riscrivendoli invece che con modifica di un oggetto standard. Così, se una videata è stata modificata così pesantemente (in particolare se i blocchi sono stati modificati) che diventa difficile da mantenere per differenza con la videata standard, è forse meglio crearne una nuova. Lo stesso se una funzione standard è modificata in modo radicale, è forse meglio riscrivere una funzione specifica, basandosi su sotto-programmi standard documentati da ADONIX.

Si tratta di un elemento da considerare prima di ogni sviluppo specifico: è meglio riscrivere o modificare gli elementi forniti dallo standard?

Una volta somposta questa domanda caso per caso, le regole di perennizzazione sono le seguenti:

=== Regola numero 1: Non modificare mai un sorgente standard ===

Il non rispetto di questa regola è il modo migliore per ottenere un dossier impossibile da mantenere.

Infatti, il fatto che un sorgente standard sia consegnato non significa che questo sorgente debba essere modificato. I sorgenti standard consegnati sono per fini di consultazione.

Questo limite non è pertanto un limite che crea disturbo. Infatti, nella maggior parte dei casi, si chiama un programma specifico dedicato, quando questo esiste. E' generalmente il caso:

* in gestione oggetto, a lato del programma SUBXXX, dove XXX è il codice dell'oggetto, esiste un programma SPEXXX per gestire lo specifico.

* in consultazione, a lato del programma standard (chiamato in generale CNSXXXSTD, dove XXX è il codice della consultazione), è possibile indicare il nome di un programma specifico (in generale CNSXXXSPE).

* nel dizionario delle azioni, se l’azione è di tipo Programma standard e il nome del programma comincia per SUB, si può anche utilizzare il programma equivalente che comincia per SPE; se il nome del programma (TRAITE per esempio) non comincia per SUB, il programma specifico associato si chiama XYTRAITE e permette quindi di realizzare degli specifici senza toccare il codice di origine.

* nel dizionario delle azioni, se l’azione è di tipo Inserimento finestra, la finestra principale si chiama per esempio FENETRE, un programma specifico, di nome XWFENETRE, permette di realizzare degli specifici senza toccare il codice di origine.

Inoltre se, per intervenire, uno specifico ha bisogno della modifica di un programma standard, l'unica maniera ammissibile per risolvere i problemi di perennizzazione consiste nel richiedere un entry point ad ADONIX.
=== Regola numero 2: utilizzare strettamente le regole per battezzare tutti gli elementi aggiunti ===

Per evitare eventuali collisioni con versioni future del software, è obbligatorio chiamare gli elementi aggiunti con nomi che cominciano con X, Y o Z. Per elemento si intende tutto ciò che si trova nel seguente riquadro:


{| class="wikitable"
|+ Caption text
|-
! Funzione di definizione !! Descrizione
|-
| GESATY|| Tipi di dati
|-
| GESATB||Tabelle
|-
| GESACV||Codici attività
|-
| GESAMK||Videate
|-
| GESAWI (*)||Finestre 
|-
| GESAOB||Oggetti
|-
| GESACN||Consultazioni
|-
| GESACT||Azioni
|-
| ADOTRT||Programmi
|-
| GESARP||Stampe
|}

(*) Fatta eccezione per le finestre che cominciano per O, che sono associate ad un oggetto il cui nome comincia con X, Y o Z.

Per alcuni elementi esistono delle regole per dare un nome. Infatti:

* vanno per forza aggiunti dei parametri specifici in capitoli dedicati, il cui codice deve cominciare per X, Y, o Z.

* vanno per forza aggiunti dei messaggi specifici nei capitoli il cui numero è compreso tra 160 e 169.

* i menù locali specifici e le tabelle diverse specifiche devono utilizzare le porzioni di numerazione comprese tra 1000 e 1999.

Infine, il nome dei campi aggiunti in tabelle o videate standard devono cominciare con X_, Y_, o Z_.
=== Regola numero 3: proteggere con un codice attività, ma al livello più di dettaglio possibile ===

Il rispetto delle regole per dare un nome non basta a perennizzare degli elementi. Occorre anche proteggerli con un codice attività che cominci con X, Y o Z. Ma si consiglia di proteggere solo le modifiche fatte a livello di dettaglio più sottile, per beneficiare al massimo delle evoluzioni apportate sugli altri elementi di un elemento del software. Così è possibile proteggere:

* Una videata intera o una tabella intera. In questo caso, ogni modifica apportata sulla videata o sulla tabella da una patch verrà ignorata. Questo tipo di protezione viene consigliato solo per le nuove videate o tabelle o in caso di modifica totale di una videata o di una tabella. Diventa allora inutile mettere un codice attività specifico ai livelli sottostanti, salvo si desideri servirsi di un codice attività per disporre di varianti nella videata o nella tabella.

* Il blocco di una videata. In caso di patch non viene modificato nessuno dei campi del blocco. Anche qui si tratta di un livello abbastanza alto di protezione, poiché tutti i campi del blocco non vengono più modificati in caso di patch. Bisogna quindi proteggere in modo più sottile quando ciò è possibile. Resta il fatto che si tratta dell'unico livello accettabile se si modifica il posizionamento di un blocco standard, o se si cerca di rendere configurabile alla gestione di dossier il numero di righe di un riquadro che altrimenti sarebbe fisso.

* Il campo di una videata o il campo di una tabella o l'indice di una tabella. E' il livello da utilizzare nel caso in cui si modifichino le caratteristiche di un campo (formato, tipo, descrizione, lunghezza...). Questo livello di protezione è molto sottile, sapendo che il solo conflitto potenziale in caso di patch verte sui campi protetti.

* Una tabella collegata, un folder, una lista di selezione in un oggetto (è preferibile ad una protezione globale dell'oggetto).

* Un'opzione, una variabile associata ad una funzione (è preferibile ad una protezione globale della funzione).

Alcuni elementi non possono essere protetti in modo dettagliato (è il caso delle stampe). In questo caso, l'unica soluzione è quella di proteggere globalmente la stampa, installando il file con estensione rpt a livello del dossier di produzione, sapendo che sarà anche possibile decidere di rinominarlo.

C'è tutta una serie di casi in cui i codici attività non sono utili, soprattutto sui campi delle videate:

* Se si vuole aggiungere un controllo supplementare su un campo e se questo controllo può essere definito da una tabella di controllo, è meglio implementarlo così: si tratta infatti di una parametrizzazione che non ha bisogno di essere protetta.

* Lo stesso se si vuole limitare l'accesso al campo in funzione di un utente: le assegnazioni di codici di accesso consistono parametrizzazione.

* Lo stesso se si vuole cambiare interamente gli attributi del tipo di dati associato al campo, è meglio modificare il tipo di dati e proteggerlo da un codice attività: la protezione del campo è allora inutile.

* Se si vogliono aggiungere delle azioni dette « specifiche » (chiamate SPE o SPX), occorre sapere che queste azioni rimangano invariate in caso di patch, anche se il campo non è protetto. Quindi non è utile aggiungere un codice attività sul campo se non sono state fatte altre modifiche. Se delle azioni specifiche impongono di aprire una finestra, queste azioni devono essere catalogate nel dizionario delle azioni. D'altronde, non appena il codice dell'azione comincia per X, Y o Z, questa è protetta allo stesso modo senza che sia necessario proteggere il campo. In compenso è necessario proteggere l'azione con un codice attività (sarà richiamata solo se il codice è Attivo).

* Se si vuole cancellare un'azione standard su un campo, è più semplice completarla con un'azione chiamata SPX invece che cancellarla (così, la protezione tramite codice attività non sarà necessaria sul campo).
=== Regola numero 4: Attenzione agli inserimenti su dei sotto elementi esistenti ===

Gli inserimenti di sotto elementi in un elemento non permettono, in alcuni casi, la perennizzazione. Questo riguarda i seguenti casi:

* aggiungere un indice in una tabella standard deve essere fatto alla fine dell'elenco degli indici e soprattutto non all'inizio di tale elenco (il primo indice è l'indice di default). In compenso non vi sono vincoli sui campi. Si consiglia comunque di non chiamarli in modo consecutivo nel formato ABBRn, dove ABBR è l'abbreviazione della tabella e n il numero di riga (infatti è possibile che un'evoluzione dello standard necessiti dell'aggiunta di un indice standard).

* i blocchi di una videata sono conosciuti solo tramite il loro numero. Così, se si desidera aggiungere un blocco in una videata, occorre sempre metterlo alla fine (giocare sulle posizioni di inserimento). Nemmeno qui vi sono vincoli sui campi.

* lo stesso vale per i folder di una tabella, le liste di selezione di un oggetto (in versione 140 si differenzia l'ordine del loro ordine di apparizione, poiché esiste una campo rank).
=== Regola numero 5: Prima dell'installazione di ogni patch o di ogni versione, utilizzare il tester di patch ===

Questo strumento è stato realizzato per permettere di evidenziare i potenziali conflitti al momento dell'installazione di patch. Infatti, legge la testata dei file di patch presenti in una data directory e visualizza in una traccia l'elenco degli elementi presenti in questa lista e che sono oggetto di specifici. Se l'elenco in questione è vuoto, non vi è rischio di conflitti. Al contrario, l'elenco degli elementi in conflitto è generalmente scarso e basta allora esaminare in dettaglio i pochi elementi che vi si trovano.

Quando si installa una versione tramite un CD, (in una directory dipendente dal software, sulla versione 130 di ADONIX X3 ad esempio, si trovano nella directory X3Patch\X3V130_technical) vi sono una serie di cartelle chiamate in funzione delle versioni intermedie del software (P131, P132, P133…), che contengono dei file chiamati List_nnn.dat. Questi file contengono solo la testata degli elementi contenuti nelle patch consecutive che permettono di passare da una versione all'altra. E' quindi possibile utilizzare questi file nello stesso modo con il tester di patch, per assicurarsi dei potenziali conflitti (si partirà dalla lista seguendo la lista corrente installata sul dossier da aggiornare).
== Organizzazione dei dossier in due o tre livelli ==

Al momento dell'esecuzione del software, il motore adonix carica ed esegue dei file che contengono un codice intermedio (il p-code) indipendente dall'ambiente. Questi file possono essere dei programmi, delle descrizioni di videate, la descrizione delle tabelle (per fare una consultazione sulla tabella in questione). Questi file vengono cercati nel dossier in corso di esecuzione. Ma se un file non esisten nel dossier, il motore adonix lo cercherà nel dossier padre di primo livello, poi nel dossier di secondo livello... Il motore adonix può così risalire una gerarchia di 8 dossier successivi, ma per ragioni pratiche, ci si limita a 3 livelli (la gestione di dossier ne gestisce solo 3).

La conseguenza di questa struttura è la seguente: un dossier utente creato nel software dipenderà sia dal dossier supervisore, sia da un dossier che dipende esso stesso dal dossier supervisore. Infatti, se ciò non avvenisse, non sarebbero più accessibili gli elementi indispensabili al funzionamento del dossier e della sua parametrizzazione, che sono presenti solo nel dossier supervisore. I due schemi possibili per un dossier di produzione sono i seguenti:

Il dossier di riferimento intermedio è in generale chiamato dossier di sviluppo, perché una delle possibili implementazioni delle gerarchie di dossier consiste nell'installarvi gli sviluppi specifici.

La gerarchia a 3 livelli è pesante da mantenere. Infatti, l'esistenza di questa gerarchia a tre livelli ha delle conseguenze pratiche: trasferire un dossier di produzione da un server ad un altro presuppone che, affinché il dossier trasferito possa funzionare, la gerarchia sia stata anch'essa trasferita. Nel caso di una gerarchia a due livelli, nessun problema, poiché il dossier supervisore è forzatamente presente in un ambiente in cui è installato il software. In compenso, nel caso di una gerarchia a 3 livelli, occorre anche trasferire il dossier di sviluppo.

Il principio di eredità, se permette di trasferire semplicemente degli sviluppi fatti tramite rivalidazione del dossier di produzione, presenta comunque degli effetti particolari, nella misura in cui l'eredità è immediata se si modifica un programma nel dossier di sviluppo... ma differita per tutti gli elementi del dizionario, che saranno trasferiti solo in caso di rivalidazione. Quindi si rischia di ritrovarsi con delle incoerenze temporanee nel dossier di produzione, dato che si lavora in un dossier di sviluppo.

Questa gerarchia è quindi consigliata solo nei seguenti casi:

* il cliente finale vuole sviluppare i propri specifici e si desidera che lo faccia in modo ben isolato nel dossier di produzione; sapendo che si vogliono degli sviluppi fatti da un partner ADONIX nel dossier intermedio.

* ci si trova in un ambiente di sviluppo di verticali e si desiderano utilizzare dei dossier di produzione a dei fini di test.

In tutti gli altri casi, si consiglia di utilizzare una gerarchia a due livelli. In questo caso, occorre utilizzare un dossier di test a fianco del dossier di produzione, se si desiderano realizzare degli sviluppi in corso di gestione e testarli prima di installarli (tramite copia o patch) nel dossier di produzione. L'utilizzo della funzione di patch è spesso preferibile: infatti permette di creare dei « packages » applicativi dal dossier di sviluppo e di integrarli in blocco nel dossier di produzione. Inoltre, la versione 130 integra una nuova funzione di creazione di una patch incrementale. Infatti è possibile creare una patch che contiene tutto ciò che è stato modificato su un dossier da una determinata data. Questo permette molto facilmente di isolare gli sviluppi e le parametrizzazioni realizzate tra due fasi di un'implementazione.