Archivi categoria: DOCUMENTAZIONE

La categoria contiene tutta la documentazione disponibile per la consultazione

TUTORIAL GWT – COME DEBUGGARE USANDO IL SUPERDEV

Con l’introduzione del superdev mode non è più possibile usare il debug nel nostro IDE come siamo stati abituati. Per poter usare il debug occorre installare il plugin SDBG disponibile qui.

Una volta installato il plugin avviamo il nostro progetto tramite il superdev mode e una volta che  il sistema è correttamente avviato, creiamo una configurazione Chrome  che carichi la hosted page e su questa avviamo il debug.

Se abbiamo fatto tutto correttamente verranno attivati i breakpoint selezionati in Eclipse, e sarà anche possibile usare il debug all’interno di Chrome, usando il Chrome DevTools JavaScript debugger.

TUTORIAL JHIPSTER – PRIMI PASSI

Durante la fase di scouting per valutare nuovi framework e nuove librerie mi sono imbattuto in JHIPSTER. Si tratta di una piattaforma di sviluppo che consente di generare una applicazione con quello che gli autori reputano il meglio che il panorama offre. Nel momento in cui scrivo la versione è la 4.14.0, che permette di realizzare una webapp basata su Spring Boot 1.5 e Angular 5, mentre la versione 5, già annunciata, promette il passaggio a Spring Boot 2 e l’introduzione di React  per il client e la rimozione di Angular JS. JHIPSTER ha vinto il Duke’s Choice Award 2017  e si è classificato terzo al JAX Innovation award nella categoria maggior innovazione per l’ecosistema JAVA.

Avvicinarsi a JHIPSTER ci da il vantaggio di vedere concentrato il top delle tecnologie a disposizione del mondo JAVA e ci da l’opportunità di assemblarle riducendo al minimo i tempi di creazione della applicazione. Partiamo subito e tiriamo su il nostro primo  progetto. Per usare JHIPSTER abbiamo sei approcci possibili:

  • JHipster Online è un tool online che ti guida nella creazione dell’app, va bene come prova ma allo stato attuale non consente di gestire modifiche successive
  • “Locale con YARN” è la modalità suggerita dagli autori. Si basa su YARN , che  è il package manager sviluppato da facebook basato su NPM.
  • “Locale con NPM” è identica alla precedente, ma usa NPM il package manager di Node.js.
  • “Installazione tramite package manager” è ancora in beta
  • “Box Vagrant” è disponibile una macchina virtuale che contiene tutti gli strumenti necessari.
  • Docker” è disponibile un container docker contenente gli strumenti necessari

Usiamo la modalità consigliata e seguiamo i seguenti passi:

  • Installiamo Java 8
  • Installiamo Node.js
  • Installiamo Yarn
  • installiamo Yeoman tramite il comando: yarn global add yo. Yeoman è un tool che consente di creare la struttura base di una app.
  • installiamo JHipster tramite il comando: yarn global add generator-jhipster

Seguendo questi step siamo in grado di creare la nostra app con front-end Angular, qualora volessimo usare AngularJS dobbiamo aggiungere altri due step:

  • Installare Bower: yarn global add bower. Bower è un package manager rimasto in maintenance, ormai sostituito da YARN e WEBPACK.
  • Installare Gulp: yarn global add gulp-cli. Gulp è un task manager.

A questo punto non resta che creare la nostra prima applicazione. Creiamo una directory e al suo interno lanciamo il comando: jhipster

E qui inizia il bello. Jhipster ci interroga sulle caratteristiche che vogliamo e il gioco è fatto, alla fine abbiamo una applicazione correttamente funzionante, da poter importare nel nostro editor preferito.

Per vederla funzionante lanciate il comando mvnw, che tirerà su il progetto su porta 8080.

TUTORIAL GWT – CREARE UNA WEBAPP CON GWT 2.8

Da tempo pensavo di aggiornare i componenti che uso in ufficio e ho deciso di partire da GWT. Nel momento in cui scrivo l’ultima versione è la  2.8.2.  Mi piace GWT, mi piace l’idea di lavorare solo in java e xml e non dovermi preoccupare delle librerie javascript, durante la generazione del war sarà GWT a trasformare le classi java in unico file javascript che sarà incluso all’interno del mio progetto.

Andiamo sul sito http://www.gwtproject.org e partiamo dall’analisi dei requisiti di sistema. La nuova versione ha una dipendenza minima di JDK 1.8, Google ci avvisa che il sistema compila correttamente su JDK 1.7 ma che la modalità in devmode presenta malfunzioni.  L’IDE di riferimento è Eclipse, nel momento in cui scrivo sto usando la versione Oxygen. Su questa installiamo il GWT Eclipse plugin  e possiamo iniziare.

