Quando si vuole sviluppare un’applicazione desktop la prima cosa a cui si pensa è per quale sistema operativo svilupparla, quale linguaggio usare ed opzionalmente a quale base dati si ha bisogno di connettersi.

Il mondo dell’informatica intanto si sta evolvendo verso l’utilizzo di applicazioni web per la loro semplicità di distribuzione e aggiornamento, la compatibilità con ogni sistema operativo e la superfluità di un’installazione, allora perché non sfruttare questa tecnologia? Vengo ora a proporre un compromesso valido, 

Dal sito ufficiale electron.atom.io, il suo slogan è 

“Build cross platform desktop apps with JavaScript, HTML, and CSS”

Electron è una libreria open source sviluppata dal team di GitHub che permette di sviluppare un’applicazione desktop utilizzando le stesse tecnologie di un sito web unendo la potenza del browser 

 e il più grande ecosistema di librerie open source al mondo: 

. In aggiunta a tutto questo la possibilità di pacchettizzare l’applicazione per Mac, Windows, e Linux con lo stesso risultato in termini di grafica e funzionalità.

Andiamo subito alla pratica per vedere come funziona

Innanzitutto partiamo da una cartella di progetto vuota, creiamo il file package.json come indicato qui:

{
  "name"    : "app-name",
  "version" : "0.1.0",
  "main"    : "main.js"
}

Andiamo ora a creare il file main.js, script che verrà eseguito da Electron, chiamato 

, in grado di creare l'interfaccia grafica della pagina web, che sarà quindi così composto:

// Caricamento delle librerie Node.js
const {app,BrowserWindow} = require('electron')
const path = require('path')
const url = require('url')

// Mantiene la referenza globale dell'oggetto window, in caso contrario
// la finestra verrà chiusa automaticamente quando l'oggetto JavaScript
// verrà deallocato dal garbage collector.
let win

function createWindow() {
    // Creazione della GUI, non ancora visibile
    win = new BrowserWindow({
        width: 800,
        height: 600,
        show: false
    })

    // Indichiamo quale file HTML deve essere renderizzato
    win.loadURL(url.format({
        pathname: path.join(__dirname, "index.html"),
        protocol: "file:",
        slashes: true
    }))

    // Quando la GUI è pronta allora mostriamo la finestra
    win.once("ready-to-show", () =&gt; {
        win.show();
    })

    // Evento di chiusura dell'applicazione
    win.on("closed", () =&gt; {
        // Deferenziamo l'oggetto window
        win = null
    })
}

// Questo evento viene scatenato quanto Electron ha terminato il caricamento,
// alcune API possono essere chiamate ad inizializzazione avvenuta
app.on("ready", createWindow)

// Evento scatenato alla chiusura di tutte le finestre
app.on("window-all-closed", () =&gt; {
    // Su macOS le applicazioni e la loro barra dei menu rimangono attive
    // finché l'utente non forza la chiusara con Cmd + Q
    if (process.platform !== "darwin") {
        app.quit()
    }
})

// Su macOS è una pratica comune ricreare la finestra quando
// viene cliccata l'icona sulla dock e non ci sono altre finestre aperte
app.on("activate", () =&gt; {
    if (win === null) {
        createWindow()
    }
})

<!DOCTYPE html>
<html>
  <head>
      <meta charset="UTF-8">
      <title>Applicazione di test</title>
  </head>
  <body>
    <h1>Hello World!</h1>
  </body>
</html>

Ecco fatto, adesso vogliamo vedere il risultato. Dobbiamo ora installare il pacchetto npm 

, dunque installiamolo globalmente con il comando:

Al termine dell'installazione eseguiamo electron all'interno della cartella del nostro progetto usando il comando:

Aggiungiamo ora qualche modifica per facilitare lo sviluppo e prendere confidenza con la le API di Electron. Aggiungiamo all'interno del metodo 

...
    // Disabilitiamo l'antiestetica barra dei menu
    win.setMenu(null);

    // Aggiungiamo alcune scorciatoie da tastiera per
    // aprire gli strumenti di sviluppo e ricaricare la GUI

    var globalShortcut = require("electron").globalShortcut;

    globalShortcut.register("CommandOrControl+D", () =&gt; {
    	win.webContents.openDevTools();
    })
    globalShortcut.register("CommandOrControl+R", () =&gt; {
    	win.webContents.reload();
    })
