Chrome, persistent authoring in devtools.

Chrome, persistent authoring in devtools.

di Pubblicato: 9 giugno 2015 7 commenti

Google Chrome ha un ottimo, forse il migliore, sistema di debug attualmente sul “mercato“. Partito con poche opzioni al suo debutto, oggi si può fare debug in modo piuttosto approfondito analizzando tutto quello che passa per il browser e che deve esso stesso deve interpretare. Una delle opzioni sicuramente più utilizzate è la modifica in anteprima delle classi CSS per cambiare l’aspetto di una pagina o di un elemento. Queste pseudo-modifiche hanno effetto visivo in tempo reale, ma sono tali fintanto che abbiamo aperto il debugger. Per cui una volta raggiunto il proprio scopo si deve salvare tutto all’interno del file “reale” presente sul proprio ambiente di sviluppo. Questa pratica di authoring, come la chiamano loro, non è molto efficiente perché appunto bisogna copiare le porzioni di codice che abbiamo modificato sul file “vero” e salvare.

Finché si tratta di un file CSS di un centinaio di righe non è un gran problema, ma quando questo diventa complesso ed articolato l’opzione di copia incolla dove tocca saltare da una parte all’altra del foglio di stile è il momento in cui si comincia a prestare il fianco ad errori.

Da qualche versione di Google Chrome è stato introdotto il “persistent authoring” che in qualche modo sorpassa quanto detto poco sopra, e permette di “agganciare” la visualizzazione di debug ad una mappatura su disco locale, o disco di rete, dove quello specifico file esiste realmente. Nella pratica le modifiche che effettueremo in modalità di debug saranno scritte direttamente sul file vero senza dover fare dei noiosi copy and paste.

Questa manovra prevede qualche passaggio. Prima di spiegare il tutto è bene rimarcare che si tratta di uno strumento adatto alle versioni di sviluppo di un sito web, come un classico LAMP ad esempio. Per cui non è adatto/consigliato a modifiche su un sito in produzione dove generalmente si deve effettuare una sessione SSH o FTP.

Partiamo con l’entrare in modalità di Debug, generalmente lo faccio con tasto destro sulla pagina e “Ispeziona Elemento“, oppure con la combo di tasti CTRL+SHIFT+I (CMD+OPT+I su osx). Una volta dentro nelle Tab in alto andate a cercare la voce “Sources“. Si vedrà sostanzialmente la struttura file del vostro sito web, o perlomeno la parte che è stata interessata/caricata. Nell’albero alla vostra sinistra potremo fare tasto destro in uno dei rami e scegliere “Add folder to workspace“. Si veda l’immagine sottostante.

chromedev-001

Possiamo benissimo indicare la cartella root del nostro WordPress che abbiamo sull’ambiente di sviluppo. Può essere fornita una cartella sul PC o una cartella di rete. Verrà chiesto, con un barra di notifica posta in alto, l’autorizzazione a poter scrivere (da parte del browser) sul nostro sistema. E’ una richiesta che si limita solo all’utilizzo della modalità di debug e può essere revocata in qualsiasi momento. A questo punto abbiamo indicato una posizione fisica al debugger.

Ora dobbiamo “mappare” la versione interpretata con quella presente nel workspace. In pratica scegliendo il file css, ma la cosa funziona anche per un file php, javascript o html, con il tasto destro andremo a scegliere la voce “Map to file system resource…“.

chromedev-002

Apparirà una finestra in popup con l’albero della Workspace locale. Sceglieremo tramite il cerca, o navigando, il file che vogliamo mappare ad esempio il foglio di stile. Verrà ricaricata la pagina e da questo momento in poi ogni modifica fatta, anche e sopratutto nella tab Elements, sarà automaticamente scritta nel file di sviluppo.

Inizialmente la cosa tende un po’ ad essere sconcertante, poiché di fatto non si preme mai nessun pulsante “Salva” poiché le modifiche sono in tempo reale. Questo può essere negativo ad esempio quando ci si rende conto che le modifiche che stavamo tentando non vanno e vogliamo tornare indietro. Ci viene in aiuto la modalità “Local modifications…” che vedete anche nella immagine precedente. Si aprirà nella parte bassa del debugger una vista che mostra tutti i file modificati, se più di uno, e la possibilità di ritornare alla versione originale (o parte di esso, infatti i revert possono anche solo interessare alcune modifiche). L’importante è non chiudere il debugger.

E’ anche possibile effettuare delle ricerche che coinvolgono tutti i file delle workspace. Nella sezione “search” in basso, oppure attraverso la combo CTRL+SHIFT+F (CMD+OPT-F su osx) apparirà la possibilità di cercare qualcosa, anche utilizzando espressioni regolari. Nel caso invece si voglia cercare all’interno del file corrente si utilizzerà la combo CTRL+O (CMD+O su osx).

