Gwt-Log

Una delle cose più noiose nel logging con applicazioni GWT è che, lato client, non si riesce ad usare nativamente la console di loggin, ne quella di GWT in Hosted mode, nè quella del server. Il che diventa noioso, poichè spesso si ha la necessita di avere un minimo di tracciabilità delle attività svolte dal codice, e si vuole subito avere un feddback con il loggin, ma con gwt, almeno lato client, sono sempre stato obbligare ad usare i fastidiosi "windows alert".
Certo, da una parte hanno la loro utilità, come quella di bloccare, di fatto, l'esecuzione dell'applicazione e questo può avere un suo aspetto positivo... ma sono troppo invadenti... e soprattutto se ce si li dimentica nel codice, passando poi il prodotto al cliente, si posson avere situazioni imbarazzanti.

Ho trovato, in questi giorni, una libreria davvero interessante per il loggin con GWT

GWT-LOG

Che gestisce in maniera del tutto trasparente il loggin su più livelli... infatti, lasciando fare tutto a lui (ci sono comunque dei setting da poter usare per disabilitare/abilitare i vari tipi di logger), si può avere il log lato server (anche gli errori lato client possono essere spediti in amniera del tutto trasparente al server con rpc), con la normale console errore del server (errori lato server, come con il normale System.out o System.err), sia nella console dell'Hosted Browser di GWT (come con il classico GWT.log)(client e server), sia un log da leggere con al console di FireBug (un ottima estensione di Fiorefox), sia con un interessante "finestrella div" che compare all'interno delal applicazione stessa, un div semitrasparente draggabile...
Insomma, si può fare veramente di tutto e con in pratica nessuna riga di codice particolare... si importa la libreria nel progetto, si inseriscono alcune righe nel file gwt.xml... e basta usare Log(stringa) e via che si logga dappertutto.
Stupendo.


Aggiornamento: Strani Errori
Ieri sembrava funzionare tutto perfettamente, mentre oggi, aggiornando il progetto a GWT 1.5, cambiando quindi librerie eccetera, ho forse commesso qualche errore... e non si compilava più il modulo gwt... continuava a lamentarsi che non trovava la libreria di gwt-log, in particolare che non trovava il file di confiugurazione gwt.xml del progetto gwt-log
L'errore era:
[echo] Module: com.fdlservizi.sse.HelpDeskGWT
[java] Loading module 'com.fdlservizi.sse.HelpDeskGWT'
[java] Loading inherited module 'com.allen_sauer.gwt.log.gwt-log'
[java] [ERROR] Unable to find 'com/allen_sauer/gwt/log/gwt-log.gwt.xml' on your classpath; could be a typo, or maybe you forgot to include a classpath entry for source?
[java] [ERROR] Line 7: Unexpected exception while processing element 'inherits'
[java] com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries)
[java] at com.google.gwt.dev.cfg.ModuleDefLoader.nestedLoad(ModuleDefLoader.java:225)
[java] at com.google.gwt.dev.cfg.ModuleDefSchema$BodySchema.__inherits_begin(ModuleDefSchema.java:194)
[...]

Non so per quale motivo, ma ignorava totalmente la presenza della libreria, che invece avevo normalmente selezionato tar le librerie esterne in IntelliJ Idea.
Poi, guardando bene il forum di grails (in particolare questa discussione), non ho capito bene perchè, ho scoperto che dovevo inserire tale libreria nella directory /lib/gwt.
Cosa mai fatta, anche perchè eventualmente le librerie le avrei messe in /lib, dentro al quale la directory gwt non esisteva nemmeno.
Ora invece, con l file messo lì dentro, funziona senza problemi.... misteri di grails.

Grails + GWT

Ho finito di leggere ed applicare l'esempio del libro "Getting started with Grails"... sembra proprio essere un gran bel framwork, ottimo per lo sviluppo di service web, praticamente fa tutto lui e grazie alla convention over configuration il codice da scrivere è davvero poco. Eseguendo la logica del MVC sembra non sia difficile integrare, come parte "view" del client dei moduli GWT.

Quindi ora passo allo studio proprio dell'integrazione di Grails con GWT.
Esiste un plugin per grails, già esistente nella normale installazione di Grails: http://grails.org/GWT+Plugin