...


e rilanciamo l'applicazione, adesso sarà possibile aprire i DevTools di Chromium per eseguire il debug e ispezionare l'HTML con la combinazione specificata 

Adesso la domanda che sorge spontanea è 

"ok, è un sito web offline, ma ne passa di acqua sotto i ponti prima che diventi un'applicazione vera e propria"

 ed è proprio qui che entra in gioco Node.js.

Lo scope del javascript all'interno dell'HTML è fuso insieme a quello di Node.js, separato da quello del main process, ma è pur sempre Node.js. Aggiungiamo una funzionalità che un sito web non potrà mai avere: 

. Ovviamente senza che l'utente lo abbia scelto da un input di tipo file.

Aggiungiamo un file nella cartella del progetto chiamato test.txt con un contenuto di esempio come alcune righe di Lorem Ipsum e aggiungiamo un file javascript /js/load-file-content.js con l'operatività per mostrare il contenuto:

// Caricamento delle librerie Node.js
const fs = require('fs');
const path = require('path');

// Lettura del contenuto del file
fs.readFile(path.join(__dirname, 'test.txt'), 'UTF-8', (err, data) =&gt; {
    if (err){
        throw err;
    }else{
        // Visualiziamo il contenuto del file
        var el = document.getElementById('file-content');
        el.innerHTML = data;
    }
});

Includiamo il file all'interno del index.html e aggiungiamo l'elemento html dove mostrare il contenuto

...
<body>
    <h1>Hello World!</h1>

    <p id="file-content"></p>

    <script src="./js/load-file-content.js"></script>
</body>
...

Il risultato sarà la visualizzazione del contenuto del file:

Non ci sono limiti alle funzionalità che può avere la nostra applicazione, npm ha infinite librerie per fare praticamente qualunque cosa che un'applicazione desktop classica può fare, forse anche qualcosa in più. Vogliamo connetterci ad una base dati? ci sono centinaia di librerie Node.js, tra tutte Sequelize per PostgreSQL, MySQL, MariaDB, SQLite e MSSQL oppure Mongoose per MongoDB e tantissime altre.

In oltre Electron espone un'enorme quantità di API per le funzionalità più comuni delle applicazioni desktop, che potente trovare nella sua documentazione 

http://electron.atom.io/docs/tutorial/desktop-environment-integration/

 (Windows, Mac, Ubuntu) e tantissime altre.

Electron ci aiuta nello sviluppo aggiungendo alcune funzionalità come una gestione del Menu dell'applicazione, Localizzazione, Clipboard, un sistema per aggiornamenti automatici OTA e come abbiamo visto prima shortcuts da tastiera.

Per poter distribuire l'applicazione bisogna crearne un pacchetto, utilizziamo uno strumento da linea di comando electron-packager. Installiamo globalmente il pacchetto npm:

electron-packager <sourcedir> <appname> --platform=<platform> --arch=<arch> [optional flags...]

Per ulteriori informazioni sullo strumento seguire la documentazione relativa. Per rendere più semplice la fase di build consiglio l'utilizzo di grunt-electron che utilizza gli stessi parametri mappati con Grunt task runner.

Inoltre c'è la possibilità di creare un setup di installazione per Windows tramite il pacchetto electron-installer-windows e creare un pacchetto installante deb electron-installer-debian o rpm electron-installer-redhat per sistemi Linux.

La sicurezza del codice? Non si può compilare un sito web

Se trovate una soluzione per fare in modo che il software non venga copiato o ri distribuito  fatelo sapere ad Adobe, Microsoft e Autodesk, neanche loro hanno trovato una soluzione definitiva.

Nonostante questo si può sempre eseguire una procedura di uglify sul codice javascript e impacchettamento delle risorse con asar in modo da rendere il processo di reverse engineering il più complesso possibile. 

Sul sito web di Electron sono mostrate alcune delle applicazioni che attualmente usano questa tecnologia, tra queste spicca sicuramente Atom l'IDE di sviluppo per web developer, Insomnia un client per testare API insieme a Postman, GitKraken un GUI per per GIT, Slack famosissimo client di messaggistica real-time, WordPress.com pannello di amministrazione per siti WordPress, VisualStudioCode IDE di sviluppo, Kitematic GUI per gestione container docker e centinaia di altre applicazioni.

