CreateActions_it

Parte III: Creare Action e JSP - Un HowTo per la creazione di Action di Struts e JSP nell'architettura di AppFuse.

Questo tutorial dipende da Parte II: Creare nuovi Manager.

Informazioni su questo Tutorial

Per default, AppFuse esce con Struts come framework web. Dalla 1.6+, puoi usare Spring o WebWork come tuo framework web. Nella 1.7, è stato aggiunto il supporto per usare JSF o Tapestry.

Per installare uno di questi framework web invece di Struts, è sufficiente che tu vada nella directory extras e da qui nella directory del framework che vuoi installare. Il file README.txt in questa directory contiene ulteriori informazioni. I tutorial per questi altri framework sono elencati sotto.

• Spring: Creazione Controller Spring e JSP
• WebWork: Creating WebWork Actions and JSPs
• JSF: Creating JSF Beans and JSPs
• Tapestry: Creating Tapestry Pages and Templates

Iniziamo a creare una nuova Struts Action ed una JSP per il tuo progetto AppFuse.

Ti dirò come faccio le cose nel Mondo Reale in un testo come questo.

Indice

• [1] Aggiungi Tag XDoclet a Person per generare PersonForm
• [2] Crea lo scheletro delle JSP usando XDoclet
• [3] Crea PersonActionTest per effettuare test su PersonAction
• [4] Crea PersonAction
• [5] Esegui PersonActionTest
• [6] Ripulisci la JSP per renderla presentabile
• [7] Crea dei WebTests Canoo per effettuare test di interazioni browser-like