Purtroppo sul sito di codehouse il plugin, o meglio, l'integrazione effettiva di gwt e grails non sono ben documentate, anzi...
Per prima cosa l'installazione del plugin nei singoli progetti grails non è veloce, almeno la prima volta: eseguito nel progetto racetack, quello che ho creato studiando GSWG, il comando
grails install-plugin gwt
ho dovuto aspettare quasi 10 minuti prima che si "ripulisse la cache"... di cosa non so bene.

Ho quindi creato il modulo gwt, chiamandolo Racetrack, seguendo la classica regola dei nomi del package, quindi con il comando
grails create-gwt-module com.fdlservizi.Racetrack

Seguendo la logica che quella che voglio fare è una view al progetto già esistente e funzionante, ho creato la pagina hosting del modulo gwt pensandola proprio come una view al controller "race".
La convenzione del plug in di gwt vuole che con il comando grails create-gwt-page , dove è la pagina hosting con il relativo path, se la pagina è indicata come una gsp e come indirizzo ha una singola cartella, questa viene interpretata come un controller view, altrimenti viene trattata come una normale pagina web.
Quindi ho eseguito il comando
grails create-gwt-page race/gwt.gsp com.fdlservizi.Racetrack

Tutto ciò dovrebbe avermi creato i file di configurazione necessari per il funzionamento del modulo gwt, e la pagina hosting dove mettere poi i widget gwt.
Con il comando
grails run-gwt-client
parte l'esecuzione dell'hosted mode di gwt, quindi parte anche il "browser" interno di gwt... va però precisato, e io me ne sono accorto dopo un po' di imprecazione, che deve essere attivo il server web... quindi da IDEA prima faccio partire il progetto racetrack e poi eseguo il comando run-gwt-client (ovviamente questo e i comandi precedenti vanno fatti all'interno del path del progetto racetrack)


Edit 8 Maggio
Iniziano i primi problemi... in pratica, come indicato nella pagina del plugin di gwt, per poter usare map e list in gwt, bisogna specificare nel servizio di grails il tipo di ritorno di queste liste o mappe. In teoria questo lo si dovrebbe fare con @CollectionTypeArg e @MapTypeArg ma qui casca l'asino. Il mio ambiente non vede le classi per queste annotation... viene questo errore
"unable to find class for annotation"
Ho chiesto aiuto nella mailing list di Nabble Grails User
Vediamo se ottengo aiuto.

Edit
Pausa pranzo finita e per ora nessun aiuto. Ho cercato di arrangiarmi e qualcosa, forse, ho risolto. Smattendo a destra e a manca no trovato dove risiede la classe delle annotazioni del plug in di gwt... in pratica nella directory del porgetto, sotto plugin in, vi è la directory in cui vi sono due jar. Uno di questi è grails-gwt-util.jar
Ho importato questa libreria da IDEA, andando in Setting -> Project Setting -> Library -> Attach Classes -> e ho selezionato il jar di cui sopra.
Poi nel file in cui voglio usare le annotazioni ho importato il riferimento alle annotazioni con
import org.codehaus.groovy.grails.plugins.gwt.annotation.CollectionTypeArg
Non so se è il metodo corretto, nè perchè abbia dovuto farlo (presupponevo che il plugin di GWT almeno importasse le jar necessarie al suo funzionamento), ma sembra funzionare.

Enunciate, Maven, GWT, forse Spring, qualcos'altro?

Mi sto studiando un po' Enunciate, alla fine sembrerebbe interessante e potrebbe servirci per velocizzare lo sviluppo dei Web Services, evitando di scrivere tanto codice piuttosto ridondante.

Facendo il primo tutorial, anzi, il secondo, mi sono trovato di fronte ad un po' di difficoltà... si integra maven, con GWT, con enunciate, e volendo pure con spring... quindi insomma, un po' difficile per me che non conosco bene praticamente nessuna di queste tecnologie.

Comunque, spulciando un po' nei readme di enunciate (nella release ci sono anche 3 esempi) e un po' spulciando in rete, ho trovato come fare.

Dalla directory principale del sample, dal prompt dei comandi, si lancia maven

mvn -Dgwt.home=/path/to/gwt/home package

ovviamente inserendo il path dell'installazione di gwt
Questo comanda chiede a maven di compilare il progetto... nel progetto infatti c'è già un file pom.xml bello pronto.