In conclusione Electron è un framework completo a potente tenuto costantemente aggiornato con release mensili e a volte settimanali in caso di fix di problemi, i suoi componenti Chromium e Node.js sono affidabili ed usati nelle loro versioni stabili.

Ci sono diverse progetti che cercano di portare tecnologie web ad avere le funzionalità desktop.

Chrome, il celeberrimo browser di Google, utilizza una tecnologia molto simile per lo sviluppo delle sue App, come si può notare dalla documentazione developer.chrome.com/apps/first_app molti aspetti sono simili, un 

chrome.app.runtime.onLaunched.addListener(function() {
    chrome.app.window.create('window.html', {
        'outerBounds': {
            'width': 400,
            'height': 500
        }
    });
});

e un file html per creare la GUI, ma senza un'integrazione con Node.js.

È d'obbligo citare NW.js, aka node-webkit, un framework molto simile ma più asciutto nelle funzionalità. Molto interessante è la compatibilità con le Applicazioni Chrome.

Non si può non aprire una parentesi su Firefox OS, il sistema operativo sviluppato da Mozilla per dispositivi mobili utilizzando tecnologie web.

Non solo desktop, sono nati molti framework per applicazioni mobile basate su tecnologie web, il più famoso è 

, uno dei progetti più imponenti in questo campo. Quest’ultimo ha sviluppato un IDE (oramai dismessa) chiamata 

, indovinate un po’? Basata su Electron!

, una soluzione enterprise con strumenti di test, analytics, API per connettersi a svariate sorgenti dati  e molto altro.

Personalmente ho usato Electron in un paio di progetti e ne sono rimasto molto soddisfatto, l'unico consiglio che sento di dover dare e di cercare di utilizzare dei framework javascript per lo sviluppo di applicazioni Electron per tenere una certa organizzazione: AngularJS, Backbone.js o Ember sono tutte validissime soluzioni.

Electron – Una nuova era per le applicazioni desktop

Magento 2 ha introdotto tantissimi cambiamenti nella vita di noi sviluppatori Magento, primo fra tutti la quasi obbligatorietà di interfacciarsi con task runner, gestore di pacchetti, compilazione degli assets statici, ambienti diversificati (sviluppo, produzione).

Abbiamo già visto in diversi articoli come è possibile replicare alcune di queste caratteristiche anche su Magento 1.

In questo articolo vedremo come poter gestire gli assets statici diversificandoli in base all’ambiente di sviluppo,  e nel prossimo articolo, in base al tema/sottotema nel caso di template adaptive.

La procedura richiede l’utilizzo di task runner e nello specifico in questo articolo verrà trattato Gulp. Ciò non toglie che la stessa procedura sia tranquillamente replicabile anche su altri task runner come Grunt.

Immaginiamo di dover gestire un importante ecommerce con un tema custom e che il workflow imposto sia diviso su tre livelli:

Ogni ambiente ha delle particolari necessità: prod dovrebbe avere gli assets statici unificati e minificati; dev dovrebbe averli separati e usando ad esempio LESS, anche una sourcemap per agevolare il lavoro di debugging e sviluppo; test potrebbe invece avere l’esigenza di passare da una modalità ad un’altra, sia per il debugging che per il test sulla corretta unificazione dei file (in particolare js che creano spesso dei problemi).

Modificare le impostazioni del proprio task runner per cambiare le modalità di generazione degli assets potrebbe essere alla lunga piuttosto oneroso in termini di tempo con rilasci abbastanza frequenti e espone comunque gli ambienti al rischio di possedere un’errata configurazione degli assets statici (es. su prod potrebbero finire css e js non minificati/unificati o in remoto potrebbero finire gli script di livereload e/o browsersync, generando errori per la mancanza del servizio).

Per ovviare a questi problemi abbiamo testato e provato diverse modalità. Quella che maggiormente riduce la possibilità di errore è quella di creare molteplici file statici in modalità differenti.

Generazione di file statici diversificati

Per ottenere diversi file dal medesimo sorgente è possibile modificare il proprio gulpfile.js creando le configurazioni e duplicando il task.

Supponendo di avere per ora solo due livelli. dev e prod partendo da un unico task e config:

Create il nuovo file less che il task userà per generare il file less. Essendo una copia di style.less, dovrebbe contenere solo:

Ovviamente se dovesse servirvi qualche stile su dev per delle particolari casistiche, potete includerlo nel file creato.

