Share
Fortsatt med vår statiska webbplatsbyggnad, i denna handledning ska vi utforma detaljsidan för inlägg, bädda in podcast widgeten och spendera lite tid att få vår indexlista i form. Vi tar också hand om stil dupliceringar och relativa länkar.
Vi kommer att täcka följande:
Jag tror att vi ska flytta vår uppmärksamhet och ge vår information sida lite grundläggande kärlek innan vi justerar appen för att visa våra podcast-episoder. Vi är inte helt färdiga med indexsidan, om vi har lite utrymme kvar i den här handledningen kommer jag noga att lägga till ett par mediafrågor för att hantera olika skärmupplösningar. För nu vill jag säga, låt oss gå vidare. Vad är status quo?
Yikes, det ser inte så bra ut! Vår text är överallt. Låt oss fixa den här först. Det är en bra idé att aktivera det visuella nätet igen.
I "source / stylesheets / base / _grid-settings.scss":
$ visuellt rutnät: true;
Därför måste vi skapa en separat layout för detaljsidorna i våra inlägg. Layouten kommer att vara flexibel så att vi kan använda dem för rena blogginlägg och för att posta podcast-episoder också - ett litet villkorligt uttalande hjälper oss med det. Mer om det senare men. Låt oss öppna config.rb och lägg till den här raden:
aktivera: blogg göra | blogg | blog.layout = "layouts / blog-layout" slutet
Detta berättar Middleman att vi har en separat layout för detaljerna och att den finns i "layouts / blog-layout". Nästa måste vi skapa "layouts / blog-layout.erb". Kom ihåg att .erb är nödvändigt utan .html-tillägget för att göra detta arbete korrekt.
I "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 %>
Så låt oss prata om vad som händer här. Först av allt måste vi paketera det här blog-layout inuti vår allmänna layout. Eller, sätta annorlunda, vi paketerar vår applikationslayout kring blogglayouten.
<% wrap_layout :layout do %>... <% end %>
Varför? Eftersom vi vill återanvända många saker från den ursprungliga layouten och inte duplicera saker som sidfot dela eller tillgångslänkarna i huvud. Bara ge det en minut eller två att sjunka in om det här ser konstigt ut till dig först. Layouten som vi använde tidigare var mer av en global sak. Nu behöver vi lite mer specificitet för att passa våra behov.
Inuti artikel taggbehållare, bygger vi manuellt vad vi behöver för att malla vårt inlägg. Den har en titel, ett datum, en valfri SoundCloud-inbäddad widget och, självklart, själva artikeln. Inuti våra layouter har vi tillgång till varje enskild person BlogArticle. Vi kan använda current_article för att få informationen för varje artikel för att bygga upp vår anpassade mall. titel, datum och kropp är bara metoder för att extrahera attributen från den enskilda artikeln. Vi har också använt strftime att formatera datumet som vi gjorde tidigare på indexsidan.
Accentsconagua
<%= current_article.title %> <%= current_article.date.strftime('%b %e') %> <%= current_article.body %> Som redan nämnts är en enkel villkorlig ansvarig för hantering av data som tillhandahålls valfritt för varje enskild post via sin frontmatter-som avgränsas av tre bindestreck. Här ser vi ut om sidan har ID för ett SoundCloud-spår och att visa widgeten om så är fallet:
<% if current_page.data.soundcloud_id %>... <% end %>
Om du behöver en uppdatering får vi tillgång till data via nuvarande sida objekt och fråga sin data för det värde vi lagrade i frontmataren via dess nyckel. I vårt exempel är nyckeln vi behöver soundcloud_id. Om vår mall hittar den här nyckeln via villkoret visas widgeten och interpolerar SoundCloud-id för det spåret för att hitta rätt. Om det bara är ett vanligt blogginlägg, behöver vi inte tillhandahålla soundcloud_id i frontmatteren och SoundCloud-widgeten blir inte inbäddad.
Här är en del exempel på en podcast-post med en SoundCloud-widget:
--- titel: Min super häftiga elfte elva titeln med titeln som går in i ett annat linjedatum: 2015-11-30 22:14 UTC soundcloud_id: 138095821 Taggar: --- Din fantastiska podcast-episodbeskrivning ... <%= lorem.sentences 10 %> - Fråga # 01 - Fråga # 02 ...
När du klickar på "dela" på någon av SoundCloud-spåren får du möjlighet att bädda in en iframe för det spåret och behöver bara kopiera klistra in någonstans i din kod. Vi använder denna iframe som grund och använder id för spåret vi behöver interpolera det i webbadressen. Det finns två alternativ, en stor och en liten widget-jag valde den stora. Den andra har fördelen av att vara lite mer anpassningsbar - du kan justera färgen för spelknappen till exempel. Det är upp till dig:
Den magiska händer i den här delen:
... api.soundcloud.com/tracks/<%= current_page.data.soundcloud_id %>& Auto_play = ...
När vi frågade om dessa data är tillgängliga för oss via villkoret använder vi fronmatter-data för att injicera idet för att visa spåret vi vill ha. Låt oss ta en titt på hur sakerna visade sig så långt:
Usch. På den ljusa sidan har vi all den struktur och data vi behöver. Och se, för vi nestade blog-layout inuti layout layout, vi får nytta av att ha footer redan där längst ner. Inget behov av att duplicera saker-coolt! Med bara en liten bit av styling kan vi vända saker och göra det här lite mer anständigt.
I "source / stylesheets / all.sass":
@import 'posts_detail'
Och sedan i den dela "källan / stylesheets / _posts_detail.sass":
#main + yttre-behållaren artikel.artikel-detalj + skift (2) + spänn-kolumner (8) .detalj-efter-titel färg: $ matcha-grön typsnitt: 1.7em margin-top: 40px .detail-post -date font-size: 1.1em färg: $ text-color .article-detaljer p font-size: 1.05em margin-bottom: 4em color: $ text-color linjehöjd: 1.35em .soundclould-player-big margin- botten: 50px
Låt oss ha en annan snabb topp.
Tja, det kommer dit. Låt oss begå för nu, och gör lite hushållning efter det:
git add -all git commit -m 1: a försök på post detalj sida w / podcast alternativ Lägger till blogg layout Justerar config för blogg layout Lägger till stilar för detaljer sida Lägger till Sass partiell import Sass partiella uppdateringar blogginläggets frontmatter "
Den ivriga läsaren kanske redan har upptäckt vad vi ska städa upp nästa. Det finns lite dubbelarbete i "_posts_detail.sass" och "_index_posts.sass". Jag skulle vilja extrahera dubbletterna i en separat Sass-fil som heter "_blog_post_extractions.sass". Jag experimenterar med den här tekniken på senare tid - en idé som jag fick från objektorienterad programmering. Saker som BEM eller SMACSS kan vara bra, särskilt för större projekt med större grupper om de har avgjort för följande konventioner, men för mindre projekt letar jag alltid efter friktionslösa, döda enkla lösningar. Jag kommer att försöka tills nästa nya glänsande sak övertygar mig om ett bättre tillvägagångssätt.
I "source / stylesheets / all.sass":
@import 'bourbon' @import 'bas / bas' @ import 'snyggt' @ import 'blog_post_extractions' @ import 'footer' @ import 'index_posts' @ import 'posts_detail'
En i "source / stylesheets / _blog_post_extractions.sass":
#main, .posts + outer-container .posts p, .post-title, article.article-detail + shift (2) + span-kolumner (8) .post-title a, .detalj-efter-titel färg: $ matcha-green .post-title, .detail-post-title font-size: 1.7em .posts p, .article-detail p font-size: 1.05em linjehöjd: 1.35em .posts p, .article-detail p , .detalj-post-datum, .post-datum färg: $ text-färg .posts p, .article-detalj p margin-bottom: 4em
Om du jämför ovanstående med originalfilerna kan du se att vi blev av med en fin bit av dubbelarbete. Det är också lätt att förstå och hitta eftersom jag importerar sådana extraherade filer högst upp i "all.sass". Det är lätt att upptäcka dessa extraktioner för personer som är nya i kodbasen. I det här fallet använder jag dessa filer för att samla utdragna stilar som gäller för blogginlägg. Ett liknande tillvägagångssätt kan fungera för dubbletter över olika utseenden på sidofält, enheter eller liknande. Det bör dock vara en gemensam tråd.
I "source / stylesheets / _index_posts.sass":
.post-title a + övergång (färg .4s enkelhet) &: svängfärg: $ text-färg .post-datum teckenstorlek: 0.7em marginal: vänster: em (-80px) höger: em (20px)
I "source / stylesheets / _posts_detail.sass":
.detalj-post-title margin-top: 40px .detalj-post-datum typsnittstorlek: 1.1em .soundclould-player-big margin-bottom: 50px
De tidigare filerna är nu mycket mindre, snygga och städa - exakt hur jag gillar dem. Filerna är billiga, så jag bryr mig inte om jag har många av dem som alla gör sitt specifika lilla jobb. En separation av oro. Det är inte en perfekt lösning, men det är så dött enkelt för små saker som jag gillar att experimentera mer med det här tillvägagångssättet.
Vi bör också kommentera vårt visuella rutnät i "source / stylesheets / base / _grid-settings.scss" och se hur det ser ut:
Det är detsamma som tidigare men med mycket renare stilar. Jag gillar! Tiden att begå och för att använda våra förändringar:
git add --all git commit -m 'Extraherar stilar till _blog_post_extractions Extraherar duplikeringar från _index_posts.sass _posts_detail.sass Import stilar' mellanmedlem
Låt oss gå till vår sida för GitHub Pages och kontrollera om allt fungerar som förväntat. Kära nån. Vid första anblicken ser det bra ut, men om vi försöker gå till detaljsidan från index får vi en 404 felmeddelande. GitHub kan inte hitta vad vi behöver.
Om du har tittat noga kan du ha sett att vi saknar viss information i vår webbadress. Nu står det något som "http://your_username.github.io/2015/11/30/my-super-awesome-post.html". Vad det borde säga är något som "http://your_username.github.io/matcha-nerdz/2015/11/30/my-super-awesome-post.html". Partiet "matcha-nerdz" saknades helt. Oroa dig inte, det här är en enkel lösning. Vi måste aktivera relativa länkar i vår config-fil:
set: relative_links, true
Att ha absoluta länkar på GitHub Pages pekar i fel riktning. Med den här lilla förändringen är dina länkar namngivna i förhållande till din apps rot. Som du kan se från det här lilla exemplet är implementering tidigt och ofta idealiskt för att fånga saker som det. Att hitta dessa saker ur sammanhanget, när du redan arbetar på något helt annat och du måste gräva djupt för buggar, kan röra med ditt flöde enormt.
git commit - all git commit -m 'Ange relative_links i config.rb' intermediary deploy
Allt ska fungera bra nu. Typografi är inte perfekt ännu, men jag skulle vilja fortsätta och du kan finjustera dessa saker när webbplatsen är inställd på hur vi behöver det. Låt oss ta en titt:
Som du kan se saknar vi ljud widgeten; och längden på det visade inlägget är inte idealiskt för en indexlista. Låt oss fixa det där nästa. Jag vill använda den mindre SoundCloud-spelaren för att visa podcast-episoden i indexlistan. Därför är det inte meningsfullt att extrahera en partiell för spelaren för både indexet och detaljsidan - varje sida behöver sin egen widget. Om du bara vill använda en av spelarna för båda layouterna borde du definitivt extrahera en partiell för den. Jag lämnar det steget till dig eftersom du redan har lärt dig hur det här görs.
I "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 %>
Kodexemplet är inriktat på det avsnitt där vi repeterar över page_articles. Jag lade till en förutsättning att endast ljuddisplayen visas om artikeln har en sound_cloud_id i artikelns främre del - som vi åtkomst till via dess datatribut. Det är väldigt lik det sätt som vi löst detta tidigare. I det här fallet använde vi blockparametern artikel för att komma åt den information vi behöver.
Därefter vill jag förkorta den visade texten innan vi tillämpar några stilar. I indexlistan vill vi bara se något som en sammanfattning av 300 tecken - inte för mycket men definitivt inte heller för liten text. Experiment på egen hand och se vad som bäst passar dina behov.
Först måste vi lägga till pärlan Nokogiri till vår Gemfile:
pärla "nokogiri"
och bunt det:
buntinstallation
I index behöver vi bara ändra en rad. Jag lämnade en kommentar för vad som behöver bytas ut. Vi använder sammanfattningsmetoden och levererar den med antalet tecken vi vill se per artikel i indexlistan.
Så, i "source / index.html.erb":
<%# article.body %> <%= article.summary(300) %>
Och sedan "source / stylesheets / _index_posts.sass":
Och vi borde lägga till stilar för den lilla SC-spelaren på .Soundcloud-spelare-small till vår extraherade fil "source / stylesheets / _blog_post_extractions.sass":
.inlägg p, .post-title, article.article-detail, .soundclould-player-small + shift (2) + span-kolumner (8)
Nudge avståndet lite och vi är klara:
.soundclould-player-small margin-bottom: 1em
Okej, vi kommer dit. Nu har vi en indexlista som visar både text-bara och podcast-episodartiklar - okomplicerat, utan några fuzz. Om du har bättre dummy text, så borde det se ganska anständigt ut nu. Låt oss begå!
git add --all git commit -m 'Lägger artikel Sammanfattning och liten widget till index Lägger till stilar för indexlista SC widget Lägger till Nokogiri lägger till tillval SC-widget till index Lägger till 300 teckenuppsättning "mellanmedlem
Jag tror att du har förtjänat dig en cool dryck på den här tiden, så vi kan lämna det med det för nu. I nästa och sista handledning tweakar vi det lite längre och lägger till lite lite för att navigera på webbplatsen.
"Varför värd podcasten på SoundCloud?", Kanske du frågar. Jo, mitt resonemang var enkelt: Först och främst (och jag är inte ansluten till SoundCloud på något sätt) kommer det ganska säkert att vara länge - något som du inte nödvändigtvis kan förvänta dig av många projekt som erbjuder värd dina podcast ljudfiler. Jag vill inte få mig i situationen att hantera migrerande ton av redan publicerade ljudspår till en annan tjänst bara för att någon förvärvade eller gick bust.
För det andra är det dött billigt att vara värd för massor av spår, och de har till och med ett gratis alternativ för folk som bara publicerar spår ibland.
Spelaren och dess alternativ är också okej-jag har ingen anledning att klaga på hastighet eller någonting hittills. Statistiken är också användbar och det finns redan personer på plattformen som är intresserade av podcaster - vilket är bra för funktionsfaktorn. Får mig inte fel, det finns många anledningar till att jag ville krama någon försiktigt runt nacken när jag hanterade uppladdning och dumma UX-saker, men i jämförelse med nackdelarna med större huvudvärk med andra värdalternativ verkade SoundCloud som den mest rimliga val övergripande. Slutligen gillar jag inte de anpassade sajterna som dessa podcast-webbplatser erbjuder. De ser super generiska ut och jag gillar att bygga mina egna saker som passar mina behov och låter mig skapa en egen visuell identitet.