Altrimenti si può chiedere a maven di compilate, far partire il server jetty e pubblicare il tutto, così da renderlo accessibile in locale, con questo comando

mvn -Dgwt.home=/path/to/gwt/home jetty:run-war

e puntando il browser su http://localhost:8080/petclinic/petclinic.html (petclinic è il secondo il progetto che i tutorial di enunciate prendono in considerazione) si vede il tutto all'opera

Se in più si vuole creare i file per importare il tutto in eclipse, si usa il plugin eclipse di maven, digitando sempre dalla directory root del progetto

mvn eclipse:eclipse

In alcuni casi, non ho capito bene l'agoritmo però, bisogna controllare la path in eclipse... verificando che tutte le librerie siano importate in maniera corretta

Si può inoltre evitare di scrivere, via riga di comando, il parametro -Dgwt.home (quindi per esempio richiamando il comando con "mvn jetty:run-war") inserendo nel file di configurazione enunciate.xml questo parametro

gwtHome="c:\Programmi\GWT\gwt-windows-1.4.62"

rispettando ovviamente la path della propria installazione di gwt, all'interno della dichiarazione del modulo gwt. Per esempio, nel mio petclinic, il file enunciate.xml, è così composto

<enunciate>
  <modules>
    <gwt disabled="false"
gwtHome="c:\Programmi\GWT\gwt-windows-1.4.62"
       
rpcModuleName="org.codehaus.enunciate.samples.petclinic.PetClinic">
      <app
srcdir="src/main/gwt-apps" javascriptstyle="PRETTY">
      
<module
name="org.codehaus.enunciate.samples.petclinic.app.PetClinicApp">
      </app>
    </gwt>
    <amf disabled="true">
      <app
srcdir="src/main/flex-apps" name="vets"
mainmxmlfile="src/main/flex-apps/org/codehaus/enunciate/samples/petclinic/flex/vets.mxml">
    </amf>
  </modules>
</enunciate>

GWT-RPC

Attualmente sono arrivato in una fase di stallo per lo studio di Maven: ho capito cosa è e grossomodo come funziona. Idem, grossomodo, per Spring: ho capito, grossomodo, cosa è e ho un infarinatura su come funziona.

Ora però mi sono reso conto che è inutile, o comunque troppo complicato, per me studiarmi l'integrazione tra GWT e Spring, che in effetti sembra essere una buona strada, se non so bene come si comportano le RPC in GWT.

Quindi ho deciso di ritornare sullo studio di GWT, in particolare sull'utilizzo delle sue RPC (GWT-RPC). Una volta studiate, se sarò in grado di utilizzarle in maniera decente, e potrò dire di conoscerle, forse potrò affrontare l'integrazione con Spring senza troppa difficoltà... e se voglio analizzare altri sistemi di dialogo Client-Server, per sapere che strada affrontare, è il caso che conosca bene le RPC per conoscerne vantaggi e svantaggi.

Ho trovato qualche altro tutorial in rete:

• RPC To Java Tutorial
• Java Version of GWT-RPC, una discussione sul gruppo gwt di google groups
• Using Google Web Toolkit RPC with AsyncCreator, descrizione di un tool per la generazione automatica di codice per le chiamate asincrone

RPC To Java Tutorial
Ho provato ad usare questo tutorial. Molto semplice, con poche informazioni e non spiegato benissimo, da però alcuni accorgimenti interessanti per gli "niubbi" di Java e gwt
Ho voluto però implementarlo da zero. Non ho quindi usato il codice online, ma ho creato un progetto in Eclipse da zero e piano piano ho aggiunto il codice.
Nuovo progetto web dinamico
Ho poi aggiunto il modulo GWT (dal progetto, new -> other -> GWT Module)
Ho aggiunto poi il modulo per le rpc (in pratica crea le classi async, imple eccetera, sia per client che per server) (dal progetto, new -> other -> GWT Remote Service)
Ho aggiunto il codice del tutorial (rinominando però RPCImpl in RPCInterfaceImpl perchè mi pareva più conforme agli standard... usare il nome stesso, aggiungendo prima async e poi impl)
Ho rinominato anche il nome del modulo, ma nulla di che