Aggiungete ora il nuovo task creata anche nel task default e in altri task utilizzate (es. gulp watch) per poter così generare due file distinti:

Per quanto riguarda invece i javascript, la procedura cambia.

possiamo creare più variabili per racchiudere i js in ambiti diversi:


var scripts = {
'bower_components/jquery/dist/jquery.js',
'bower_components/bootstrap/js/transition.js',
'bower_components/bootstrap/js/collapse.js',
'bower_components/bootstrap/js/carousel.js',
'src/js/script.js'
}
var scripts-dev = {
'src/js/browsersync.js',
'src/js/livereload.js'
}


gulp.task('js', function() {

var stream = gulp

.src(scripts)

.pipe(concat('scripts.js'));

if ( bitbullConfig.uglifyJS == true) {  // Uglify function

stream.pipe(uglify());

}

return stream;

.pipe(gulp.dest('js'))

.pipe(notify({ message: 'Successfully compiled JavaScript' }));

});

gulp.task('js-dev', function() {

var scripts = scripts.concat(eval(scripts-dev));

var stream = gulp

.src(scripts)

.pipe(concat('scripts-dev.js'));

if ( bitbullConfig.uglifyJS-dev == true) {  // Uglify function

stream.pipe(uglify());

}

return stream;

.pipe(gulp.dest('js'))

.pipe(notify({ message: 'Successfully compiled JavaScript' }));

});


Ora che abbiamo i nostri file diversificati, rimane il problema di dover assegnare i file ad ogni ambiente, cioè far sì che Magento sappia quali file caricare per ogni ambiente.

Per dare le giuste condizioni, abbiamo pensato di utilizzare un piccolo modulo che aggiunge una nuova configurazione alla tab sviluppatore e usare questa stessa configurazione come condizione nel layout xml del nostro tema.

app/code/local/Bitbull/Theme/etc/config.xml

<sections>
   <groups>
      <envcontrol translate="label">
         <label>Env Config</label>
         <frontend_type>text</frontend_type>
         <sort_order>200</sort_order>
         <show_in_default>1</show_in_default>
         <show_in_website>1</show_in_website>
         <show_in_store>1</show_in_store>
         <fields>
            <active translate="label,comment"></active>
            <label>Active Assets for Dev Env.</label>
            <comment><![CDATA[Use the development version of js and css]]>;</comment>;
            
            <frontend_type>select</frontend_type>
            
            <source_model>adminhtml/system_config_source_yesno</source_model>
            
            <sort_order>10</sort_order>
            
            <show_in_default>1</show_in_default>
            
            <show_in_website>0</show_in_website>
            
            <show_in_store>0</show_in_store>
         </fields>
      </envcontrol>
   </groups>
</sections>

E il file di dichiarazione del modulo in app/etc/modules:

<config>
   <modules>
      <Bitbull_Theme>
         <active>true</active>
         <codePool>local</codePool>
      </Bitbull_Theme>
   </modules>
</config>

Una volta fatto si dovrebbe ottenere la tendina di configurazione con valore booleano dell’ambiente di sviluppo (visibile in Sistema -> Configurazione -> Developer).

A questo punto è possibile usare questa condizione per attivare/disattivare gli stili e gli script di sviluppo; aprite il file xml del tema e usate la condizione per rimuovere gli stili standard e aggiungere quelli dev:


<action ifconfig="dev/envcontrol/active" method="removeItem"><type>skin_css</type><name>css/style.css</name><params/></action>

<action ifconfig="dev/envcontrol/active" method="removeItem"><type>skin_js</type><name>js/scripst.js</name><params/></action>

<action ifconfig="dev/envcontrol/active" method="addItem"><type>skin_css</type><name>css/style-dev.css</name></action>

<action ifconfig="dev/envcontrol/active" method="addItem"><type>skin_js</type><name>js/scripts-dev.js</name></action>


Usando questo semplice stratagemma è possibile quindi switchare i file statici passando dai file standard (destinati all’ambiente di prod) a quelli “-dev” destinati all’ambiente di sviluppo.

La procedura che ho descritto è un esempio molto banale e semplificato di quello che è possibile fare con questo approccio. Modificando opportunamente il gulpfile è possibile migliorare il codice per renderlo più compatto (evitando duplicazioni massicce del codice ma centralizzando le funzioni), inserire nuovi ambienti e casistiche, prevedere opzioni aggiuntive ecc..

