Share
Fortsetter med vår statiske nettsidebygging, i denne opplæringen vil vi utforme detaljsiden for innlegg, legge inn podcast-widgeten og bruke litt tid på å få indekslisten vår i form. Vi vil også ta vare på stil duplikasjoner og relative lenker.
Vi skal dekke følgende:
Jeg tror vi bør skifte vår oppmerksomhet og gi vår informasjon side litt grunnleggende kjærlighet før vi justerer appen for å vise våre podcast-episoder. Vi er ikke helt ferdige med indekssiden, hvis vi har noen plass igjen i denne opplæringen, vil jeg nok legge til et par medieforespørsler for å håndtere forskjellige skjermoppløsninger. For nå vil jeg si, la oss gå videre. Hva er status quo?
Yikes, dette ser ikke så bra ut! Vår tekst er over alt. La oss fikse den første. Det er en god idé å aktivere det visuelle nettet på nytt.
I "kilde / stylesheets / base / _grid-settings.scss":
$ visningsnett: sant;
Det som er gjort, må vi lage et eget oppsett for detaljene i våre innlegg. Oppsettet vil være fleksibelt slik at vi kan bruke dem til rene blogginnlegg og for å legge ut podcast-episoder også. En liten betinget erklæring vil hjelpe oss med det. Mer om det senere skjønt. La oss åpne config.rb og legge til denne linjen:
aktivere: blogg do | blog | blog.layout = "layouts / blog-layout" slutten
Dette vil fortelle Middleman at vi har en egen layout for detaljer og at den finnes i "layouts / blog layout". Deretter må vi lage "layouts / blog-layout.erb". Husk at .erb er nødvendig uten .html-utvidelsen for å gjøre dette arbeidet riktig.
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å la oss snakke om hva som skjer her. Først av alt, må vi pakke inn dette blogg-layout inne i vår generelle oppsett. Eller sett annerledes, vi pakker inn programoppsettet rundt bloggoppsettet.
<% wrap_layout :layout do %>... <% end %>
Hvorfor? Fordi vi ønsker å gjenbruke mange ting fra det opprinnelige oppsettet og ikke duplisere ting som bunntekst delvis eller eiendelkoblingene i hode. Bare gi det et minutt eller to å synke inn hvis dette ser merkelig ut til deg først. Layoutet vi brukte tidligere var mer av en global ting. Nå trenger vi litt mer spesifisitet for å passe våre behov.
Inne i artikkel tag container, bygger vi manuelt det vi trenger for å malere innlegget vårt. Den har en tittel, en dato, en valgfri SoundCloud-innebygd widget og selvfølgelig selve artikkelen. I våre layouter har vi tilgang til hver enkelt person BlogArticle. Vi kan bruke current_article for å få informasjonen for hver artikkel for å bygge opp vår egendefinerte mal. tittel, Dato og kropp er bare metoder for å trekke ut attributter fra den enkelte artikkelen. Vi brukte også strftime å formatere datoen som vi tidligere gjorde på indekssiden.
Accentsconagua
<%= current_article.title %> <%= current_article.date.strftime('%b %e') %> <%= current_article.body %> Som allerede nevnt er en enkel betinget ansvarlig for håndtering av data som er gitt eventuelt for hvert enkelt innlegg via frontmatteren - som er avgrenset av tre bindestreker. Her ser vi ut om siden har ID for et SoundCloud-spor, og for å vise widgeten hvis så:
<% if current_page.data.soundcloud_id %>... <% end %>
Hvis du trenger en oppfriskning, får vi tilgang til dataene via nåværende side objekt og spør det data for verdien vi lagret i frontmatteren via nøkkelen. I vårt eksempel er nøkkelen vi trenger soundcloud_id. Hvis vår mal finner denne nøkkelen via betinget, viser den widgeten og interpolerer SoundCloud-ID for det sporet for å finne den rette. Hvis det bare er et vanlig blogginnlegg, trenger vi ikke å gi soundcloud_id i frontmatteren og SoundCloud-widgeten blir ikke innebygd.
Her er noen eksempler på en podcast-post med en SoundCloud-widget:
--- tittel: Min super fantastiske ellevte lange assed tittel post som bryter inn i en annen linje dato: 2015-11-30 22:14 UTC soundcloud_id: 138095821 tags: --- Din fantastiske podcast episode beskrivelse ... <%= lorem.sentences 10 %> - Spørsmål # 01 - Spørsmål # 02 ...
Når du klikker på "dele" på noen av SoundCloud-sporene, får du muligheten til å legge inn en iframe for det sporet og trenger bare å kopiere lim inn det et sted i koden din. Vi bruker denne iframe som grunnlag og bruker id for sporet vi trenger for å interpolere det inn i webadressen. Det er to alternativer, en stor og en liten widget-jeg valgte den store. Den andre har fordelen av å være litt mer tilpassbar - du kan justere fargen for spilleknappen for eksempel. Det er opp til deg:
Den magien skjer i denne delen:
... api.soundcloud.com/tracks/<%= current_page.data.soundcloud_id %>& Auto_play = ...
Etter at vi spurte om disse dataene er tilgjengelige for oss via betingelsene, bruker vi fronmatter-dataene til å injisere id for å vise sporet vi ønsker. La oss ta en titt på hvordan ting har vist seg så langt:
Ugh. På den lyse siden har vi all strukturen og dataene vi trenger. Og se, fordi vi nestet blogg-layout inne i oppsett layout, får vi fordelen av å ha bunnteksten allerede der på bunnen. Du trenger ikke å duplisere ting-kul! Med bare litt styling kan vi snu ting rundt og gjøre dette ser litt mer anstendig ut.
I "kilde / stylesheets / all.sass":
@import 'posts_detail'
Og så i delene "kilde / stylesheets / _posts_detail.sass":
#main + outer-container artikkel.artikkel-detalj + skift (2) + span-kolonner (8) .detalj-post-tittel farge: $ matcha-grønn skriftstørrelse: 1.7em margin-top: 40px .detail-post -date font-size: 1.1em farge: $ tekst-farge .artikkel-detalj p font-størrelse: 1.05em margin-bunn: 4em farge: $ text-farge linje høyde: 1.35em .soundclould-player-big margin- bunn: 50px
La oss få en annen rask topp.
Vel, det kommer dit. La oss forplikte for nå, og gjør noe etter det:
git add -all git commit -m 1 første forsøk på post detalj side w / podcast-alternativ Legger til bloggoppsett Justerer konfigurasjon for blogg-layout Legger til stiler for detaljer side Legger til Sass delvis Import Sass delvis oppdateringer blogginnleggets frontmatter '
Den ivrige leseren har kanskje allerede oppdaget hva vi skal rydde opp neste. Det er litt duplisering i "_posts_detail.sass" og "_index_posts.sass". Jeg vil gjerne trekke ut dupliserte stiler i en egen Sass-fil kalt "_blog_post_extractions.sass". Jeg eksperimenterer med denne teknikken i det siste - en ide som jeg fikk fra Object Oriented Programming. Ting som BEM eller SMACSS kan være flotte, spesielt for større prosjekter med større lag hvis de har bosatt seg for følgende konvensjoner, men for mindre prosjekter søker jeg alltid etter friksjonsløse, døde, enkle løsninger. Jeg gir dette en prøve til neste nye skinnende ting overbeviser meg om en bedre tilnærming.
I "kilde / stylesheets / all.sass":
@import 'bourbon' @import 'base / base' @import 'ryddig' @import 'blog_post_extractions' @import 'footer' @import 'index_posts' @import 'posts_detail'
En i "kilde / stylesheets / _blog_post_extractions.sass":
#main, .posts + outer-container .posts p, .post-title, artikkel.artikkel-detalj + skift (2) + span-kolonner (8) .post-title a, .detalj-etter tittelfarge: $ matcha-green .post-title, .detail-post-title font size: 1.7em .posts p, .article-detaljer p font-size: 1.05em linjehøyde: 1.35em .posts p, .article-detaljer p , .details-post-date, .post-date farge: $ tekst-farge .posts p, .artikkel-detaljer p margin-bunn: 4em
Hvis du sammenligner ovennevnte med de opprinnelige filene, kan du se at vi ble kvitt en fin del av duplisering. Det er også lett å forstå og finne fordi jeg importerer slike hentede filer helt oppe i "all.sass". Det er lett å få øye på disse ekstraksjonene for folk som er nye på kodebase. I dette tilfellet bruker jeg disse filene til å samle uthente stilarter som gjelder for blogginnlegg. En lignende tilnærming kan fungere for duplikasjoner på tvers av forskjellige fremtoninger av sidefelt, enheter eller lignende. Det bør imidlertid være en felles tråd.
I "kilde / stylesheets / _index_posts.sass":
.post-title a + overgang (farge .4s brukervennlighet) &: sveverfarge: $ tekstfarge .post-dato fontstørrelse: 0.7em margin: venstre: em (-80px) høyre: em (20px)
I "kilde / stylesheets / _posts_detail.sass":
.detalj-post-title margin-top: 40px .details-post-date font size: 1.1em .soundclould-player-big margin-bottom: 50px
De forrige filene er nå mye mindre, hyggelige og ryddige, akkurat slik jeg liker dem. Filene er billige, så jeg bryr meg ikke om jeg har mange av dem som alle gjør sin spesifikke lille jobb. En adskillelse av bekymringer. Det er ikke en perfekt løsning, men det er så dødt enkelt for små ting som jeg liker å eksperimentere mer med den tilnærmingen.
Vi bør også kommentere vårt visuelle nett i "kilde / stylesheets / base / _grid-settings.scss" og se hvordan det ser ut:
Det er det samme som før, men med mye renere stiler. Jeg liker! Tid til å forplikte seg og for å implementere våre endringer:
git add --all git commit -m 'Ekstra stiler i _blog_post_extractions Ekstrakter duplikasjoner fra _index_posts.sass _posts_detail.sass Import stiler' mellommann distribuere
La oss gå til vår GitHub Pages-side og sjekke om alt fungerer som forventet. Åh kjære. Ved første øyekast ser det bra ut, men hvis vi prøver å gå til detaljsiden fra indeksen, får vi en 404 feilmelding. GitHub kan ikke finne det vi trenger.
Hvis du har sett nøye, har du kanskje sett at vi mangler litt info i vår webadresse. Nå står det noe som "http://your_username.github.io/2015/11/30/my-super-awesome-post.html". Hva det skal si er noe som "http://your_username.github.io/matcha-nerdz/2015/11/30/my-super-awesome-post.html". "Matcha-nerdz" -delen manglet helt. Ikke bekymre deg, dette er en enkel løsning. Vi må aktivere relative lenker i vår config-fil:
sett: relative_links, true
Å ha absolutte lenker på GitHub Pages vil peke i feil retning. Med denne lille forandringen er linkene dine navngitt i forhold til appens rot. Som du kan se fra dette lille eksempelet, er distribusjon tidlig og ofte ideell for å fange ting som det. Å finne disse tingene ut av sammenheng, når du allerede jobber med noe helt annet og du må grave dypt for feil, kan rote med strømmen enormt.
git commit - all git commit -m 'Sett relative_links i config.rb' mellomman distribuere
Alt skal fungere fint nå. Typografien er ikke perfekt ennå, men jeg vil gjerne fortsette, og du kan finjustere disse tingene når nettstedet er satt opp slik vi trenger det. La oss se:
Som du kan se, mangler vi lyd-widgeten; og lengden på det viste innlegget er ikke ideelt for en indeksliste. La oss fikse det neste. Jeg vil bruke den mindre SoundCloud-spilleren til å vise podcast-episoden i indekslisten. Derfor er det ikke fornuftig å trekke ut en del for spilleren for både indeksen og detaljsiden - hver side trenger sin egen widget. Hvis du bare vil bruke en av spillerne for begge layoutene, bør du definitivt trekke ut en del for den. Jeg forlater dette skrittet for deg siden du allerede har lært hvordan dette er gjort.
I "kilde / 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 %>
Kodeksemplet er fokusert på delen der vi gjentar over page_articles. Jeg la til en betinget at bare viser lyd-widgeten hvis artikkelen har en sound_cloud_id i frontmatteren av artikkelen - som vi har tilgang til via datatributtet. Det ligner på den måten vi løst dette tidligere. I dette tilfellet brukte vi blokkparameteren artikkel for å få tilgang til den informasjonen vi trenger.
Deretter vil jeg forkorte den viste teksten før vi bruker noen få stiler. I indekslisten vil vi bare se noe som et 300 tegnsammendrag - ikke for mye, men definitivt heller ikke for liten tekst. Forsøke på egenhånd og se hva som passer best for dine behov.
Først må vi legge til perlen Nokogiri til vår Gemfile:
perle 'nokogiri'
og pakke det:
bunt installasjon
I indeksen må vi bare endre en linje. Jeg dro en kommentar til det som må byttes ut. Vi bruker sammendragsmetoden og leverer den med antall tegn vi vil se per artikkel i indekslisten.
Så, i "kilde / index.html.erb":
<%# article.body %> <%= article.summary(300) %>
Og så "kilde / stylesheets / _index_posts.sass":
Og vi bør legge stilene til den lille SC-spilleren på .Soundcloud-player-small til vår hentede fil "kilde / stylesheets / _blog_post_extractions.sass":
.Innlegg p, .post-title, artikkel.artikkel-detaljer, .soundclould-player-small + shift (2) + span-kolonner (8)
Nudge avstanden litt, og vi er ferdige:
.soundclould-player-small margin-bottom: 1em
OK, vi kommer dit. Nå har vi en indeksliste som viser både tekst-bare og podcast-episodeartikler-ukomplisert, uten noen fuzz. Hvis du har bedre dummy tekst, bør dette se ganske greit ut nå. La oss begå!
git add --all git commit -m Legger artikkeloversikt og liten widget til indeksen legger til stiler for indekslisten SC-widget legger til Nokogiri legger til valgfri SC-widget til indeksen legger til 300 tegn sammendrag "mellomman distribuere
Jeg tror du har tjent deg en kul drikke på dette tidspunktet, så vi kan forlate det på det for nå. I neste og siste opplæring vil vi finjustere det litt videre og også legge til litt noe for å navigere på nettstedet.
"Hvorfor hoste podcasten på SoundCloud?", Kan du spørre. Vel, min begrunnelse var enkel: Først og fremst (og jeg er ikke tilknyttet SoundCloud på noen måte) vil det ganske sikkert være lenge rundt, noe som du ikke nødvendigvis kan forvente av mange prosjekter som tilbyr å vert for podcast lydfilene dine. Jeg ønsker ikke å få meg i situasjonen for å håndtere migrerende tonn allerede publiserte lydspor til en annen tjeneste, bare fordi noen fikk til seg eller gikk bust.
For det andre er det dødt billig å være vert for en rekke spor, og de har selv et gratis alternativ for folk som publiserer spor bare av og til.
Spilleren og dens alternativer er også i orden - jeg har ingen grunn til å klage på hastighet eller noe så langt. Statistikken er også nyttig, og det er allerede folk på plattformen som er interessert i podcaster, noe som er bra for funnfaktoren. Ikke misforstå, det er mange grunner til at jeg ville kramme noen forsiktig rundt nakken når det gjelder opplasting og dumme UX-ting, men i forhold til ulemper av større hodepine med andre hosting-alternativer, virket SoundCloud som den mest fornuftige valg generelt. Til slutt, jeg liker ikke de egendefinerte nettstedene som disse podcast-nettstedene tilbyr. De ser super generiske ut, og jeg liker å bygge mine egne ting som passer til mine behov, og lar meg lage min egen visuelle identitet.
