Raible's Wiki: ValidationAndList

At line 1 changed 1 line.

__Parte IV:__ [Aggiungere Convalida e Schermata Elenco|ValidationAndList_it] - Aggiungere un logica di convalida 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.

__Parte IV:__ [Aggiungere Validazione e Schermata Elenco|ValidationAndList_it] - Aggiungere un 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.

At line 7 changed 1 line.

Questo tutorial ti mostrerà come aggiungere una logica di Convalida (sia lato client che server) all'oggetto PersonForm usando il Validator di Struts. Creeremo anche una schermata di elenco usando la [Display Tag Library|http://displaytag.sf.net] per visualizzare tutte le persone nel database.

Questo tutorial ti mostrerà come aggiungere una logica di Validazione (sia lato client che server) all'oggetto PersonForm usando il Validator di Struts. Creeremo anche una schermata di elenco usando la [Display Tag Library|http://displaytag.sf.net] per visualizzare tutte le persone nel database.

At line 13 changed 1 line.

* [2] Visualizza la JSP con la convalida aggiunta ed effettua un test

* [2] Visualizza la JSP con la validazione aggiunta ed effettua un test

At line 22 changed 1 line.

To use the Struts Validator, normally you have to write a validation.xml file by hand. If you're not using AppFuse, you also have to configure the Validator Plugin and error keys in your ApplicationResources.properties. For more information on this, see the [Validation Made Easy Tutorial|http://www.reumann.net/struts/lesson3/step8.do] (there's also a [rich set of tutorials|http://www.reumann.net/struts/main.do] for Struts itself).

Per usare il Validator di Struts, normalmente devi scrivere un file validation.xml a mano. Se non stai usando AppFuse, devi anche configurare il Plugin Validator e le chiavi degli errori nel tuo ApplicationResources.properties. Per ulteriori informazioni sull'argomento, vedi il [Tutorial Validation Made Easy|http://www.reumann.net/struts/lesson3/step8.do] (c'è anche un [ricco insieme di tutorial|http://www.reumann.net/struts/main.do] per Struts da solo).

At line 24 changed 1 line.

Thanks to XDoclet, it's much easier - you just need to add a couple of ''@struts.validator'' tags to the Person class. Open it up (src/dao/**/model/Person.java) and modify the getFirstName() and getLastName() methods to include ''@struts.validator type="required"'' tags.

Grazie ad XDoclet, è molto più semplice - devi solo aggiungere un paio di tag ''@struts.validator'' alla classe Person. Apri (src/dao/**/model/Person.java) e modifica i metodi getFirstName() e getLastName() in modo da includere i tag ''@struts.validator type="required"''.

At line 45 changed 1 line.

You can also add a ''msgkey'' attribute to this tag to override the default message key for this error.

Puoi anche aggiungere un attributo ''msgkey'' a questo tag per fare l'override della chiave di default relativa al messaggio associato a questo errore.

At line 52 changed 1 line.

The default key for type="required" is already ''errors.required'', so I usually leave it to the default. This key is defined in web/WEB-INF/classes/ApplicationResources_*.properties. You'll notice that we put these tags on the ''getters'' of this class even though the [XDoclet documentation|http://xdoclet.sourceforge.net/tags/apache-tags.html#@struts.validator%20(0..*)] says to put them on the setters. This is because we are generating our PersonForm.java - the template file (metadata/template/struts_form.xdt) takes care of putting these tags onto the setters in the generated file.

La chiave di default per type="required" è già ''errors.required'', pertanto io di solito la lascio al valore di default. Questa chiave viene specificata in web/WEB-INF/classes/ApplicationResources_*.properties. Come avrai notato, stiamo mettendo questi tag nei ''getter'' di questa classe per quanto la [documentazione di XDoclet|http://xdoclet.sourceforge.net/tags/apache-tags.html#@struts.validator%20(0..*)] dica di metterli nei ''setter''. Questo perché stiamo generando il nostro PersonForm.java - il file del modello (metadata/template/struts_form.xdt) si preoccupa di mettere questi tag sui ''setter'' nel file generato.

At line 54 changed 1 line.

Now if you save Person.java and run __ant clean webdoclet__, a validation.xml file will be generated in build/appfuse/WEB-INF/. Its contents should have now have an entry for "personForm".

Ora se registru Person.java ed esegui __ant clean webdoclet__, verrà generato un file validation.xml in build/appfuse/WEB-INF/. Il suo contenuto dovrebbe includere una voce per "personForm".

At line 72 changed 1 line.

Client-side validation is enabled by default in personForm.jsp. There is an <html:javascript> JSP tag and script at the bottom of this page that enables it. The following should already exist (thanks to AppGen) - but you might need to uncomment it if you commented it out in the last tutorial.

La validazione lato-client è attivata per default in personForm.jsp. C'è un tag JSP <html:javascript> ed uno script in fondo alla pagina che lo attiva. Ciò che segue dovrebbe esser già presente (grazie ad AppGen) - ma potresti aver bisogno di rimuovere il commento se avevi commentato il blocco nel file nel tutorial precedente.

At line 79 changed 1 line.

%%note __NOTE:__ If you have nested objects with validation rules, those will be picked up and put into validation.xml. This is because an @struts.validator tag gets added to the setter of the nested object when the form is generated (using metadata/templates/struts_form.xdt). If you have many-to-many bi-directional relationships between objects, this can cause a problem. There are two solutions to fix this. The first is to remove the @struts.validator tag from struts_form.xdt and manually place it on the setter in your POJO. The second is [described here|https://appfuse.dev.java.net/issues/show_bug.cgi?id=88].%%

%%note __NOTA:__ Se hai oggetti innestati con regole di validazione, verrano presi e messi nel validation.xml. Ciò avviene in quanto un tag @struts.validator viene aggiunto al setter dell'oggetto innestato quando viene generato il form (usando metadata/templates/struts_form.xdt). Se hai relazioni molti-a-molti bidirezionali fra oggetti, ciò potrebbe essere un problema. Ci sono due soluzioni per risolvere la questione. La prima è eliminare il tag @struts.validator tag da struts_form.xdt e posizionarlo a mano sul setter nel tuo POJO. La seconda viene [descritta qui|https://appfuse.dev.java.net/issues/show_bug.cgi?id=88].%%

At line 81 changed 1 line.

!!Visualizza la JSP con la convalida aggiunta ed effettua un test [#2]

!!Visualizza la JSP con la validazione aggiunta ed effettua un test [#2]

At line 83 changed 1 line.

Now that you have Validation configured for this form, whenever this form is used in an action-mapping with validate="true", these rules will be applied. In the [last tutorial|CreateActions], we added the "savePerson" action-mapping for PersonAction. The XDoclet tags for this action-mapping were:

Ora che hai configurato la Validazione per questo form, ogni volta che questo form viene usato in un action-mapping con validate="true", verranno applicate queste regole. Nell'[ultimo tutorial|CreateActions_it], abbiamo aggiunto l'action-mapping "savePerson" per la PersonAction. I tag XDoclet per questo action-mapping erano:

At line 91 changed 1 line.

So now, as long as your web/pages/personForm.jsp has <html:form action="savePerson">, validation should kick in when we try to save this form. Run __ant db-load deploy__, start Tomcat and go to [http://localhost:8080/appfuse/editPerson.html?id=1].

Pertanto ora, se la tua web/pages/personForm.jsp ha un <html:form action="savePerson">, dovrebbe intervenire la validazione ogni volta che proviamo ad inviare questo form. Esegui __ant db-load deploy__, avvia Tomcat e vai a [http://localhost:8080/appfuse/editPerson.html?id=1].

At line 93 changed 1 line.

If you erase the values in the firstName and lastName fields and click the save button, you should get the following JavaScript alert.

Se cancelli i valori nei campi firstName e lastName e fai clic sul pulsante registra, dovresti ottenere il seguente alert JavaScript.

At line 99 changed 1 line.

To make sure things are ''really'' working as expected, you can turn off JavaScript and ensure the server-side validation is working. This is easy in [Firefox|http://www.mozilla.org/products/firefox/] (my favorite browser), just go to Tools → Options → Web Features and uncheck "Enable JavaScript". Now if you clear the fields and save the form, you should see the following:

Per assicurarti che le cose funzionino ''davvero'' come previsto, puoi spegnere JavaScript e verificare se la validazione lato-server sta funzionando. Ciò è semplice in [Firefox|http://www.mozilla.org/products/firefox/] (il mio browser preferito), basta che vai in Strumenti → Preferenxe → Contenuto e deselezioni "Abilita JavaScript". Ora se cancelli i campi e invii il form, dovresti vedere il messaggio seguente:

At line 105 changed 1 line.

If you don't see these validation errors, there are a couple possibilities:

se non vedi questi errori di validazione, ci sono un paio di possibilità:

At line 107 changed 4 lines.

* The form saves with a success message, but the firstName and lastName fields are now blank.

;:''This is because the <html:form> in web/pages/personForm.jsp has action="editPerson" - make sure it has __action="savePerson"__.''

* You click save, but a blank page appears.

;:''The blank page indicates that the "input" attribute of you "savePerson" forward is incorrectly configured. Make sure it relates to a local or global action-forward. In this example, it should be __input="edit"__, which points to the .personDetail tile's definition. From my experience, the input's value must be a forward, not a path to an action.''

* Il form registra cin un messaggio di successo, ma i campi firstName e lastName sono ora vuoti.

;:''Questo perché l'<html:form> in web/pages/personForm.jsp ha action="editPerson" - controlla che abbia __action="savePerson"__.''

* Fai clic su registra, ma compare una pagina vuota.

;:''La pagina vuota indica che l'attributo "input" del tuo forward "savePerson" non è stato configurato correttamente. Controlla se si riferisca ad un action-forward locale o globale. In questo esempio, dovrebbe essre __input="edit"__, che punta alla definizione del tile .personDetail. Dalla mia esperienza, il valore di input dovrebbe essere un forward, non un path ad una action.''

At line 112 changed 1 line.

If you only want server-side validation (no JavaScript), you can remove the ''onsubmit'' attribute of <html:form> (in web/pages/personForm.jsp) as well as the Validator JavaScript tags at the bottom of the page.

Se vuoi la sola validazione lato server (niente JavaScript), puoi eliminare l'attributo ''onsubmit'' da <html:form> (in web/pages/personForm.jsp) come anche i tag JavaScript del Validator in fondo alla pagina.

At line 123 changed 1 line.

To create a List screen (also called a master screen), we need to create methods that will return all the rows from our ''person'' table. Let's start by adding tests for these methods to our PersonDaoTest and PersonManagerTest classes. I usually name this method ''getEntities'' (i.e. getUsers), but you could also use ''getAll'' or ''search'' - it's really just a matter of personal preference.

Per creare una schermata di Elenco (chiamata anche schermata master), dobbiamo creare dei metodi che restituiscano tutte le righe dall nostra tabella ''person''. Iniziamo con l'aggiungere i test per questi metodi alle nostre classi PersonDaoTest e PersonManagerTest. Di solito io chiamo questi metodi ''getEntities'' (i.e. getUsers), ma potresti usare anche ''getAll'' o ''search'' - è solo questione di preferenze personali.

At line 125 changed 1 line.

Open test/dao/**/dao/PersonDaoTest.java and add a ''testGetPeople'' method:

Apri test/dao/**/dao/PersonDaoTest.java ed agiungi un metodo ''testGetPeople'':

At line 136 changed 1 line.

The reason I'm passing in a person object to the ''getPeople'' method is to allow for filtering (based on values in person) in the future. Adding this parameter in your getPeople() method signature is optional, but the rest of this tutorial assumes you have done this.

Il motivo per cui sto passando un oggetto person al metodo ''getPeople'' è per permettere in futuro di filtrare il risultato (basandomi come criterio sui valori presenti in person). Aggiungere questo parametro alla firma del tuo metodo getPeople() è opzionale, ma il resto di questo tutorial assume tu lo abbia fatto.

At line 138 changed 1 line.

Now open test/service/**/service/PersonManagerTest.java and add a ''testGetPeople'' method:

Ora apri test/service/**/service/PersonManagerTest.java ed aggiungi un metodo ''testGetPeople'':

At line 157 changed 1 line.

In order for these tests to compile, you need to add the ''getPeople()'' method to the PersonDao and PersonManager interfaces, and their implementations.

Affinché questi test compilino, devi aggiungere il metodo ''getPeople()'' alle interfacce PersonDao e PersonManager, nonché alle relative implementazioni.

At line 160 changed 1 line.

Open src/dao/**/dao/PersonDao.java and add the getPeople() method signature:

Apri src/dao/**/dao/PersonDao.java ed aggiungi la firma del metodo getPeople():

Raible's Wiki

AppFuse

Other Applications

ValidationAndList_it