Nel prossimo articolo vedremo come usare questo approccio per creare dei temi adaptive seguendo un metodo simile a quello di Magento 2 (anche se molto più semplice) senza necessariamente creare eccessivi override e/o doppioni da mantenere e gestire.

Gestire gli assets statici con multipli ambienti con Magento 1

Giovedì e venerdì della settimana scorsa il reparto frontend di Bitbull si è allontanato dalle tastiere per partecipare al From the Front 2016, uno dei più importanti eventi nazionali dedicati al mondo del frontend development.

The frontend guide to life, the universe, and everything”

, ispirato al libro e film The Hitchhiker’s Guide to the Galaxy (non sono mancati maglietta e stickers a tema) e si è svolta nella splendida location degli anni precedenti, il teatro Duse di Bologna.

Si sono alternati sul palco alcuni tra i 

migliori frontend dev e ux designer a livello internazionale

 che, forse complici anche le luci, il palco e le poltrone rosse del teatro, sono riusciti a rendere emozionanti argomenti tecnici.

Gli argomenti trattati sono stati molti, alcuni più strettamente frontend, altri più vicini al design, ma costante tra tutti i talk è stato il taglio più improntato a 

 piuttosto che una soluzione tecnica preconfezionata.

Tra i talk più tecnici è stato sicuramente molto apprezzato quello di Mark Robbins, che ha lasciato tutti a bocca aperta con “Modern CSS and interactive email”, in cui ci ha mostrato come sviluppare email interattive: mini giochi, una scheda prodotto di un capo di abbigliamento con selezione di taglie e colori. Addirittura le stesse slide della presentazione erano state fatte con solo html e css, sfruttando principalmente 

! ;  Meno spettacolare ma non meno interessante il talk di Hugo Giraudel sui 

un sistema per rendere lo scope delle dichiarazioni css locali anziché globali, che insieme al talk di Varya Stepanova “Doing nothing for visual regression testing”  (quello che ci ha raccontato è 

 ) ci siamo promessi di studiare una volta tornati a casa.

 e ci hanno raccontato del loro passato e delle scelte che li hanno portati a diventare quello che sono: Marc Thiele organizzatore del 

  ha parlato del cambiamento, Lyza Danger Gardner con “Everyone Else is So Clever” di come non essere sopraffatti dagli alti e bassi che si possono incontrare nella vita lavorativa, e Beth Dean con “Emotional intelligence in design”, attraverso la sua esperienza personale, ci ha ricordato la responsabilità etica e politica dei designer.

Si è parlato anche di molto altro: dall’accessibilità, ai dettagli di http/2, alla 

 e di argomenti più vicini al mondo del design e alla user experience, tra cui, molto affascinante, l’intervento di Ben Sauer "

" sul futuro delle interfacce vocali e su come cambierà il ruolo dei designer con la loro diffusione.

A conti  fatti sono stati due giorni intensi ed è stato bello esserci non solo per gli spunti e gli approfondimenti, ma anche per l’energia positiva e l’entusiasmo che a volte si trovano in questi eventi e che aiutano a ricordare come mai ci piace questo lavoro, nonostante le difficoltà quotidiane.

Purtroppo gli organizzatori hanno concluso l’evento dichiarando che questa edizione del From the Front è stata l’ultima, non possiamo che augurarci che ci ripensino oppure che qualcuno raccolga il testimone!

From the Front 2016

Nonostante l’approccio nello sviluppo frontend delle email non sia ancora cambiato a distanza di anni, Magento 2 ha introdotto alcune tecnologie “recenti” nella gestione del frontend delle sue email transazionali.

In questo articolo vedremo le tecnologie e le scelte adottate da Magento2 per lo sviluppo delle email, analizzandone pregi e difetti.

Le email di Magento 2 (per numero e tipologia) sono rimaste pressochè le stesse di Magento 1, sebbene siano state distribuite seguendo la nuova struttura del frontend.

Ecco una panoramica generale dei template email su Magento 2:

E i template di alcuni blocchi interni usati nei template:

Per personalizzare un template email si può procedere in due modi: azione diretta sui file del template o modifica dal pannello backend di Magento.

Dal backend, analogamente a Magento1 è possibile caricare il template standard e personalizzarlo salvando le modifiche all’interno del database di Magento.

Il tool per la modifica delle email da backend è raggiungibile dal menu principale alla voce 

