Do It The jAPS Way
Copyright © 2011 Tzente s.r.l.
Legal Notice
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the Appendix entitled "GNU Free Documentation License".
2011-03-03
| Revision History | ||
|---|---|---|
| Revision 1.6 | 2011-03-03 | MEM |
|
Revisione per il rilascio di jAPS 2.2.0 | ||
| Revision 1.5 | 2010-03-18 | MEM |
|
Revisione per il rilascio di jAPS 2.0.10 | ||
| Revision 1.4 | 2009-11-24 | MEM |
|
Cambiamenti minori per l'adattamento in Inglese | ||
| Revision 1.3 | 2009-03-09 | WG |
|
English and docbook adoption Il processo di revisione sarà ultimato non appena il documento Pattern Integrazione Servizi sarà tradotto. | ||
| Revision 1.2 | 2009-02-09 | ES |
Primo rilascio pubblico | ||
Table of Contents
List of Examples
- 4.1. Package Manager Card
- 4.2. Nome Manager Card
- 4.3. Classe Manager Card
- 4.4. Implementazione metodo init
- 4.5. Costante Nome Manager
- 4.6. Firme metodi
- 4.7. Classe DAO
- 4.8. Definizione Completa del Manager
- 4.9. Ridefinizione del manager Gestore degli utenti
- 4.10. Package Classe Action della gestione Card
- 4.11. Package Classe Action della gestione Card
- 4.12. Definizione del bean delle classe Action
- 4.13. Definizione delle azioni - file card.xml
- 4.14. Definizione delle azioni - file portalExample.xml
- 4.15. jsp servizio gestore card
- 4.16. Definizione Menù
- 4.17. Ridefinizione della interfaccia di gestione Albero Pagine
Table of Contents
Lo scopo di questo documento è fornire una descrizione del modello architetturale di jAPS 2.0 entando e le linee guida per i passi da seguire per lo sviluppo di un nuovo servizio applicativo.
Questo documento è destinato agli sviluppatori che intendono creare un nuovo Servizio Applicativo su jAPS 2.0 entando.
Per poter utilizzare efficacemente le informazioni contenute in questo documento, è necessario avere competenze di base su: piattaforma Java, strumenti di sviluppo Eclipse, servlet engine Apache Tomcat, database PostgreSQL.
Ulteriori informazioni possono essere richieste attraverso la mailing list ufficiale Google Group "japs-platform".
Per mandare un messaggio ai membri della lista, invia una mail a <japs-platform@googlegroups.com>.
È inoltre possibile consultare la documentazione presente in:
Un jAPS Manager rappresenta un componente applicativo del jAPS Core che implementa una funzionalità base della piattaforma. Il jAPS Manager rappresenta il gestore principale di una singola funzionalità.
I principali Managers della piattaforma sono suddivisi in servizi di base e servizi del jACMS.
Servizi base:
AuthenticationProviderManager: servizio gestore delle autenticazioni.
BaseConfigManager: servizio di configurazione. Carica da db e rende disponibile la configurazione.
CacheManager: servizio gestore cache.
CategoryManager: manager delle categorie.
ControllerManager: servizio di controllo dell'esecuzione relativa ad una richiesta del client.
GroupManager: servizio gestore dei gruppi.
I18nManager: servizio che fornisce stringhe “localizzate”.
KeyGeneratorManager: servizio gestore di sequenze univoche.
LangManager: servizio di gestione delle lingue.
NotifyManager: servizio notificatore eventi.
PageManager: servizio di gestione delle pagine.
PageModelManager: servizio di gestione dei modelli di pagina.
RoleManager: servizio di gestione dei ruoli.
ShowletTypeManager: servizio di gestione dei tipi di showlet (ShowletType) definiti nel sistema.
UrlManager: servizio di gestione degli url; crea un URL completo ad una pagina del Portale a partire da informazioni essenziali.
UserManager: manager gestore degli utenti.
Servizi CMS:
ContentManager: manager gestore dei contenuti.
ContentPageMapperManager: servizio gestore della mappa dei contenuti pubblicati nelle pagine.
LinkResolverManager: servizio gestore della risoluzione dei link simbolici.
ResourceManager: Servizio gestore tipi di risorse (immagini, audio, video, etc..).
SearcheEngineManager: servizio detentore delle operazioni di indicizzazione di oggetti ricercabili tramite motore di ricerca.
I servizi definiti nel sistema vengono istanziati ed inizializzati all'avvio del sistema (attraverso la Factory di Spring Framework).
Esiste sempre e solo una singola istanza di ciascun servizio. L'accesso ad un servizio può essere ottenuto sia attraverso la tecnica di "Dependency Injection" favorita da Spring, oppure attraverso elementi a servizio del sistema (Classe ApsWebApplicationUtils).
Ogni singolo jAPSManager viene descritto attarverso una specifica interfaccia, ed ogni oggetto di sistema utilizza il Manager sempre e solo attraverso la sua Interfaccia, mai attraverso la sua implementazione concreta
Il Manager (o jAPS Manager) è l'unico punto di raccordo tra qualunque base dati presente nel sistema ed una qualsiasi funzionalità gestita. Esempio di servizio è il PageManager, delegato alle operazioni di gestione dell'albero delle pagine nel Portale; qualunque operazione di aggiunta, rimozione, modifica, caricamento, fornitura di una pagina è gestita dal PageManager.
Table of Contents
Il Modello Architetturale di jAPS 2.0 entando
Per poter comprendere a fondo il pattern Service Creation and Integration è necessario capire il modello architetturale su cui si basa. jAPS si compone principalmente di 3 layer:
Data Access Layer: Si compone di tutti gli elementi delegati al controllo dello Strato di Persistenza. L'elemento principale è rappresentato dalle classi DAO (Data Access Object) che è l'unico elemento di raccordo tra il Framework e gli elementi esterni come Database, FileSystem, Servizi di Directory LDAP, etc....
Business Layer: Rappresenta il Core del Sistema. In esso troviamo il concetto di Servizi jAPS che rappresentano il gestore di ogni singola macro-funzionalità del sistema. Il Layer è costruito attraverso Spring Framework il cui Listener, in fase di inizializzazione del sistema inizializza ed inserisce i Servizi jAPS nel contesto dell'Applicazione sotto forma di
bean. Il Business Layer utilizza lo strato di Data Access per recuperare i dati gestiti, fornisce allo strato superiore (il Presentation Layer) gli elementi da erogare e lo supporta alla esecuzione delle azioni su di esso imposte.Presentation Layer: E' il layer delegato alla costruzione delle interfacce grafiche che rappresentano il mezzo mediante il quale gli utenti interagiscono con il sistema. Il Layer fornisce sia uno strato di View pura (jsp, rigorosamente senza logica di Business) che una logica di Controller “snella” (il cui compito è quello di controllare la correttezza dei dati in input e gestire i dati in fase di erogazione) a supporto dello strato inferiore di Business Layer. In jAPS, questo layer si divide in due parti distinte: la View di Portale e la View dell'Area di Amministrazione. Le due aree, che si diversificano nelle funzioni e nelle architetture componenti, sono separate ed indipendenti l'una rispetto all'altra.
Qualsiasi servizio applicativo deve essere sviluppato aderendo al precedente schema architetturale, facendo aderire ogni suo elemento nel corretto Layer. La presenza di elementi del nuovo Servizio Applicativo in ciascun Layer di jAPS dipende dal Funzionalità stessa. Un Servizio Applicativo che abbia il compito di gestire le funzioni di aggiunta, rimozione, modifica e ricerca di “Personal Card” (come nell'esempio di seguito riportato in questo Manuale e nel Portale “PortalExample”) necessita di elementi in tutti e tre i Layer (in particolare presenta dei moduli di erogazione nel Layer View sia nell'area di Portale che nell'Area di Amministrazione).
E' la parte del Presentation Layer delegato alla erogazione di Servizi di Portale attraverso il motore di Portale di jAPS, in particolare attraverso le Showlet che rappresentano gli elementi tramite il quale erogare i servizi applicativi. I compiti dello strato della View di Portale è sia quello di erogare servizi di Portale in relazione all'utente corrente (a tal fine ogni elemento costituente il Portal Layer ha insito in sè le regole di accesso ed i controlli di autorizzazione) che di erogarli nel più breve tempo possibile (attraverso un motore di Caching dei Contenuti). La View di Portale viene gestita da una Servlet apposita (ControllerServlet) il cui compito primario è quello di invocare in successione una serie di Servizi di Controllo (controllo di validità della url/pagina richiesta, controllo di autorizzazione dell'utente corrente, etc) per poi invocare la costruzione ed erogazione della pagina.
E' l'area riservata alle operazioni di Amministrazione degli elementi di Portale (Pagine, Contenuti, Risorse, etc..) il cui accesso è riservato a particolari utenti autorizzati. La View dell'Area di Amministrazione (comprensiva del suo strato di Controller) è stata oggetto, nella versione jAPS2, di una completa reingegnerizzazione sia con il cambiamento del Framework Controller di riferimento (Struts2, strettamente correlato con Spring Framework) e sia con la totale ricostruzione della View in maniera da consentire il rispetto delle normative vigenti in termini di Accessibilità.
Le sorgenti java di jAPS sono divise sostanzialmente (escludendo i package relativi ai test ed a elementi di servizio) in due package:
com.agiletec.aps: in questo package sono presenti tutti gli elementi del Data Access Layer, Business Layer e Presentation Layer (con la sola parte di View di Portale).com.agiletec.apsadmin: questo package contiene invece tutti gli elementi per la gestione del Presentation Layer specifico per la gestione dell'Area di Amministrazione.
Una analoga suddivisione è presente all'interno della cartella di sistema WEB-INF della Web Application: in essa sono presenti (oltre ad altre cartelle di servizio) le cartelle aps (contenente tutte le jsp e tld riconducibili al Layer View di Portale) e apsadmin (contenente tutte le jsp e tld riconducibili al Layer View dell'Area di Amministrazione).
Il pattern Service Creation and Integration descrive come creare ed integrare un servizio applicativo nel sistema jAPS 2.0 entando.
Il target principale di questo di questo documento è consentire ai jAPS-Developers uno sviluppo veloce di nuove funzionalità da affiancare a quelle di jAPS 2.0 entando senza modificare le sorgenti (classi java, jsp, configurazioni, etc) del Core Base.
Nella esposizione dei passi per poter descrivere l'implementazione di un nuovo Servizio Applicativo si parte dal Business Layer e dal Data Layer.
Elementi Partecipanti: Le classi in gioco sono: <NOME_OGGETTO_GESTITO>Manager (il nome del Servizio) che deve estendere la classe AbstractService; nel caso si utilizzino i DAO anche <NOME_OGGETTO_GESTITO>DAO che deve estendere la classe AbstractDAO.
Creare il package esterno al progetto rispettando lo schema che utilizza il core.
Example 4.1. Package Manager Card
Se devo creare un servizio che gestisce oggetti Card il nome del package sarà it.projectname.aps.system.services.card.
Creare un'interfaccia Firma del Servizio che rispecchi la sintassi I<NOME_OGGETTO_GESTITO>Manager.
Questa interfaccia comprende tutti i metodi pubblici (e le eventuali costanti) che il servizio deve esporre.
L'utilizzo del servizio concreto (in qualunque punto dell'applicazione) dovrà avvenire attraverso la sua interfaccia.
Creare la classe del servizio di nome <NOME_OGGETTO_GESTITO>Manager che estende la classe AbstractService e che implementi l'interfaccia appena creata.
Example 4.3. Classe Manager Card
public class CardManager extends AbstractService implements ICardManager {
....
}
Implementare adeguatamente il metodo init di AbstractService (che consente l'inizializzazione del servizio) e tutti i metodo definiti nell'interfaccia.
Example 4.4. Implementazione metodo init
/**
* Inizializzazione del servizio.
*/
public void init() throws Exception {
.....
}
Aggiungere, nella classe (o interfaccia) <NOME_PROGETTO>SystemConstants contenuta nel sotto-package aps.system del progetto,
una stringa costante <NOME_OGGETTO_GESTITO>_MANAGER che individua univocamente il nome del servizio all'interno del progetto.
Example 4.5. Costante Nome Manager
public interface MioProgettoSystemConstants {
public static final String CARD_MANAGER = "CardManager";
.......
}
Aggiungere il servizio in un nuovo file di configurazione di Spring; il file di configurazione devono essere inseriti
in una cartella posta in /WEB-INF/<NOME_PROGETTO>/conf/ seguendo lo schema impostato nel Core.
Il nuovo Manager deve essere inserito nel Contesto di Spring secondo la seguente sintassi:
<bean id="CardManager" class="it.projectname.aps.system.services.card.CardManager" parent="abstractService" > </bean>
dove l'id equivale al valore della costante impostata al punto precedente.
Important
Particolare attenzione deve essere posta nella definizione dell'id del Bean in quanto esso non deve corrispondere a nessun bean del Core di jAPS, a meno che non si voglia estendere una funzionalità esistente.
Inserire il pattern per registrazione dei file di configurazione del progetto nell'attributo xml param-value del parametro contextConfigLocation nel file /WEB-INF/web.xml.
WEB-INF/<NOME_PROGETTO>/conf/**/**.xml (la definizione deve essere aggiunta in ultima posizione).
Inserire il pattern per registrazione dei file di configurazione del progetto nella classe test.com.agiletec.aps.ConfigUtils
(metodo getSpringConfigFilePaths) a servizio delle classi di test (la definizione deve essere aggiunta in ultima posizione).
Se eventualmente viene utilizzato un DAO (Data Access Object), per cui il nuovo Servizio Applicativo presenta elementi nel Data Layer, la prima cosa da fare è creare un'interfaccia Firma del DAO con la sintassi I<NOME_OGGETTO_GESTITO>DAO e aggiungere, nella classe concreta del servizio, una variabile d'istanza (del tipo dell'interfaccia appena creata) con i metodi getter e setter (setter obbligatoriamente pubblico).
Example 4.6. Firme metodi
public void setCardDao(ICardDAO cardDao); protected ICardDAO getCardDao();
Creare la classe DAO <NOME_OGGETTO_GESTITO>DAO implementante l'interfaccia appena creata.
Nel caso che si voglia utilizzare JDBC standard, la classe DAO creata deve estendere la classe AbstractDAO.
Iniettare il DAO nel bean del servizio definito precedentemente, l'oggetto DAO appena creato
Example 4.8. Definizione Completa del Manager
<bean id="CardManager" class="it.projectname.aps.system.services.card.CardManager" parent="abstractService" > <property name="cardDao"> <bean class="it.projectname.aps.system.services.card.CardDAO" > <property name="dataSource" ref="dataSourceBeanName" /> </bean> </property> </bean>
NOTA: iniettare adeguatamente il datasource tramite la referenza alla definizione di un datasource tra quelli disponibili di default nel sistema (“portDataSource” o “servDataSource”) o in quelli definiti appositamente nel progetto specifico.
Ogni servizio ed ogni DAO deve essere testato nei suoi metodi pubblici. A tal scopo è necessario:
Creare una classe java <NOME_PROGETTO>ConfigUtils (nel package
test.it.projectname) che estende la classe ConfigUtils ed estendere adeguatamente i metodi getSpringConfigFilePaths (per la definizione dei path per la estrazione dei nuovi file di configurazione delle classi ) e closeDataSources (per gestire la chiusura di nuovi DataSource).Creare una classe java <NOME_PROGETTO>BaseTestCase (nel package
test.it.projectname.aps) che estende la classetest.com.agiletec.aps.BaseTestCasee fare l'Override nel metodo getConfigUtils in maniera tale che restituisca un'istanza della classe creata nel punto precedente.Creare le classi di test le classi Test<NOME_OGGETTO_GESTITO>Manager ed eventualmente Test<NOME_OGGETTO_GESTITO>DAO all'interno del il package
test.it.projectname.aps.system.services.<NOME_OGGETTO_GESTITO>ed estendenti la classe creata nel punto precedente. Testare i metodi pubblici definiti nella classe da testare.
Dovendo testare un servizio andremo, in ogni singola classe di test, a recuperare il medesimo come mostrato nell'esempio:
ImioServizioManager mioServizioManager = (ImioServizioManager) this.getService(MioProgettoSystemConstants.MIO_SERVIZIO_MANAGER);
Per testare un DAO è necessario invece crearlo ad hoc esattamente come viene creato da Spring, passandogli quindi il DataSource e ogni eventuale bean richiesto.
DataSource dataSource = (DataSource)
this.getApplicationContext().getBean("nomeDataSource");
MioServizioDAO mioServizioDao = new MioServizioDAO();
mioServizioDao.setDataSource(dataSource);
Esistono appositi DataBase per i test, ad esempio jAPStestPort e jAPStestServ (equivalenti dei DB jAPSPort e jAPSServ). Qualora fossero necessari ulteriori Database dovranno esserne create 2 versioni, una normale e una apposita per i test.
Per ogni metodo da testare andrà creato l'equivalente metodo di test:
public void testNomeMetodoDaTestare() {
........
}
A volte potrebbe essere utile creare più test per un solo metodo oppure un solo metodo che esegua il test di più metodi (ad esempio per le operazioni di aggiunta, modifica e rimozione). Ogni singola unità di test (il singolo metodo testMetodoDaTestare) deve, al termine delle operazioni, riportare il DataBase alla condizione iniziale.
Nel caso che il Servizio Applicativo debba andare a modificare dei Manager già esistenti (integrando o modificando funzionalità)
non modificare le classi del core ma creare, all'interno dello specifico package del progetto it.projectname.aps.system.services creare un nuovo Manager estendendo quello che si intende modificare e ridefinire (nel file di configurazione dei Bean proprio del progetto) il corrispondente Bean del Contesto di Spring con lo stesso nome (id) con la quale viene definito nel Core di jAPS.
Example 4.9. Ridefinizione del manager Gestore degli utenti
<bean id="UserManager" class="it.projectname.aps.system.services.user.UserManager" parent="abstractService" > <property name="userDAO" > <bean class="it.projectname.aps.system.services.user.UserDAO"> <property name="dataSource" ref="servDataSource" /> </bean> </property> <property name="configManager" ref="BaseConfigManager"/> </bean>
Nell'esempio precedente, il nuovo bean di id UserManager và a sostituire (essendo omonimo) quello del Core di jAPS.
Nella definizione del bean, si devono inserire le stesse property che vengono utilizzate per la definizione del bean del core.
Per alcuni Servizi Applicativi sarà necessario realizzare interfacce di amministrazione. All'interno del core di jAPS, le classi preposte alla gestione delle interfacce sono tutte racchiuse all'interno del package com.agiletec.aspadmin. All'interno del package troviamo una serie di package che rappresentano ciascuno le macro funzionalità esposte nell'area di Amministrazione dal Core. Il nuovo servizio Applicativo dovrà presentare le sorgenti per la gestione delle sue interfaccie di BackEnd, sviluppate secondo lo schema del Core.
Creare il package esterno al Core rispettando lo schema utilizzato nel Core di jAPS 2.0 entando.
Example 4.10. Package Classe Action della gestione Card
Se si devono creare un insieme di Azioni per la gestione degli oggetti schede (oggetto Card) il nome
del package sarà it.projectname.apsadmin.card.
Creare le interfacce java Firma delle Action che rispecchi la sintassi I<NOME_OGGETTO_GESTITO>Action.
Questa interfaccia presenta tutti i metodi pubblici (e le eventuali costanti) che la classe action concreta deve implementare. Ogni metodo presentato dall'interfacca java rappresenta un'azione che può essere eseguita.
Nel caso in cui sia necessario gestire anche una funzione di ricerca degli elementi gestiti dal Servizio principale, deve essere definita anche una interfaccia java I<NOME_OGGETTO_GESTITO>FinderAction per la gestione delle operazioni di ricerca.
Creare le classi Action di nome <NOME_OGGETTO_GESTITO>Action che estende la classe BaseAction e che implementi l'interfaccia appena creata. Creare eventualmente anche la classe action delegata alle operazioni di ricerca.
Aggiungere le azioni appena definite in un nuovo file di configurazione di Spring secondo la sintassi dell'esempio seguente.
Example 4.12. Definizione del bean delle classe Action
<bean id="cardAction" scope=”prototype” class="it.projectname.apsadmin.card.CardAction" parent="abstractBaseAction" > </bean>
Important
Lo scope dei bean relativi alle Classi Action DEVE essere prototype e particolare attenzione deve essere posta nella definizione
dell'id del Bean in quanto esso non deve corrispondere a nessun bean del Core di jAPS 2.0 entando, a meno che non si voglia estendere una funzionalità esistente.
Inserire il file di configurazione in una cartella posta in /WEB-INF/<NOME_PROGETTO>/apsadmin/conf/.
Inserire il pattern per registrazione dei file di configurazione del progetto nell'attributo xml param-value del parametro contextConfigLocation nel file /WEB-INF/web.xml.
WEB-INF/<NOME_PROGETTO>/apasadmin/conf/**/**.xml (la definizione deve essere aggiunta in ultima posizione).
Creare nello stesso livello delle interfacce java (e relative implementazioni concrete) un file xml dove vengono definite le Azioni specifiche (secondo le regole di Struts2 in namespace apposito) che si possono eseguire attraverso le nuove Interfacce Utente.
Example 4.13. Definizione delle azioni - file card.xml
<struts> <package name="portalExample_do/Card" namespace="/do/Card" extends="japs-default"> <action name="list" class="cardFindingAction"> <result type="tiles">admin.Card.list</result> <interceptor-ref name="japsDefaultStack"> <param name="requestAuth.requiredPermission">superuser</param> </interceptor-ref> </action> ...... <action name="edit" class="cardAction" method="edit"> <result type="tiles">admin.Card.entry</result> <interceptor-ref name="japsDefaultStack"> <param name="requestAuth.requiredPermission">superuser</param> </interceptor-ref> </action> .... </package> </struts>
Nota: Il nome del package Struts2 deve presentare come prefisso il nome del progetto.
Utilizzare gli Stack di interceptors definiti all'interno del file struts.xml:
japsDefaultStack: Stack di default per Azioni interne all'Area di Amministrazione, che necessitano di permesso specifico per l'esecuzione (con controllo del permesso di accesso all'area protetta), e senza controllo di Validazione di eventuali parametri inseriti (attraverso campi di un Form o parametri nella url). Lo stack necessita della specifica del permesso richiestorequiredPermissionper l'esecuzione dell'Azione.japsValidationStack: Estensione del japsDefaultStack con l'aggiunta del controllo di Validazione.japsFreeStack: Stack per Azioni interne (o esterne) all'Area di Amministrazione che non necessitano di permesso specifico per l'esecuzione (senza controllo del permesso di accesso all'area protetta) e senza controllo di Validazione.japsFreeValidationStack: Estensione del japsFreeStack con l'aggiunta del controllo di Validazione.
Creare, nello stesso livello delle interfacce java (e relative implementazioni concrete), appropriati file xml per la gestione delle Validazioni (secondo le regole di Struts2).
Creare un nuovo file <NOME_PROGETTO>-struts.xml nella root delle sorgenti (allo stesso livello del file struts.xml) che conterrà i riferimenti a tutti i file di configurazione delle nuove azioni definite specifiche per il progetto.
Example 4.14. Definizione delle azioni - file portalExample.xml
<struts> <include file="it/myprojectname/apsadmin/card/card.xml"/> </struts>
Registrare il file di definizione delle azioni del progetto nel parametro Struts2Config nel file /WEB-INF/web.xml (la definizione deve essere aggiunta in ultima posizione).
Nello stesso package dove vengono locate le Action proprie della Funzionalità, devono essere posizionati i file properties relativi alle Stringhe per il supporto all'Internazionalizzazione (i18n). La predisposizione di questi files dele seguire le indicazioni fornite dalle Documentazioni rese a disposizione nel WebSite del Framework Struts2.
In questi file devono essere inserite, oltre che tutte le label statiche delle jsp delle Interfaccie Utente, tutte le label correlate con il supporto alla Validazione.
Le labels devono essere fornite nella lingua Inglese e Italiano (per cui devono essere inseriti i files package_it.properties e package_en.properties).
Le chiavi delle labels devono essere strutturate in maniera da non sovrascrivere le impostazioni delle risorse comuni (files global-messages_en.properties e global-messages_it.properties).
A tal proposito si consiglia di suddividere le label nel gruppi:
per menù
per Titoli (h1 e h2)
Stringhe Statiche delle jsp
per Messaggi a supporto della Validazione
Creare l'Ambiente di Test e le classi di Test delle Azioni appena create. Nello specifico:
Creare una classe java <NOME_PROGETTO>ConfigUtils (o utilizzare quella creata per i test dei Manager) che estende la classe ConfigUtils ed estendere adeguatamente i metodi getSpringConfigFilePaths (per la definizione dei path per la estrazione dei nuovi file di configurazione delle classi ) e closeDataSources (per gestire la chiusura di nuovi DataSource).
Creare una classe java <NOME_PROGETTO>ApsAdminTestCase (nel package test.it.projectname.apsadmin) che estende la classe test.com.agiletec.apsadmin.ApsAdminTestCase e fare l'Override nel metodo getConfigUtils (in maniera tale che restituisca un'istanza della classe creata nel punto precedente) e del metodo setInitParameters (per estendere il caricamento delle Azioni definite anche a quelle definite allo stesso livello del file struts.xml).
Creare le classi Action di nome Test<NOME_OGGETTO_GESTITO>Action che estende la classe definita nel punto precedente. Creare eventualmente anche la classe di test della Action delegata alle operazioni di ricerca. Testare adeguatamente tutte le azioni.
Creare i file jsp a servizio delle interfacce Utente vanno posizionate dentro una apposita
cartella all'interno del directory /WEB-INF/<NOME_PROGETTO>/apsadmin/jsp/.
Example 4.15. jsp servizio gestore card
cardFinder.jspper la interfaccia di ricerca Card (gestita dalla classe Action concreta CardFinderAction).entryCard.jspper la interfaccia di aggiunta/modifica Card (gestita dalla classe Action concreta CardAction).
Le interfacce devono essere presentate internamente al template definito main.layout nel file
/WEB-INF/apsadmin/tiles.xml che definisce la configurazione delle pagine di destinazione delle Azioni.
La definizione delle Pagine di destinazione deve seguire le regole di Tiles2 come plugin di Struts2.
Definire un nuovo file di configurazione Pagine <NOME_PROGETTO>-tiles.xml all'interno della cartella /WEB-INF/<NOME_PROGETTO>/apsadmin.
Le pagine devono estendere main.layout e singoli codici rappresenteranno il risultato (di tipo tiles) di ogni azione definita.
Il file di configurazione va registrato all'interno del parametro org.apache.tiles.impl.BasicTilesContainer.DEFINITIONS_CONFIG del descriptor (web.xml) dell'applicazione (in ultima posizione).
Per creare una voce di menù aggiuntiva all'interno del menu Plugin, è necessario creare nella cartella
/WEB-INF/<NOME_PROGETTO>/apsadmin/jsp/common/template/ un file di nome subMenu.jsp che contenga l'eventuale voce
di menù aggiuntiva del nuovo Servizio Applicativo.
Successivamente deve essere definito un nuovo Bean (Spring Object) di id <NOME_SERVIZIO>SubMenu della Classe PluginSubMenuContainer
che presenti la property submenuFilePath valorizzata con la posizione relativa del file subMenu.jsp appena creata.
Example 4.16. Definizione Menù
<bean id="cardPluginSubMenu" class="com.agiletec.apsadmin.system.plugin.PluginSubMenuContainer" > <property name="subMenuFilePath"> <value>/WEB-INF/demo/apsadmin/jsp/common/template/subMenu.jsp</value> </property> </bean>
In questo modo, la singola voce di menu verrà inclusa all'interno della voce Plugin dell'Area di Amministrazione.
Nel caso che il Servizio Applicativo debba andare a modificare delle interfaccie già esistenti (per esempio integrando Moduli, link, o altro)
non modificare le interfacce del Core ma creare, all'interno della specifica nuova definizione dei tiles <NOME_PROGETTO>-tiles.xml
una nuova definition con lo stesso nome della interfaccia del core che si intende ridefinire nella quale viene riscritto l'elemento che si intende modificare.
Example 4.17. Ridefinizione della interfaccia di gestione Albero Pagine
Nel <NOME_PROGETTO>-tiles.xml viene inserita la definition:
<definition extends="main.layout" name="admin.Page.viewTree"> <put-attribute name="title" value="title.pageManagement" /> <put-attribute name="extraResources" value="/WEB-INF/apsadmin/jsp/common/template/extraresources/pageTree.jsp" /> <put-attribute name="body" value="/WEB-INF/<NOME_PROGETTO>/apsadmin/jsp/page/pageTree.jsp" /> </definition>
dove admin.Page.viewTree è l'identificativo della interfaccia gestore dell'Albero delle Pagine.
La posizione delle jsp deve rispettare fedelmente la posizione (a meno del directory proprio del progetto) delle jsp delle interfaccie che si devono sostituire.
Nei limiti del possibile, è sconsigliato utilizzare questa tecnica; nel caso di inserimento nuove funzionalità che integrano alcune preesistenti,
è consigliato utilizzare la tecnica dei SubMenu dei Plugin per creare gli EntryPoint della funzionalità.