però ho poi dovuto consultare il codice che veniva fornito, perchè ho dovuto aggiungere questa riga al file "nomemodulo".gwt.xml perchè la configurazione di eclipse non la crea

Rilasciato un aggiornamento minore di GWT: GWT 1.4.62

Mentre sto un po' impazzendo per studiarmi almeno un pochino (giusto un infarinatura, prima di buttarmici seriamente) riguardo spring e la sua integrazione con gwt, leggo che è stata rilasciata ieri un aggiornamento, minore, a GWT.
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/bd5cbb7a0d5b60aa
sembrano solo bugfix... ma dato che uno di questi sembra importante per problemi connessi a Firefox3, e dato che il rilascio di FF3 sembra imminente, forse è il caso di aggiornarsi...

Chissà quando verrà rilasciato GWT 1.5
In questo caso l'aggiornamento sarà decisamente più interessante, no?

Spring / Hibernate e altri framework

Studiando per la rete il pattern MVC, sono incappato in alcuni framework che inizialmente avevamo considerato per lo sviluppo del nostro frameweork, tra i quali, Spring (http://www.springframework.org/), Hibernate (http://www.hibernate.org/) e altri framework che possono aiutarci nello sviluppo di ciò che vogliamo realizzare

• Spring
  E' un framework a strati per la realizzazione di applicazioni Java/J2EE. Ha al suo interno diversi "moduli", tra cui una sorta di implementazione del pattern MVC e permette la facile integrazione di altri framework, come Hibernate.
  Un interessante articolo: Mokabyte Sprin e successivi
  
  
• Hibernate
  è una piattaforma middleware open source per lo sviluppo di applicazioni Java che fornisce un servizio di Object-relational mapping (ORM), ovvero che gestisce la rappresentazione e il mantenimento su database relazionale di un sistema di oggetti Java.
  
  
• GWT Server Library
  Una libreria che permette la facile integrazione tra GWT e Spring
  

GWT, JSTM e JSTM4GWT

In questa settimana sono riuscito nell'impresa di far dialogare GWT con JSTM4GWT (la versione per GWT di XSTM) e JSTM (la versione Java di XSTM.
Ho realizzato (e sto ampliando) un piccolo esempio per verificare se riesco ad ottenere da XSTM ciò che voglio.

L'idea di base è cercare di creare una form logica sul server, via Java, replicarla in GWT sul client, sia in via logica che come UI fisica sul browser e far comunicare il tutto in maniera semplice senza PRC.

Lo strato che fa la maggior parte del lavoro è proprio, ovviamente XSMT... si realizza la maschera (form) logica sul server via java... sul serve non serve una rappresentazione visiva (ma sarebbe immediato implementarla). Si condivide con il client questa maschera logica (attraverso appunto il dialogo JSTM e JSTM4GWT) e la si replica poi in GWT per realizzarla fisicamente sul browser, e viceversa

In questo modo ogni interazione sulla maschera fatta da un utente sul client viene replicata sulla maschera logica sul server, che può agire autonomamente in base ad ascoltatori che intercettano le variazioni della maschera logica, aggiorna la maschera logica che poi verrà replicata immediatamente sul client

Per ora, nell'esempio che ho fatto io, si replicano immediatamente sul client le modifiche fatte sulla maschera logica del server... ma non viceversa (bisogna sempre premere il tasto "commit"... questo anche per una scelta architetturale di JSTM), anche se il comportamento è non difficilmente modificabile (già parzialmente testato)

Il server riesce a capire se le modifiche sulla maschera logica sono avvenute internamente al server o dal client e quindi può agire diversamente di conseguenza.

A quanto pare sono riuscito ad ottenere ciò che volevamo... devo verificare alcuni dettagli ma forse siamo arrivati ad un livello di astrazione/interazione vicino a quello che vorremmo ottenere... anche perchè la realizzazione grafica del client può essere abbastanza facilmente svincolata da GWT e realizzata in uno dei qualsiasi 3 linguaggi supportati da XSTM: Java, .NET e appunto Java/GWT

Risorse GWT

Ora mi sono messo in rete a spulciare un po' di risorse per GWT, così nei prossimi giorni mi studio altro e provo a sviluppare qualcosa in GWT. Il fine primario è quello sia di imparare meglio a programmare in Java, sia famigliarizzare di più con GWT ma soprattutto tenere a mente l'obbiettivo che devo pormi per la il progetto/tesi: trovare un modo per sviluppare uno strato intermedio tra il server e il client... andando a fare qalcosa di simile a ciò che fa già echo2; in pratica fare in modo di non dover usare solo RPC per ogni interazione del client, ma cercare di pensare sul server la stessa logica sul client, fare comunicare le due logiche e interagire solo con quella lato server

• GWT Windows Manager (http://www.gwtwindowmanager.org/)
  Offre un sistema "ad alto livello" per la creazione/gestione di finestre e finestre di dialogo. Davvero bello e ben fatto. Da tenere in considerazione.
• GWT-EXT (http://gwt-ext.com/)
  Libreria fornitissima, con alberi, finestre, layout, e veramenti molti widgets, alcuni interessantissimi.
• GWTSITE (http://www.gwtsite.com/)
  Un blog con un sacco di risorse interessanti, link utili, tutorial ecc..
• OnGWT (http://www.ongwt.com/)
  Altro blog aggiornato con risorse su GWT
• Tutorial GWT
  Un elenco di 17 nuovi tutorial su GWT, alcuni sembran interessanti, altri meno
• XSTM (http://www.xstm.net/)
  Replicazione e sincronizzazione di oggetti, tra client e client, o client e server, per Java, .NET e GWT. Può esserci molto utile
• GWT-Tooling (http://code.google.com/p/gwt-tooling/)
  Plugin per Eclipse... questo pare funzionare davvero. Dopo averlo installato, per usarlo, in Eclipse creo un nuovo progetto Web dinamico, seleziono Apache Tomcat 6 come Target Runtime, e seleziono "dinamic web project using GWT" in configuration. Poi una volta creato il progetto, lo seleziono, e con il destro "new" "other" "GWT" "Gwt module". Poi "run on server" (in realtà forse bisogna selezionare run as -> open run dialog -> GWTBrowser)
  
• MyGWT (http://mygwt.net)
  Libreria con alcuni riguardi vero il pattern Model-View-Controller (MVC)
• GWT Small Guide: Integrazione GWT e PHP con JSON
  

Cypal Studio for GWT

Leggengo "GWT in Action" scopro, e questo è un altro punto a favore di GWT, che esistono alcuni tool per aiutare la vita dello sviluppatore GWT (sì, ok, non posso ancora definirmi uno sviluppatore GWT, manco mi posso definire sviluppatore, però è interessante).
Tra questi un plug in di Eclipse che potrebbe tornarmi utile: Cypal Studio for GWT
E annesso a questo trovo anche un tutorial che mi insegna ad usare questo plugin: http://grprakash.googlepages.com/gwttutorialwithgooglipse

Ritorno a GWT

Parlando stamane con il mio correlatore, abbiamo pensato, soprattutto vista la non entusiastamente esperienza con la scarsa presenza di documentazione su Echo2/Cooee e la scarsa attività delle community a queste connesse, di riprovare a dare uno sguardo a GWT.

Questo perchè? Forse principalmente per la prima lettera di GWT... la G di Google. Dopotutto questa G da garanzie di stabilità futura, di continua manutenzione. Ma soprattutto è sinonimo di ottima documentazione, grande community e numerosi utilizzatori.

Per fare un esempio, se si cercano in rete tutorial o libri su GWT in breve tempo se ne trovano una marea... su Echo2/Cooee? Poco o nulla

L'idea è tornare su GWT per quanto riguarda l'aspetto client, il disegno dell'interfaccia web, e di pensare noi a qualcosa che possa interfacciarsi con questa per dialogare con il server, senza usare le RPC previste da google

Nel libro "GWT in Action", nella parte in cui si parla di un confronto/integrazione con Ruby On Rail si sottolinea che è possibile intraprendere questa strada: (PAG 24 del pdf)

GWT is client-centric, and most of what GWT does is on the client-side of the picture. It allows you to develop and display widgets using Java and write Java handlers to trap user-triggered actions. GWT can communicate with the server, as needed, which could be driven by user interaction, or perhaps a timed event.
GWT then allows you to compile all of the Java code to JavaScript so that the program can be run in the browser. On the server, GWT only provides a mechanism for serializing and desterilizing Java objects so that they can be received from the browser and sent back, and does not get involved in other aspects of the server.
Instead of competition between GWT and Ruby on Rails, we find an opportunity for integration. This is in part driven by the fact that GWT provides several non-proprietary schemes for passing data between client and server. We are finding that many developers who are starting to use GWT are using non-Java technologies on the server, and are looking at GWT to provide only client-side functionality.

Credo che il discorso si possa allargare ad ogni tecnologia (o quasi) ci sia su lato server. Ora mi studio ancora un po' GWT, sperando di riuscire ad apprenderlo a fondo in modo da concretizzare l'idea di realizzare un "interfaccia lato client con GWT e lato server con Java"

Federico Fissore e Cooee

La settimana scorsa, tra le poche cose fatte, ho scritto a Federico Fissore (www.fissore.org), personaggio che spesso è "saltato fuori" durante le mie ricerche in internet riguardo a echo2. A quanto pare è uno degli italiani che ha sviluppato con questo fremowork.
Gli ho scritto chiedendogli un suo parere sul futuro di Echo2... gli ho spiegato la mia situazione chiedendogli qualche consiglio.
Prontissimo e gentilissimo mi ha risposto...

Incollo qui la sua rispota... può sempre essere utile a qualcun altro:

[...]
Dunque, se posso riassumere la tua mail, tu vuoi sapere se Echo2/3 sono
una soluzione viabile e, se sì, dove trovare documentazione più completa

Il mio parere, e mi spiace davvero tanto dirlo, è negativo: no, non mi
fiderei troppo di Echo2, per una somma di ragioni diverse, che ti
snocciolo perchè tu possa usarle anche in altri contesti

Framework per costruire Rich Internet Applications ce ne sono tanti,
troppi: spiccare fra gli altri è difficile.
GWT ci riesce per due motivi

* si chiama GOOGLE web toolkit (ChiTiConosce web toolkit non avrebbe
avuto lo stesso successo)
* come dicevo nell'intervista, GWT si presta più facilmente allo
sviluppo di applicazioni per il grande pubblico, il che significa
visibilità e passaparola

Tutti gli altri rimangono nelle nicchie, e lì gioca davvero il loro
valore e la loro community.
Sul valore di Echo2 non ho dubbi: è tecnicamente un OTTIMO strumento. Le
API sono chiare e semplici. Si possono fare (e ho fatto) cose moolto
interessanti con poche righe di codice. Personalmente mi sono davvero
divertito
Ma Echo2 è un prodotto di nicchia, gestito ahimè da un idiota, che

* non ha abbastanza soldi per sviluppare certe componenti importanti
* ha una community piccola, quindi in grado di sopperire alle
mancanze economiche con eccessiva lentezza
* non è molto propenso a dare accesso in scrittura ai membri anche
capaci della comunità, causando un rallentamento anche
nell'applicazioni delle patch proposte dai membri della comunità

Un'alternativa è Cooee (http://karora.org/), fork di Echo2, che promette di fare
manutenzione evolutiva sui componenti esistenti (evitando di rompere la
retro compatibilità come ha fatto Echo3). Anche qui, per quel poco che
ne so, la community è piccola

Quindi?
Ho lavorato con Echo2 per un anno, sviluppandoci 2 progetti. Oggi a quel
mio cliente propongo di passare a Cooee per non dover rifare tutto ma
per evitare di applicare delle patch fatte in casa come invece fa oggi
(le patch che ho sviluppato io e che sono sempre state ignorate
dall'idiota di prima, nonostante il numero di download di chi se le
voleva applicare a mano)

Se però dovessi cominciare un lavoro nuovo, penserei ad altro
ZK (http://zkoss.org/) sembra essere un buon prodotto: è GPL, quindi non ci si può fare
applicazioni proprietarie da redistribuire, ma continua a ricevere elogi
e chi lo ha usato qui a Torino me ne ha parlato bene
wingS (http://wingsframework.org/) è un altro progetto che mi attira: ha delle API molto simili a
Swing ed è sviluppato da tedeschi (quindi si "gioca in casa")
openlaszlo (www.openlaszlo.org/): altro progetto moolto interessante per supporto e
qualità finale del prodotto. Con la versione 4 hanno finalmente aggiunto
un rendering DHTML invece del solo rendering Flash (che 2 anni fa me lo
aveva fatto scartare)
[...]