Per personalizzare un template email direttamente lato tema si segue la normale procedura di personalizzazione del tema:

Ipotizzando di personalizzare il template email della email per il nuovo ordine:

vendor/magento/module-sales/view/frontend/email/order-new.html

lo si copia semplicemente sul nuovo tema rispettando la struttura indicata nella documentazione ufficiale:

vendor/[nome_vendor]/[nome_tema]/Magento_Sales/email/order-new.html

La grande novità di questa nuova versione delle email è la rielaborazione degli stili nelle email transazionali. Se in Magento 1 avevamo un template molto standard e minimale con pochi stili inline che definivano più che altro sfondi e bordi per ogni template, in Magento 2 abbiamo la possibilità di definire degli stili specifici per ogni singolo elemento.

Chi ha lavorato con i template delle email saprà che lo sviluppo di queste, necessita di “tornare indietro” nelle modalità di sviluppo di almeno 20 anni. Ogni client e webclient infatti ha regole sue nell’interpretazione degli stili e dell’html: a partire dagli standard html e css che non vengono minimamente presi in considerazione a tag e stili css che vengono letti / interpretati / ignorati a seconda del client. Persino la lettura degli stili (o in un file .css, o nel documento all’interno dei tag style o direttamente inline nell’elemento) cambia da client a client.

Fatta questa premessa è facile intuire che lo sviluppo di email complesse e personalizzate è per lo sviluppatore frontend un vero calvario.

Magento 2 cerca di superare questa problematica integrando gli stili in modalità differenti ma usando gli stessi sorgenti.

Vediamo ad esempio il template header delle email di Magento2:

Come è possibile notare Magento 2 richiama due file CSS principali e utilizza tre tag in tutto:

Il primo tag consiste in una variabile che restituisce dei valori provenienti dal campo Template Styles se si personalizza il template email lato backend e da qualsiasi stile presente nel documento inserito all’interno di un blocco commentato. Es:

<!-@styles