Aggiungi Tag XDoclet a Person per generare PersonForm [#1]

Estendiamo org.appfuse.webapp.form.BaseForm perché ha un metodo toString() che ci permette di chiamare log.debug(formName) per stampare una visualizzazione più leggibile dell'oggetto Form.

Se non hai rinominato i package "org.appfuse" in "com.company" o in alternativa non hai la tua classe di modello nel package di default, può rivelarsi necessario specificare completamente il riferimento a org.appfuse.webapp.form.BaseForm nel tag @struts.form.

Ora se esegui ant gen-forms, Ant (ed XDoclet) genererà un PersonForm.java per te in build/web/gen/**/form.

Crea lo scheletro delle JSP usando XDoclet [#2]

Ecco i semplici passi per generare una JSP ed un file properties contenente le etichette per gli elementi del form:

• Dalla linea di comando, naviga in "extras/appgen"
• Esegui ant -Dobject.name=Person -Dappgen.type=pojo per generare una serie di file in extras/appgen/build/gen. Infatti, genererà tutti i file di cui hai bisogno per completare questo tutorial. Tuttavia, prendiamo solo quelli di cui abbiamo bisogno.
  • web/WEB-INF/classes/Person.properties (etichette per gli elementi del tuo form)
  • web/pages/personForm.jsp (file JSP per visualizzare una singola Persona)
  • web/pages/personList.jsp (file JSP per visualizzare un elenco di Persone)
• Copia il contenuto di Person.properties in web/WEB-INF/classes/ApplicationResources.properties. Queste sono tutte le chiavi di cui avrai bisogno per titoli/intestazioni e proprietà del form. Ecco un esempio di quello che dovrai aggiungere ad ApplicationResources.properties:

# -- person form --
personForm.id=Id
personForm.firstName=First Name
personForm.lastName=Last Name

person.added=Person has been added successfully.
person.updated=Person has been updated successfully.
person.deleted=Person has been deleted successfully.

# -- person list page --
personList.title=Person List
personList.heading=Persons

# -- person detail page --
personDetail.title=Person Detail
personDetail.heading=Person Information

• Copia personForm.jsp in web/pages/personForm.jsp. Copia personList.jsp in web/pages/personList.jsp.

I file nella directory "pages" finiranno in "WEB-INF/pages" al momento del deployment. Il container mette in sicurezza tutti i file sotto WEB-INF. Ciò si applica alle richieste del client, ma non ai forward dalla ActionServlet di Struts. Mettere tutte le JSP sotto WEB-INF assicura che queste siano accedute solo tramite Action, e non direttamente dal client o fra loro. Ciò consente di spostare la sicurezza nella Action, dove può essere gestita in modo più efficiente, e fuori dallo strato di presentazione di base.

La sicurezza a livello di web application per AppFuse specifica che tutti le url del tipo *.html siano protette (ad eccezione di /signup.html e /passwordHint.html). Ciò garantisce che i client passino attraverso una Action per arrivare ad una JSP (o almeno a quelle in pages).

body#pageName element.class { background-color: blue } 

• Aggiungi le chiavi ApplicationResources.properties relative a titoli ed intestazioni nelle JSP

Appena sopra, abbiamo aggiunto delle chiavi del tipo "personForm.*" a questo file, per cui per quale motivo ora uso personDetail invece di personForm per i titoli e le intestazioni? Il motivo migliore è che dà una buona separazione fra le etichette del form ed il testo nella pagina. Un altro motivo è perché tutti i *Form.* ti danno una buona rappresentazione give di tutti i campi nel tuo database.

Recentemente ho avuto un cliente che voleva tutti i campi nel database ricercabili. Ciò è stato piuttosto semplice da fare. Ho semplicemente cercato tutte le chiavi in ApplicationResources.properties che contenessero "Form." e le ho messe un un menu a discesa. Sulla UI, l'utente poteva inserire un termine da cercare e selezionare la colonna in cui volesse effettuare la ricerca. Sono stato contento di aver seguito questa distinzione Form vs. Detail in quel progetto!

Crea PersonActionTest per effettuare test su PersonAction [#3]

Devi aggiungere PERSON_KEY come variabile alla classe src/dao/**/Constants.java. Il nome, "personForm", corrisponde al nome dato al form nel file struts-config.xml.

Se provi ad eseguire questo test, otterrai una serie di NoSuchMethodErrors - pertanto definiamo i metodi edit, save, e delete della classe PersonAction.

Crea PersonAction [#4]

In src/web/**/action, crea un file PersonAction.java con il seguente contenuto:

Noterai che nel codice sopra ci sono molte chiamate per convertire un oggetto PersonForm o Person. Il metodo convert è BaseAction.java (la quale richiama ConvertUtil.convert()) ed usa BeanUtils.copyProperties per convertire i POJO → ActionForm ed ActionForm → POJO.

Se stai eseguendo dentro Eclipse, potresti aver bisogno di fare un "refresh" sul progetto in modo da vedere PersonForm. Si trova in build/web/gen, che dovrebbe essere una delle cartelle sorgenti del tuo progetto. Questo è l'unico modo per Eclipse do vedere ed importare PersonForm, in quanto viene generato da XDoclet e non fa parte del tuo albero sorgenti regolare. Puoi trovarlo in build/web/gen/org/appfuse/webapp/form/PersonForm.java.

In BaseAction puoi registrare ulteriori Converter (i.e. DateConverter) in modo che BeanUtils.copyProperties sappia come convertire String → Object. Se hai delle List nei tuoi POJO (i.e. per relazioni genitore-figlio), dovrai convertirle manualmente usando il metodo convertLists(java.lang.Object) .

Ora devi aggiungere il forward edit e l'action-mapping savePerson, entrambi specificati in PersonActionTest. Per farlo, aggiungi un altro paio di tag XDoclet in cima al file PersonAction.java. Fai questo subito sotto la dichiarazione della classe. Dovresti avere di già il tag XDoclet per l'action-mapping editPerson, ma te lo mostro qui in modo che tu possa vedere tutti i tag XDoclet in cima a questa classe.

La differenza principale fra gli action-mapping editPerson e savePerson è che savePerson ha la validazion attiva (vedi validation="true") nel tag XDoclet sopra. Nota che l'attributo "input" deve riferirsi ad un forward, e non può essre un path (i.e. /editPerson.html). Se preferisci usare il path di save sia per edit che per save, è possibile anche quello. Controlloa solo che sia impostato validate="false", poi nel tuo metodo "save" - dovrai richiamare form.validate() e gestire gli errori in modo appropriato.

Potresti notare che il codice che stai usando per richiamare il PersonManager è lo stesso codice usato nel test PersonManagerTest. Sia PersonAction che PersonManagerTest sono client di PersonManagerImpl, pertanto ciò ha perfettamente senso.

É quasi tutto fatto per questo tutorial, andiamo ad eseguire i test!

Esegui PersonActionTest [#5]

Se guardi il nostro PersonActionTest, tutti i test dipendono dall'avere un record con id=1 nel database (e testRemove dipende da id=2), pertanto aggiungilo al nostro file dati di esempio (metadata/sql/sample-data.xml). Lo aggiungerei in coda - l'ordine non è importante poiché (attualmente) non ha relazioni con altre tabelle.

  <table name='person'>
    <column>id</column>
    <column>first_name</column>
    <column>last_name</column>
    <row>
      <value>1</value>
      <value>Matt</value>
      <value>Raible</value>
    </row>
    <row>
      <value>2</value>
      <value>James</value>
      <value>Davidson</value>
    </row>
  </table>

DBUnit carica questo file prima dell'esecuzione di uno qualsiasi dei nostri test, pertanto questo record sarà disponibile al PersonActionTest.

Ora se esegui ant test-web -Dtestcase=PersonAction - tutto dovrebbe funzionare come previsto. Controlla che Tomcat non sia in esecuzione prima di provare questo.

Ripulisci la JSP per renderla presentabile [#6]

Ora ripuliamo la pagina personForm.jsp generata. Modifica la action di <html:form> in "savePerson" in modo che la validazione sia attiva quando si registra. Modifica anche l'attributo focus da focus="" a focus="firstName" in modo che il cursore sia nel campo firstName quando la pagina viene caricata (questo viene fatto con JavaScript).

Un'altra cosa che devi fare è scommentare le righe seguenti al termine si personForm.jsp. Questo è perché il Validator lancerà un'eccezione se viene specificato un formName e non esistono regole di validazione per esso.

Personalmente, credo che questo sia un bug, ma i Committer di Struts non erano d'accordo.

<html:javascript formName="personForm" cdata="false"
    dynamicJavascript="true" staticJavascript="false"/>
<script type="text/javascript" 
    src="<html:rewrite page="/scripts/validator.jsp"/>"></script>

Ora se esegui ant db-load deploy, fai partire Tomcat e punti il tuo browser si http://localhost:8080/appfuse/editPerson.html?id=1, dovresti vedere qualcosa del genere:

Infine, per rendere questa pagina più user friendly, potresti voler aggiungere un messaggio per i tuoi utenti in cima al form, il che può essere facilmente fatto aggiungenfo del testo (usando <fmt:message>) in cima alla pagina personForm.jsp.

[Opzionale] Crea dei WebTests Canoo per effettuare test di interazioni browser-like [#7]

Il passo finale (opzionale) di questo tutorial è creare un WebTest Canoo per effettuare test sulle JSP.

Dico che questo passo è opzionale, perché puoi eseguire gli stessi test attraverso il tuo browser.

Puoi usare le URL seguenti per effettuare test sulle diverse action di aggiunta, modifica e registrazione di un utente.

• Aggiungi - http://localhost:8080/appfuse/editPerson.html.
• Modifica - http://localhost:8080/appfuse/editPerson.html?id=1 (assicurati di aver eseguito orima ant db-load).
• Elimina - http://localhost:8080/appfuse/editPerson.html?method=Delete&amp;id=1 (o modifica e fai clic sul pulsante Delete).
• Registra - Click edit e fai clic sul pulsante Save.

I test di Canoo sono piuttosto immediati in quanto si configurano tramite un semplice file XML. Per aggiungere test per add, edit, save e delete, apri test/web/web-tests.xml ed aggiungi il seguente XML. Noterai che questo frammento ha un target che si chiama PersonTests per eseguire tutti i test correlati.

Io uso nomi CamelCase per i target (controlo il tradizionale minuscolo, separato da trattini) perché quando digiti -Dtestcase=Name, ho scoperto che sono solito fare il CamelCase per i miei Test JUnit.

Dopo aver aggiunto questo, dovresti essere in grado di eseguire ant test-canoo -Dtestcase=PersonTests con Tomcat in esecuzione o ant test-jsp -Dtestcase=PersonTests se vuoi che Ant faccia lo start/stop di Tomcat per te. Per includere i PersonTests quando vengono eseguiti tutti i test Canoo, aggiungilo come dipendenza al target "run-all-tests".

Noteria che no c'è alcun log nella finestra lato client di Canoo. Se vuoi vedere cosa sta facendo, puoi aggiungere le righe seguenti fra </webtest> e </target> alla fine di ciascun target.

<loadfile property="web-tests.result" 
    srcFile="${test.dir}/data/web-tests-result.xml"/>
<echo>${web-tests.result}</echo>

Prossima Puntata: Parte IV: Aggiungere la Validazione ed una Schermata Elenco - Aggiungere una logica di validazione al personForm in modo che firstName e lastName siano campi obbligatori ed aggiungere una schermata di elenco per visualizzare tutti i record di tipo person nel database.

personForm-final.png

5640 bytes