Continuando con la compilazione del nostro sito Web statico, in questo tutorial definiremo la pagina dei dettagli per i post, incorporeremo il widget podcast e trascorriamo un po 'di tempo a mettere a punto la nostra lista di indici. Ci occuperemo anche delle duplicazioni di stile e dei collegamenti relativi.
Ci occuperemo di quanto segue:
Penso che dovremmo spostare la nostra attenzione e dare alla nostra pagina dei dettagli un po 'di amore di base prima di modificare l'app per visualizzare i nostri episodi di podcast. Non abbiamo completamente terminato la pagina dell'indice, se in questo tutorial avremo ancora un po 'di spazio, probabilmente aggiungerò un paio di media query per gestire risoluzioni dello schermo diverse. Per ora, direi, andiamo avanti. Qual è lo status quo?
Yikes, questo non sembra troppo bello! Il nostro testo è dappertutto. Risolviamolo per primo. È una buona idea attivare di nuovo la griglia visiva.
In "source / stylesheets / base / _grid-settings.scss":
$ griglia visiva: true;
Fatto ciò, dobbiamo creare un layout separato per le pagine di dettaglio dei nostri post. Il layout sarà flessibile in modo che possiamo utilizzarli per post di blog puri e per pubblicare anche episodi di podcast: una piccola dichiarazione condizionale ci aiuterà in questo. Ancora su questo più tardi però. Apriamo config.rb e aggiungiamo questa riga:
attiva: blog do | blog | blog.layout = fine "layouts / blog-layout"
Questo dirà a Middleman che abbiamo un layout separato per le pagine di dettaglio e che può essere trovato in "layout / layout del blog". Quindi dobbiamo creare "layouts / blog-layout.erb". Ricorda che il .erb è necessario senza l'estensione .html per farlo funzionare correttamente.
In "layouts / blog-layout.erb":
<% wrap_layout :layout do %><% end %> <%= current_article.title %>
<%= current_article.date.strftime('%b %e') %>
<% if current_page.data.soundcloud_id %><% end %> <%= current_article.body %>
Quindi parliamo di cosa sta succedendo qui. Prima di tutto, dobbiamo concludere questo blog-Layout
dentro il nostro generale disposizione
. Oppure, mettiamo in modo diverso, avvolgiamo il layout dell'applicazione attorno al layout del blog.
<% wrap_layout :layout do %>... <% end %>
Perché? Perché vogliamo riutilizzare molte cose dal layout originale e non duplicare cose come la footer
collegamento parziale o attivo in capo
. Dagli un minuto o due per affondare se ti sembra strano all'inizio. Il layout usato in precedenza era più di una cosa globale. Ora abbiamo bisogno di un po 'più di specificità per soddisfare i nostri bisogni.
Dentro il articolo
tag contenitore, costruiamo manualmente ciò di cui abbiamo bisogno per modellare il nostro post. Ha un titolo, una data, un widget incorporato SoundCloud opzionale e, naturalmente, il corpo dell'articolo stesso. All'interno dei nostri layout, abbiamo accesso a ogni individuo BlogArticle
. Possiamo usare current_article
per ottenere le informazioni per ogni articolo per creare il nostro modello personalizzato. titolo
, Data
e corpo
sono solo metodi per estrarre gli attributi dal singolo articolo. Abbiamo anche usato strftime
per formattare la data come abbiamo fatto in precedenza nella pagina dell'indice.
<%= current_article.title %> <%= current_article.date.strftime('%b %e') %> <%= current_article.body %>
Come già accennato, un semplice condizionale è responsabile della gestione dei dati forniti opzionalmente per ogni singolo post tramite il suo frontmatter, che è delimitato da tre trattini. Qui stiamo controllando se la pagina ha l'id di una traccia SoundCloud e per visualizzare il widget in questo caso:
<% if current_page.data.soundcloud_id %>... <% end %>
Nel caso in cui sia necessario un aggiornamento, otteniamo l'accesso ai dati tramite pagina corrente
oggetto e chiedi il suo dati
per il valore che abbiamo archiviato nel frontmatter tramite la sua chiave. Nel nostro esempio, la chiave di cui abbiamo bisogno è soundcloud_id
. Se il nostro modello trova questa chiave tramite il condizionale, visualizza il widget e interpola l'id SoundCloud per quella traccia per trovare quello giusto. Se è solo un semplice post sul blog, non è necessario fornire il soundcloud_id
nel frontmatter e il widget SoundCloud non verranno incorporati.
Ecco alcuni esempi di frontmaster per un post di podcast con un widget SoundCloud:
--- titolo: Il mio super stupendo undicesimo post dal titolo assed che irrompe in un'altra riga: 2015-11-30 22:14 UTC soundcloud_id: 138095821 tags: --- La tua fantastica descrizione dell'episodio podcast ... <%= lorem.sentences 10 %> - Domanda n. 01 - Domanda n. 02 ...
Quando fai clic su "condividi" su una qualsiasi delle tracce di SoundCloud, ottieni l'opzione per incorporare un iframe
per quella traccia e basta copiarlo incollarlo da qualche parte nel tuo codice. Usiamo questo iframe come base e usiamo l'id per la traccia che abbiamo bisogno di interpolarlo nell'URL. Ci sono due opzioni, un grande e un piccolo widget: ho scelto il grande. L'altro ha il vantaggio di essere un po 'più personalizzabile, ad esempio puoi regolare il colore del pulsante di riproduzione. Tocca a voi:
La magia avviene in questa parte:
... api.soundcloud.com/tracks/<%= current_page.data.soundcloud_id %>& AUTO_PLAY = ...
Dopo aver chiesto se questi dati ci sono disponibili tramite il condizionale, utilizziamo i dati di fronmatter per iniettare l'id per visualizzare la traccia che vogliamo. Diamo un altro sguardo su come sono andate le cose finora:
Ugh. Dal lato positivo, abbiamo tutta la struttura e i dati di cui abbiamo bisogno. E vedi, perché abbiamo annidato il blog-Layout
dentro il disposizione
layout, otteniamo il vantaggio di avere il footer già lì in fondo. Non c'è bisogno di duplicare le cose, bello! Con un po 'di stile, potremmo cambiare le cose e rendere questo aspetto un po' più decente.
In "source / stylesheets / all.sass":
@import 'posts_detail'
E poi nel parziale "source / stylesheets / _posts_detail.sass":
#main + outer-container article.article-detail + shift (2) + span-columns (8) .detail-post-title color: $ matcha-green font-size: 1.7em margin-top: 40px .detail-post -data font-size: 1.1em colore: $ text-color .article-detail p font-size: 1.05em margin-bottom: 4em colore: $ text-color line-height: 1.35em .soundclould-player-large margin- fondo: 50 px
Facciamo un altro picco veloce.
Bene, sta arrivando. Impegniamoci per ora, e facciamo alcune pulizie dopo:
git add --all git commit -m '1 ° tentativo nella pagina di dettaglio dei post con l'opzione podcast Aggiunge il layout del blog Regola la configurazione per il layout del blog Aggiunge gli stili per la pagina dei dettagli Aggiunge il Sass parziale Imports Sass partial Aggiornamenti del frontmatter del blog post'
L'avido lettore potrebbe aver già individuato ciò che dovremmo pulire in seguito. C'è un po 'di duplicazione in "_posts_detail.sass" e "_index_posts.sass". Mi piacerebbe estrarre gli stili duplicati in un file Sass separato chiamato "_blog_post_extractions.sass". Sto sperimentando questa tecnica ultimamente, un'idea che ho ottenuto da Object Oriented Programming. Cose come BEM o SMACSS possono essere grandiose, specialmente per progetti più grandi con team più grandi se si sono stabiliti per le seguenti convenzioni, ma per progetti più piccoli cerco sempre soluzioni semplici e prive di attrito. Farò un tentativo finché la prossima nuova brillantezza non mi convince di un approccio migliore.
In "source / stylesheets / all.sass":
@import 'bourbon' @import 'base / base' @import 'neat' @import 'blog_post_extractions' @import 'footer' @import 'index_posts' @import 'posts_detail'
Un in "source / stylesheets / _blog_post_extractions.sass":
#main, .posts + outer-container .posts p, .post-title, article.article-detail + shift (2) + span-columns (8) .post-title a, .detail-post-title color: $ matcha-green .post-title, .detail-post-title font-size: 1.7em .posts p, .article-detail p font-size: 1.05em line-height: 1.35em .posts p, .article-detail p , .detail-post-date, .post-date color: $ text-color .posts p, .article-detail p margin-bottom: 4em
Se si confronta il precedente con i file originali, è possibile vedere che ci siamo liberati di una bella porzione di duplicazione. È anche facile da capire e trovare perché importare tali file estratti in alto in "all.sass". È facile individuare queste estrazioni per le persone nuove al codice base. In questo caso, utilizzo questi file per raccogliere gli stili estratti che si applicano ai post del blog. Un approccio simile potrebbe funzionare per duplicazioni su diverse apparenze di barre laterali, dispositivi o simili - tuttavia, dovrebbe esserci un filo comune.
In "source / stylesheets / _index_posts.sass":
.post-titolo a + transizione (colore .4s easy-in-out) &: hover colore: $ text-color .post-date font-size: 0.7em margin: left: em (-80px) right: em (20px)
In "source / stylesheets / _posts_detail.sass":
.detail-post-title margin-top: 40px .detail-post-date font-size: 1.1em .soundclould-player-big margin-bottom: 50px
I file precedenti ora sono molto più piccoli, belli e ordinati, esattamente come mi piacciono. I file sono economici, quindi non mi interessa se ho molti di loro che fanno tutti il loro piccolo lavoro specifico. Una separazione di preoccupazioni. Non è una soluzione perfetta, ma è così semplice per le piccole cose che mi piace sperimentare di più con questo approccio.
Dovremmo anche commentare la nostra griglia visiva in "source / stylesheets / base / _grid-settings.scss" e vedere come appare:
È lo stesso di prima, ma con stili molto più puliti. Mi piace! Tempo per impegnarsi e per implementare le nostre modifiche:
git add --all git commit -m 'Estrae gli stili in _blog_post_extractions Estrae le duplicazioni da _index_posts.sass _posts_detail.sass Installa middleman degli stili di importazione
Andiamo alla nostra pagina GitHub Pages e controlliamo se tutto funziona come previsto. Oh caro. A prima vista sembra a posto, ma se proviamo ad andare alla pagina dei dettagli dall'indice, otteniamo a 404
messaggio di errore. GitHub non riesce a trovare ciò di cui abbiamo bisogno.
Se hai guardato da vicino, potresti aver visto che ci mancano alcune informazioni nel nostro url. Ora dice qualcosa come "http://your_username.github.io/2015/11/30/my-super-awesome-post.html". Quello che dovrebbe dire è qualcosa come "http://your_username.github.io/matcha-nerdz/2015/11/30/my-super-awesome-post.html". La parte "matcha-nerdz" era completamente mancante. Non ti preoccupare, questa è una soluzione semplice. Dobbiamo attivare i collegamenti relativi nel nostro file di configurazione:
set: relative_links, true
Avere collegamenti assoluti su GitHub Pages punterà nella direzione sbagliata. Con questa piccola modifica, i tuoi link sono assegnati ai nomi in relazione alla radice della tua app. Come puoi vedere da questo piccolo esempio, distribuire presto e spesso è l'ideale per catturare cose del genere. Trovare queste cose fuori dal contesto, quando stai già lavorando su qualcosa di completamente diverso e devi scavare in profondità per i bug, può pasticciare tremendamente con il tuo flusso.
git commit --all git commit -m 'Set relative_links in config.rb' middleman deploy
Tutto dovrebbe funzionare bene ora. La tipografia non è ancora perfetta, ma mi piacerebbe andare avanti e si può mettere a punto queste cose una volta che il sito è impostato nel modo in cui ne abbiamo bisogno. Diamo un'occhiata:
Come puoi vedere, ci manca il widget audio; e la lunghezza del messaggio visualizzato non è l'ideale per una lista di indici. Risolviamolo dopo. Voglio utilizzare il lettore SoundCloud più piccolo per visualizzare l'episodio di podcast nell'elenco degli indici. Quindi non ha senso estrarre un partial per il giocatore sia per l'indice che per la pagina di dettaglio: ogni pagina ha bisogno del proprio widget. Se ti piace utilizzare solo uno dei giocatori per entrambi i layout, devi assolutamente estrarne uno parziale. Lascerò questo passo a te da quando hai già imparato come è fatto.
In "source / index.html.erb":
...<% page_articles.each_with_index do |article, i| %>...<%= article.date.strftime('%b %e') %> <%= link_to article.title, article %>
<% if article.data.soundcloud_id %><% end %> <%= article.body %> <% end %>
L'esempio di codice è incentrato sulla sezione in cui eseguiamo l'iterazione page_articles
. Ho aggiunto un condizionale che visualizza solo il widget audio se l'articolo ha un sound_cloud_id
nella prima pagina dell'articolo, a cui accediamo tramite il suo attributo di dati. È molto simile al modo in cui l'abbiamo risolto in precedenza. In questo caso abbiamo usato il parametro block articolo
per accedere alle informazioni di cui abbiamo bisogno.
Quindi voglio abbreviare il testo visualizzato prima di applicare alcuni stili. Nella lista degli indici, vogliamo solo vedere qualcosa come un riassunto di 300 caratteri: non troppo, ma sicuramente anche non troppo poco testo. Sperimenta da solo e scopri cosa funziona meglio per le tue esigenze.
Per prima cosa dobbiamo aggiungere la gemma nokogiri
a noi Gemfile
:
gemma 'nokogiri'
e raggruppalo:
installazione bundle
Nell'indice dobbiamo cambiare solo una riga. Ho lasciato un commento per ciò che deve essere sostituito. Usiamo il metodo di riepilogo e lo forniamo con il numero di caratteri che vogliamo vedere per articolo nella lista degli indici.
Quindi, in "source / index.html.erb":
<%# article.body %> <%= article.summary(300) %>
E poi "source / stylesheets / _index_posts.sass":
E dovremmo aggiungere gli stili per il piccolo lettore SC .Soundcloud-player-piccole
al nostro file estratto "source / stylesheets / _blog_post_extractions.sass":
.post p, .post-title, article.article-detail, .soundclould-player-small + shift (2) + span-columns (8)
Spingi leggermente la spaziatura e abbiamo finito:
.soundclould-player-small margin-bottom: 1em
Bene, ci stiamo arrivando. Ora abbiamo una lista di indici che mostra articoli di episodi sia di solo testo che di podcast, senza complicazioni, senza alcuna sfocatura. Se hai un testo fittizio migliore, a questo punto dovrebbe sembrare abbastanza decente. Impegniamoci!
git add --all git commit -m 'Aggiunge l'articolo Summary & Small Widget all'Indice Aggiunge gli stili per l'elenco dell'indice SC widget Aggiunge Nokogiri Aggiunge il widget SC opzionale all'indice Aggiunge il riepilogo di 300 caratteri' middleman deploy
Penso che ti sei guadagnato una bella bevanda a questo punto, quindi possiamo lasciarlo per ora. Nel prossimo e ultimo tutorial lo modificheremo un po 'oltre e aggiungiamo anche qualcosa per navigare nel sito.
"Perché ospitare il podcast su SoundCloud?", Potresti chiedere. Beh, il mio ragionamento è stato semplice: prima di tutto (e non sono affiliato a SoundCloud in alcun modo) sarà sicuramente in giro per un lungo periodo - qualcosa che non ci si può aspettare da molti progetti che offrono ospita i tuoi file audio podcast. Non voglio trovarmi nella situazione di dover gestire la migrazione di tonnellate di tracce audio già pubblicate su un altro servizio solo perché qualcuno è stato acquisito o è fallito.
In secondo luogo, è decisamente economico ospitare una tonnellata di brani e hanno persino un'opzione gratuita per le persone che pubblicano brani solo occasionalmente.
Anche il giocatore e le sue opzioni vanno bene, non ho motivo di lamentarmi della velocità o di qualcosa di così lontano. Anche le statistiche sono utili e ci sono già persone sulla piattaforma che sono interessate ai podcast, il che è positivo per il fattore di scoperta. Non fraintendetemi, ci sono molte ragioni per cui ho voluto abbracciare qualcuno delicatamente intorno al collo quando si trattava di upload e sciocche cose UX, ma rispetto agli aspetti negativi di grattacapi più grandi con altre opzioni di hosting, SoundCloud sembrava il più ragionevole scelta complessiva. Infine, non mi piacciono i siti personalizzati offerti da questi siti di podcast. Sembrano super generici e mi piace costruire la mia roba che si adatta alle mie esigenze e mi consente di creare la mia identità visiva.