.esempio { background: #f00; }
  
@->

Il secondo tag “css” restituisce un file CSS generato a partire dal file LESS omonimo presente in vendor/[nome_vendor]/[nome_tema]/web/css/.

Questo file LESS contiene al suo interno degli import che includono altri file LESS:

Riferimenti più specifici sull’utilizzo dei vari file less e delle variabili e mixins interni si possono trovare all’interno dei file sorgenti tramite appositi commenti e sulla documentazione ufficiale:

http://devdocs.magento.com/guides/v2.0/frontend-dev-guide/templates/template-email.html

Notare la presenza dei file _lib.less, _theme.less e _variables.less che vengono richiamati anche nella generazione dei file css del tema principale.

Il terzo tag “inlinecss” richiama un altro file css generato a partire dal file less omonimo:

vendor/[nome_vendor]/[nome_tema]/web/css/email-inline.less.

In questo caso i file LESS associati sono gli stessi del file email.less tranne per l’ultimo _responsive.less.

Il file CSS specificato nel tag inlinecss non viene però restituito direttamente sul documento: come lascia intendere il nome stesso, il tag racchiude le regole che andranno applicate inline sui tag html grazie ad uno script di terze parti chiamato 

Emogrifier si occupa di interpretare la porzione di codice CSS specificato con inlinecss e applica a ogni tag del documento lo stile inline risultante dalla lettura e interpretazione del codice, calcolando automaticamente il valore risultante dalla cascata degli stili incontrati.

Supponendo di avere una porzione di codice html di questo tipo:

<div class="container">

<div class="container inner-container">

<h1>Title<h1>

<p>Lorem ipsum</p>

</div>

</div>

div { border:1px solid red; }

.container { border: 1px solid blue; }

div.inner-container { border: 1px solid black; }

h1 { font-size:36px; text-transform: uppercase; }


L’output dell’HTML dopo l’intervento di emogrifier diventa:

<div class="container" style="border:1px solid blue;">

<div class="container inner-container" style="border:1px solid black">

<h1 style="font-size:36px; text-transform: uppercase;">Title<h1>

<p>Lorem ipsum</p>

</div>

</div>

Emogrifier legge e applica la maggior parte dei selettori e degli attributi ad eccezione dei pseudo elementi e dei selettori globali. Il resto dipende ovviamente dalle compatibilità specifiche dei vari client per determinati stili.

Sebbene questo nuovo approccio faciliti enormemente il lavoro dello sviluppatore frontend per la compatibilità cross-browser, l’organizzazione di base dei file less lascia un po’ perplessi. Ereditare tutti i less e le variabili del tema principale può creare qualche scompiglio nella visualizzazione delle email. Probabilmente questa soluzione è stata pensata nell’ottica di avere un unico “frontend” e un’unica UI comune per l’intero progetto. Se nella teoria tale condivisione potrebbe risultare vantaggiosa, nella pratica e nella nostra realtà quotidiana questo non accade spesso e ciò rende necessario dover riscrivere parte della struttura e degli stili delle email per separarla dal frontend del sito.

Un’altra problematica molto importante riguarda l’utilizzo di LESS in combinazione con Emogrifier. Ereditando diversi file less dal tema principale oltre a quelli direttamente specificati per le email, il numero totale di file coinvolti potrebbe superare tranquillamente la decina.

Questo rende piuttosto difficile poter sovrascrivere degli stili esistenti o capire come certe regole vengano applicate sugli elementi: trattandosi di stili letti e interpretati dalla libreria Emogrifier e dal client di posta, risulta molto più complesso poter debuggare utilizzando una console di sviluppo cui siamo ormai abituati usare. Sebbene sia comunque possibile, ottenere un file css con un sourcemap, il salvataggio continuo delle email in arrivo e la lettura di queste con una console non può che rendere questo approccio eccessivamente oneroso in termini di tempo rispetto al metodo tradizionale.

Con queste premesse è probabilmente più comodo escludere dal codice l’ereditarietà dei file less del tema, nonostante l’idea di Magento sia quella di obbligare gli sviluppatori a mantenere una uniformità tra email e frontend. Partendo da uno stesso foglio di stile non si può pensare che browser e client di posta interpretino il codice allo stesso modo, se questo è vero come sappiamo anche tra browser stessi, la differenza è decisamente evidente con i client di posta.

Probabilmente arriveremo ad un punto in cui questa differenza non sarà così netta e quindi Magento 2 sarà avvantaggiato, per ora si tratta comunque di una tecnica troppo “moderna” per un mondo così “antico”.

Lavorare con le email in Magento 2

 è un gestore di pacchetti per il web, che comprende, tra gli altri, librerie JS e CSS, come Composer lo è per PHP.

Se utilizziamo spesso librerie di terzi nei nostri progetti, che vengono rilasciate con nuove versioni periodicamente, è utile avere un gestore di pacchetti perché ci consente di tenere aggiornate le nostre librerie all’ultima versione oppure di tornare indietro a specifiche versioni. Inoltre è molto utile usato insieme ad un 

 come Grunt o Gulp perché è possibile specificare tutte le librerie dipendenti all’interno del file bower.json per il progetto in essere in modo che sia sufficiente questo file per allineare il progetto su vari computer.

Anche nell’ipotesi di utilizzare un sistema di controllo di versione, basterà mettere sotto versione il solo file bower.json che ha tutti i riferimenti alle librerie utilizzate che verrano tirate giù in locale tramite un comando specifico che vedremo di seguito.

Un po’ come Composer, si compone di due parti:

Le dipendenze sono appunto i pacchetti (librerie/framework js/css etc..) contenuti nel 

 che è possibile installare tramite gli appositi comandi Bower.

Vediamo ora come generare il bower.json ma prima assicuriamoci di aver installato Bower. Se avete già node.js installato (sennò 

 e va utilizzata la prima volta soltanto per installare Bower a livello globale sulla macchina in modo che il comando 

 sia poi disponibile ovunque nel sistema).

Fatto ciò, ovunque nel terminale digitando 

 dovremmo ottenere il numero di versione. Anche questo è bene ogni tanto aggiornarlo.

Ora siamo pronti per configurare Bower. Ci portiamo nella cartella del progetto (poi starà a voi scegliere in quale posizione è meglio collocare i file, ma mediamente si mette allo stesso livello del task runner e delle cartelle di output dei JS e CSS compilati per non dover digitare URL infinitamente lunghe o complicate come vedremo poi).

Per generare il file bower.json ci viene in aiuto un suo comando nativo (molto comodo):

Questo lancia la procedura di compilazione del file, ci verranno chieste un po’ di informazioni:

Per sapere cosa sono i moduli Javascript 

 che lo spiega molto bene, ma in buona sostanza significa scrivere codice riutilizzabile e distribuibile, dove ogni modulo è costituito da un gruppo di file che insieme implementano una specifica funzionalità. Quindi qui si tratta di definire quale “metodo di scrittura codice” verrà utilizzato.

"authors": [
  "Bitbull",
  "Bitbull &lt;info@bitbull.it&gt;",
  "Bitbull &lt;info@bitbull.it&gt;; (http://bitbull.it)"
]

Oppure si può scrivere anche in questo modo:

"authors": [
  { "name": "Bitbull" },
  { "name": "Bitbull", "email": "info@bitbull.it" },
  { "name": "Bitbull", "email": "info@bitbull.it", "homepage": "http://bitbull.it" }
]

L’intervista è finita. Bower ti propone ora la bozza di quanto generato sulla base delle tue risposte. Se è tutto corretto puoi confermare con Y.

Ecco un esempio di un bower.json completo:

A queste info è possibile aggiungere il riferimento al repository se presente:

"repository": {
  "type": "git",
  "url": "git://github.com/bitbull-team/bower-spiegato-ai-backend.git"
}

Ora si può passare all’installazione dei pacchetti che ci servono, prendiamo per esempio il classico jQuery.

Se conosciamo già il nome del repo possiamo installarlo direttamente altrimenti è possibile fare una ricerca direttamente da terminale con:

Ne verrà fuori una sfilza che non finisce più, normalmente quello corretto/ufficiale si trova in alto, ma verifichiamo sempre che il repo sia giusto:

jQuery https://github.com/jquery/jquery.git
jquery https://github.com/jquery/jquery-dist.git
jquery.x https://github.com/jljLabs/jquery.x.git
jquery.Q https://github.com/jsbuzz/jQuery_Q.git
jt_jquery https://github.com/vicanso/jt_jquery.git
jquery-m https://github.com/meetup/jquery.git
[..]

Installiamo perciò il primo ricordandoci di usare la dicitura 

 che ci assicura che venga inserito nelle dipendenze richieste in produzione:

Il nostro bower.json avrà in fondo ora un blocco in più:

con la specifica della nostra dipendenza e relativa versione installata. Per installare un componente in una specifica versione bisogna scrivere:

Possiamo continuare ad aggiungere dipendenze tramite riga di comando oppure se conosciamo già nome e versione elencarli direttamente in questo blocco:

"dependencies": {
  "jQuery": "^3.1.0",
  "bootstrap": "~3",
  "font-awesome": "~4"
}

I simboli ^ e ~ che precedono le versioni sono dei vincoli di versione e significano rispettivamente:

 per la scrittura del numero di versione che prevede sia MAJOR.MINOR.PATCH. Si possono poi usare anche 

Vi sono poi altri due modi di installare i componenti tramite riga di comando, una è quella di omettere il flag 

questo installerà normalmente la libreria nella cartella bower_components ma non aggiornerà il bower.json con questa dipendenza. È utile se si vuol testare un componente ma non si sa ancora se farà parte o meno del progetto.

 che installa il componente come dipendenza delegata al solo sviluppo:

Utile per installare componenti che servono soltanto durante la fase di sviluppo e che non devono andare in produzione. Un esempio fra tutti, gli script di unit test:

"devDependencies": {
  "jasmine-core": "jasmine#^2.4.1"
}

Qualora si volesse solo installare le dipendenze di produzione basterà aggiungere il flag 

Un altro modo per configurare tutti i componenti utili al progetto è di installare tutti i pacchetti necessari tramite 

 per la creazione del bower.json assicurandoci di rispondere Y alla domanda: 

set currently installed components as dependencies?

Come già detto, il bower.json è indispensabile ed è l’unico che va messo sotto versione (tralasciando quindi la cartella bower_components). Quando viene scaricato il repo del nostro progetto, basterà portarsi tramite terminale nella cartella contenente il bower.json e lanciare 

Bitbull

Frontend

Electron – Una nuova era per le applicazioni desktop

Gestire gli assets statici con multipli ambienti con Magento 1

From the Front 2016

Lavorare con le email in Magento 2

Bower spiegato ai back end developer

Scrolling infinito o paginazione per la lista prodotti?

L’importanza del miglioramento progressivo

Affrontare il problema del mouse-over sui device touch

Primi passi con lo sviluppo front end su Magento