La parte locale rimane persistente sul vostro browser, per cui una volta chiuso il debugger e riaperto continuerete a vedere la cartella locale. Per fare in modo di cancellarla potete scegliere con il solito tasto destro la voce “Remove folder from workspace“. Con questa manovra abbiamo anche revocato il diritto di scrittura di cui abbiamo accennato in precedenza.

Questa descritta è una parte, sebbene fondamentale, delle funzioni di Persistent Authoring, ad esempio è possibile creare un nuovo file, escludere porzioni della cartella locale o salvare i file in nuovi con nome differente. Sicuramente Google aggiungerà moltissime opzioni in futuro, se non addirittura arrivare ad una funzione di IDE o Editor vera e propria.

Non ci sono commenti al momento

sezione commenti aperta al pubblico
  1. Antonio
    #1 Antonio 8 marzo, 2016, 11:12

    Salve,
    articolo molto interessante. Ma si può anche collegare un file .css esterno (es. custom-locale.css)? Oppure devo lavorare sui css già esistenti del sito.

    Creo siti su WordPress, acquistando e personalizzando i temi, quindi preferirei collegare un css esterno che lavorare su quelli già presenti nel tema.

    Grazie
    Antonio

    Rispondi a questo commento
    • Walter Tosolini
      Walter Tosolini Autore 8 marzo, 2016, 12:15

      Si è possibile, in teoria i temi WP che sono un po’ strutturati hanno dei “ganci” per tirare su css multipli. Ma se vuoi agganciare un css nuovo, dovrebbe essere sufficiente mettere in cima alla css principale, dopo i commenti:

      @import url(“nuovo.css”);

      dove nuovo.css sarà il file css che andrai a gestire con il persistent authoring di chrome.

      Rispondi a questo commento
      • Antonio
        Antonio 22 marzo, 2016, 19:26

        Ciao Walter,
        grazie mille per la risposta. Quindi diciamo che il processo dovrebbe essere:
        – creo un nuovo file css che carico ad esempio dentro la cartella del tema presente sull’hosting
        – lo @importo dal css originale
        – ricarico il sito e, con i Dev Tool mappo e collego la risorsa

        E da lì in poi le modifiche che applico in locale dovrebbero rimanere permanenti (fino ovviamente a fine modifiche, quando dovrò sostituire il css online con quello che ho in locale).

        Grazie intanto per la risposta, pubblicherò il risultato dell’esperimento su questo post 🙂
        Ciao
        Antonio

        Rispondi a questo commento
        • Walter Tosolini
          Walter Tosolini Autore 22 marzo, 2016, 20:17

          Si Antonio, direi che la procedura è corretta. Dopo l’import verifica sempre con il debug di chrome che il file sia caricato almeno la prima volta, giusto per avere un responso sul fatto che il css sia concatenato a quello originale.

          Rispondi a questo commento
          • Antonio
            Antonio 23 marzo, 2016, 16:55

            Ciao Walter,
            mi viene spontanea una dubbio: se posso mappare un css che ho caricato io, dovrei poter mappare anche il file style.css già presente sul server. Per fare questo, ho provato la seguente:
            – scarico il file style.css e lo inserisco nella cartella del Workspace
            – mappo il file style.css del tema (che nel mio caso ha il formato style.css?ver=[numeroversione]) al file in locale (quindi usando “Map to filesystem resource”)

            Da questo momento il file locale dovrebbe essere quello di riferimento. Il problema è che non è così

            Potrebbe essere che quel ?ver=[numeroversione] crei problemi?

            Ciao e grazie
            Antonio

            Rispondi a questo commento
            • Antonio
              Antonio 23 marzo, 2016, 17:09

              Aggiornamento: ho effettuato ulteriori test, la procedura per collegare correttamente lo style.css ad un file locale è la seguente:
              – Aprire Dev Tools
              – clic destro su style.css nel pannello Sources e cliccare “Map to file system resource”
              – selezionare il file locale (es. css-custom.css)
              – nella stessa finestra di style.css, cliccare su CTRL+S. Adesso il file locale css-custom.css ha lo stesso contenuto del file style.css

              Da ora in poi ogni volta che si modifica in Dev Tools il foglio style.css, queste modifiche vengono salvate su css-custom.css

              L’unico problema che rimane (e questo potrebbe essere legato alla questione del ?ver) è che se ricarico il sito, la mappatura decade e il file css di riferimento rimane quello in remoto.

              Rispondi a questo commento
              • Walter Tosolini
                Walter Tosolini Autore 23 marzo, 2016, 19:17

                No la versione del css è relativa, anche perché è quella indicata all’interno del file medesimo, quindi non è cambia. Non ho ben compreso il senso del passaggio da css-custom a style. Ad ogni modo il fatto che la mappatura ti decada mi da da pensare che stiamo parlando di un server remoto e non un ambiente di sviluppo sul tuo computer. E’ corretto? In questo caso se il computer con cui operi sei su windows e non su linux la vedo dura. O almeno a me non viene in mente una idea che non sia al contempo deleteria in materia di sicurezza per il server remoto.

Rispondi