A questo punto avete 2 possibilità:

  1. usare il wizard che vi tira su il progetto con la sua alberatura e lo rende già eseguibile .
  2. Integrare maven, integrare il plugin disponibile e creare il nostro progetto a partire da un archetipo .

L’opzione 1 è quella più rapida, selezionando i dati di esempio,  ci permette di avere subito il progetto operativo e poterlo lanciare tramite una delle seguenti opzioni :

  1. GWT Development Mode (Avvia un server in ascolto delle richieste del client. Se tutto è ok vai all’indirizzo http://127.0.0.1:9876/ per vedere il server attivo. A questo punto occorre configurare un qualsiasi server per caricare il contesto web )
  2. GWT Development Mode with jetty (Avvia il code server ed un jetty server con il client attivo. A questo punto se tutto è ok accedete alla pagina http://127.0.0.1:8888/ e vedrete la home page dell’applicativo. Rispetto al punto precedente, abbiamo già il web server pronto.)
  3. GWT Legacy Development Mode with jetty (Avvia l’applicativo usando un processo OOHPM. Tale processo non è più supportato dai moderni browser. Infatti è possibile vederlo attivo solo su una vecchia versione di firefox su cui va installato il google web toolkit developer plugin).

Il plugin ha creato la directory war e 3 package per i sorgenti: client, server e shared. Ad ogni package corrisponde una visibilità ed un comportamento diverso. Tutti i sorgenti saranno compilati in .class sotto la WEB-INF, i sorgenti del package server sono visibile solo alla parte server del progetto e non al frontend, i sorgenti della parte client verranno trasformati in javascript, pertanto alcune classi non saranno disponibili perchè non supportate da Javascript (es. Calendar o String.format), i sorgenti del package shared saranno visibili sia al frontend che al backend.

Nota dolente di questo approccio è che il wizard fallisce qualora si chiede la creazione del progetto con struttura maven. Appena generato il progetto indica errori di compilazione e questo non è bello, visto che ha fatto tutto da solo.

Aprendo la console è possibile far partire il progetto usando la direttiva mvn war:exploded gwt:devmode, mentre in eclipse occorre configurare il progetto per correggere gli errori. Per correggere l’errore in Eclipse lanciate la direttiva mvn eclipse:eclipse e fate il refresh in Eclipse del progetto, in questo modo dovrete soltanto da aggiungere la dipendenza da GWT tramite IDE e tutto dovrebbe riattivarsi.

Adesso veniamo al punto 2, con Maven posso partire da un archetipo che mi mette a disposizione tutte le librerie che mi servono con minimo sforzo. Devo realizzare una webapp che esponga un front-end gwt e dei servizi rest per l’accesso alla base dati. Parto quindi dall’archetipo minimo previsto per gwt e a questo aggiungo spring web per la gestione dei servizi rest e restyGWT per integrarli in modo più rapido. Voglio rendere al minimo l’uso delle chiamate RPC. In questo modo potrò disaccoppiare i sistemi e un domani eventualmente sostituire GWT con un altro frontend, senza dover toccare il backend. Impostato il progetto lo facciamo partire con la direttiva e il gioco è fatto

Per riassumere trovate il pom del progetto con le dipendenze già pronte.

Buon divertimento

TERMINARE UN PROCESSO JAVA

Ultimamente mi capita di aver dei processi JAVA attivi e non vederli tra quelli indicati nel taskmanager. Mi capita con il plugin jetty che a seguito di errore risulta non attivo, ma in realtà mi ha lasciato un processo che blocca l’accesso alle risorse.

Per fortuna ci viene in soccorso il jps – Java Virtual Machine Process Status Tool che mi permette di sapere quanti processi java sono attivi e relativo PID per poterli chiudere con il comando taskkill.

Pertanto apriamo una shell e lanciamo il comando

jps -m

che mi restituirà l’elenco dei processi java attivi

984 DevMode -gen C:\Users\Valerio\eclipse-workspace-oxygen\gwtwebapp\target\.generated -war C:\Users\Valerio\eclipse-workspace-oxygen\gwtwebapp\target\gwtwebapp-1.0-SNAPSHOT -logLevel INFO -port 8888 -codeServerPort 9997 -startupUrl application.html -sourceLevel 1.8 it.valeriofinazzo.application
7876
2492 Launcher gwt:run
7308 Jps -m

A questo punto possiamo lanciare il comando taskkill /F /PID 984 e il sistema ci restituirà il messaggio

OPERAZIONE RIUSCITA: il processo con il PID 984 è stato terminato.

 

TUTORIAL GWT – DETERMINARE L’ANNO CORRENTE

In ambito GWT l’oggetto Calendar non è disponibile, pertanto non volendo usare il metodo deprecato getYear() dell’oggetto Date , è possibile ottenere l’anno corrente usando l’oggetto com.google.gwt.i18n.client.DateTimeFormat

 

TUTORIAL WORDPRESS – ATTIVARE/DISATTIVARE WIDGET

Nasce l’esigenza di attivare dei widget a seguito dell’autenticazione utente. Per questa esigenza ci viene in soccorso il plugin Widget Logic, disponibile al link  https://wordpress.org/plugins/widget-logic/.

Attivando il plugin  verrà attivata dentro ogni widget un campo per la logica aggiuntiva.

All’interno del campo testo sarà possibile tramite del codice stabilire la logica di visualizzazione

is_user_logged_in() –> il widget è visibile solo per utenti autenticati

!is_user_logged_in() –> il widget è visibile solo per utenti non autenticati

 

TUTORIAL WORDPRESS – CREARE PLUGIN PER API REST

Solitamente uso WordPress come CMS, lo trovo comodo e semplice da usare qualora non siano presenti particolare esigenze da parte del cliente.  Da poco tempo ho scoperto la presenza della APi Rest pienamente supportate dalla versione 4.7, il che fa si che WordPress possa essere utilizzato come backend per architetture a servizi di tipo REST. In breve WordPress permette di definire agevolmente endpoint in grado di ricevere e inviare oggetti di tipo JSON (JavaScript Object Notation). JSON è un formato leggero per l’interscambio di dati, più leggero dell’XML e ciò ha fatto che l’architettura REST con JSON si presenti come alternativa ad una architettura SOAP con XML. Per chi volesse maggiori dettagli su REST rimando ai ragazzi di HTML.IT

Nel mio caso l’esigenza è quella di realizzare un app android che acceda ai contenuti gestiti su una piattaforma WordPress e ne consenta la lettura e/o la modifica.

In questo articolo vedremo come realizzare un servizio REST. Per fare questo occorre realizzare un plugin wordpress, definire l’endpoint da gestire e la logica con cui gestire le chiamate ricevute.

Andiamo per ordine, per realizzare il plugin occorre caricare un file php nella cartella /wp-content/plugins. Tale file deve presentare una intestazione particolare, che consenta a WordPress di individuarlo e di consentire tramite la dashboard di attivarlo. Di seguito un esempio:

Se avete fatto correttamente, accedendo alla sezione plugin di WordPress trovere il plugin da attivare

Il plugin compare dopo aver caricato il file php contenente la sua definizione

A questo punto attiviamo il file ma non essendoci alcun endpoint definito non vedremo effetti. Per definire l’endpoint ci avvaliamo della direttiva add_action che consente di stabilire le regole di invocazione del servizio e la logica con cui restituire il dato

Il comando add action invoca la direttiva register_rest_route che stabilisce l’url da invocare, il metodo HTTP con cui invocare il servizio e la funzione da invocare). Nell’esempio fornito il plugin risponde alla chiamata GET del servizio  http://www.valeriofinazzo.it/wp-json/vfplugin/v1/posts/.

Il metodo cakllback prevede di chiamare la routine api_get_posts che recupera tutti gli articoli presenti nel sito serializzati in formato json

La serializzazione viene gestita in modo trasparente da WordPress. Pertanto il servizio è attivo e non è richiesto altro.

A seguire il codice completo

TUTORIAL PRESTASHOP – NASCONDERE LA CONDIZIONE DEL PRODOTTO

Da poco ho iniziato a usare questo prodotto per l’ecommerce. Sull’installazione non mi soffermo perchè è abbastanza intuitiva, oltretutto è già offerta dai siti di hosting come aruba. Mi soffermerò di più sugli aspetti di configurazione, che l’interfaccia di back-end non permette di gestire in modo naturale.

La prima cosa che ho dovuto fare è stata rimuovere la condizione del prodotto. L’interfaccia di back-end non consente di agire su questo oggetto. Navigando sul forum ho trovato varie soluzioni che prevedevano la modifica al template tpl del prodotto. Personalmente ho preferito agire sul css e nascondere l’oggetto al momento della presentazione.

Per fare questo dovete modificare il file css product.css e aggiungere in coda la definizione

 

A questo punto ricaricando la pagina di dettaglio del prodotto il campo condizione risulterà scomparso.

Se per qualche motivo non potete modificare il css o il vedere il tag nell’html urta la vostra sensibilità potete sempre commentare il sorgente del file product.tpl all’interno del vostro tema

 

Il comportamento è stato implementato e testato sulla versione 1.6, con il thema di defautl