Share
Voortbordurend op onze statische website-opbouw, zullen we in deze tutorial de detailpagina voor berichten stylen, de podcast-widget insluiten en enige tijd besteden aan het in vorm krijgen van onze indexlijst. We zorgen ook voor duplicaties van stijlen en relatieve links.
We zullen het volgende behandelen:
Ik denk dat we onze aandacht moeten verleggen en onze pagina met details een beetje basisliefde moeten geven voordat we de app aanpassen om onze podcastafleveringen weer te geven. We zijn niet helemaal klaar met de indexpagina, als we nog wat ruimte over hebben in deze tutorial, zal ik waarschijnlijk een aantal mediaquery's toevoegen om met verschillende schermresoluties om te gaan. Voor nu zou ik zeggen, laten we doorgaan. Wat is de status-quo?
Yikes, dit ziet er niet al te goed uit! Onze tekst is helemaal over de plaats. Laten we die eerst oplossen. Het is een goed idee om het visuele raster opnieuw te activeren.
In "source / stylesheets / base / _grid-settings.scss":
$ visual-grid: true;
Als dat is gebeurd, moeten we een afzonderlijke lay-out maken voor de detailpagina's van onze berichten. De lay-out is flexibel zodat we ze kunnen gebruiken voor pure blogposts en voor het posten van podcastafleveringen. Een kleine voorwaardelijke verklaring helpt ons daarbij. Daarover later meer. Laten we config.rb openen en deze regel toevoegen:
activeren: blog do | blog | blog.layout = "lay-outs / blog-layout" einde
Dit zal Middleman vertellen dat we een aparte lay-out hebben voor detailpagina's en dat deze te vinden is in "lay-outs / blog-layout". Vervolgens moeten we "lay-outs / blog-layout.erb" maken. Vergeet niet dat de .erb zonder de .html-extensie nodig is om dit goed te laten werken.
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 %>
Laten we het hebben over wat hier gebeurt. Allereerst moeten we dit omwikkelen blog-layout binnen ons generaal lay-out. Of anders gezegd, we verpakken onze applicatie-indeling rond de blog-layout.
<% wrap_layout :layout do %>... <% end %>
Waarom? Omdat we veel van de spullen van de oorspronkelijke lay-out opnieuw willen gebruiken en geen dingen als het duplicaat dupliceren footer partiële of de asset links in hoofd. Geef het een minuut of twee om in te zakken als dit je eerst vreemd lijkt. De lay-out die we eerder gebruikten was meer een wereldwijd iets. Nu hebben we een beetje meer specificiteit nodig om aan onze behoeften te voldoen.
Binnen in de artikel tag-container, we bouwen handmatig wat we nodig hebben om onze post te sjablonen. Het heeft een titel, een datum, een optionele ingebouwde SoundCloud-widget en, uiteraard, de hoofdtekst van het artikel zelf. Binnen onze lay-outs hebben we toegang tot elk individu BlogArticle. We kunnen gebruiken current_article om de informatie voor elk artikel te krijgen om onze eigen sjabloon op te bouwen. titel, datum en lichaam zijn slechts methoden om de attributen uit het individuele artikel te extraheren. We hebben ook gebruikt strftime om de datum te formatteren zoals we eerder op de indexpagina deden.
Accentsconagua
<%= current_article.title %> <%= current_article.date.strftime('%b %e') %> <%= current_article.body %> Zoals eerder vermeld, is een eenvoudige voorwaardelijke verantwoordelijk voor het verwerken van gegevens die optioneel via de frontmatter voor elke afzonderlijke post worden aangeboden, die wordt begrensd door drie streepjes. Hier kijken we of de pagina het ID van een SoundCloud-track bevat en om de widget als dit het geval is weer te geven:
<% if current_page.data.soundcloud_id %>... <% end %>
In het geval dat u een opfriscursus nodig hebt, krijgen we toegang tot de gegevens via de huidige pagina object en vraag het gegevens voor de waarde die we in de frontmatter hebben opgeslagen via de sleutel. In ons voorbeeld is de sleutel die we nodig hebben soundcloud_id. Als onze sjabloon deze sleutel vindt via de voorwaardelijke, geeft hij de widget weer en interpoleert de SoundCloud-id voor die track om de juiste te vinden. Als het gewoon een gewone blogpost is, hoeven we de soundcloud_id in de frontmatter en de widget SoundCloud wordt niet ingesloten.
Hier is een voorbeeld van een frontmatter voor een podcast-bericht met een SoundCloud-widget:
--- title: Mijn super awesome elfde lang assed getiteld bericht dat in een andere regel datum breekt: 2015-11-30 22:14 UTC soundcloud_id: 138095821 tags: --- Je geweldige podcast aflevering beschrijving ... <%= lorem.sentences 10 %> - Vraag # 01 - Vraag # 02 ...
Wanneer u op een van de SoundCloud-tracks op "delen" klikt, krijgt u de mogelijkheid om een in te voegen iframe voor die track en moet je gewoon ergens in je code kopiëren. We gebruiken dit iframe als basis en gebruiken het ID voor de track die we nodig hebben om het in de URL te interpoleren. Er zijn twee opties, een grote en een kleine widget - ik heb de grote gekozen. Het andere heeft het voordeel dat het iets meer aanpasbaar is - je kunt bijvoorbeeld de kleur aanpassen voor de afspeelknop. Het is aan jou:
De magie gebeurt in dit deel:
... api.soundcloud.com/tracks/<%= current_page.data.soundcloud_id %>& Auto_play = ...
Nadat we hebben gevraagd of deze gegevens beschikbaar zijn via de voorwaardelijke, gebruiken we de fronmatter-gegevens om de ID te injecteren om de gewenste track weer te geven. Laten we nog een keer kijken hoe de zaken tot nu toe zijn verlopen:
Ugh. Aan de positieve kant hebben we alle structuur en gegevens die we nodig hebben. En kijk, omdat we de nestelden blog-layout binnen in de lay-out lay-out, we hebben het voordeel dat de voettekst al onderaan staat. U hoeft niets te dupliceren - cool! Met slechts een beetje styling, kunnen we dingen omdraaien en deze er wat fatsoenlijker uit laten zien.
In "source / stylesheets / all.sass":
@import 'posts_detail'
En dan in de gedeeltelijke "source / stylesheets / _posts_detail.sass":
#main + outer-container article.article-detail + shift (2) + span-kolommen (8) .detail-posttitel kleur: $ matcha-green font-size: 1.7em margin-top: 40px .detail-post -date font-size: 1.1em kleur: $ text-color .article-detail p font-size: 1.05em margin-bottom: 4em kleur: $ text-colour line-height: 1.35em .soundclould-player-big margin- onderaan: 50px
Laten we nog een snelle piek maken.
Wel, het komt daar. Laten we ons voor nu engageren en daarna wat huishouden doen:
git add --all git commit -m '1e poging tot post detail pagina w / podcast optie Voegt blog-layout toe Wijzigt configuratie voor blog-layout Voegt stijlen toe voor detailpagina Voegt Sass partiële import toe Sass partial Updates blog frontmatter'
De enthousiaste lezer heeft misschien al gezien wat we nu moeten opruimen. Er is een beetje duplicatie in "_posts_detail.sass" en "_index_posts.sass". Ik wil de gedupliceerde stijlen extraheren naar een afzonderlijk Sass-bestand met de naam "_blog_post_extractions.sass". Ik ben de laatste tijd aan het experimenteren met deze techniek - een idee dat ik kreeg van Object Oriented Programming. Dingen zoals BEM of SMACSS kunnen geweldig zijn, vooral voor grotere projecten met grotere teams als ze zich hebben geschikt voor het volgen van conventies, maar voor kleinere projecten ben ik altijd op zoek naar wrijvingloze, doodeenvoudige oplossingen. Ik zal dit proberen totdat het volgende nieuwe glimmende ding me overtuigt van een betere aanpak.
In "source / stylesheets / all.sass":
@import 'bourbon' @import 'base / base' @import 'nette' @import 'blog_post_extractions' @import 'footer' @import 'index_posts' @import 'posts_detail'
Een in "source / stylesheets / _blog_post_extractions.sass":
#main, .posts + outer-container .posten p, .post-title, article.article-detail + shift (2) + span-kolommen (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 kleur: $ text-color .posts p, .article-detail p margin-bottom: 4em
Als je het bovenstaande vergelijkt met de originele bestanden, kun je zien dat we een aardig stuk duplicatie hebben weggegooid. Het is ook gemakkelijk te begrijpen en te vinden omdat ik zulke uitgepakte bestanden direct boven in "all.sass" importeer. Het is gemakkelijk om deze extracties te herkennen voor mensen die nieuw zijn in de codebasis. In dit geval gebruik ik deze bestanden om geëxtraheerde stijlen te verzamelen die van toepassing zijn op blogposts. Een vergelijkbare aanpak zou kunnen werken voor duplicaties over verschillende verschijningsvormen van zijbalken, apparaten of soortgelijke - er zou echter een rode draad doorheen moeten.
In "source / stylesheets / _index_posts.sass":
.post-title a + transition (kleur .4s ease-in-out) &: hover color: $ 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
De vorige bestanden zijn nu een stuk kleiner, leuk en opgeruimd, precies zoals ik ze leuk vind. Bestanden zijn goedkoop, dus het maakt me niet uit als ik er veel heb die allemaal hun specifieke baantje doen. Een scheiding van zorgen. Het is geen perfecte oplossing, maar het is zo doodeenvoudig voor kleine dingen dat ik graag meer experimenteer met die aanpak.
We zouden ook ons visuele raster moeten becommentariëren in "source / stylesheets / base / _grid-settings.scss" en kijken hoe het eruit ziet:
Het is hetzelfde als voorheen, maar met veel schonere stijlen. Ik vind het leuk! Tijd om vast te leggen en voor het implementeren van onze wijzigingen:
git add --all git commit -m 'Extracts styles to _blog_post_extractions Extracts duplications from _index_posts.sass _posts_detail.sass Imports styles' medleman deploy
Laten we naar onze pagina GitHub-pagina's gaan en controleren of alles werkt zoals verwacht. Oh jee. Op het eerste gezicht ziet het er goed uit, maar als we proberen om van de index naar de detailpagina te gaan, krijgen we een 404 foutmelding. GitHub kan niet vinden wat we nodig hebben.
Als je goed hebt gekeken, heb je misschien gezien dat we wat info missen in onze url. Nu staat er iets als "http://your_username.github.io/2015/11/30/my-super-awesome-post.html". Wat het zou moeten zeggen is zoiets als "http://your_username.github.io/matcha-nerdz/2015/11/30/my-super-awesome-post.html". Het gedeelte "matcha-nerdz" was compleet verdwenen. Maak je geen zorgen, dit is een gemakkelijke oplossing. We moeten relatieve links activeren in ons configuratiebestand:
set: relative_links, true
Het hebben van absolute links op GitHub-pagina's zal in de verkeerde richting wijzen. Met deze kleine wijziging zijn uw links naamgevoelig ten opzichte van de hoofdmap van uw app. Zoals je aan dit kleine voorbeeld kunt zien, is vroegtijdig inzetten en vaak ideaal om dingen op die manier te vangen. Als je deze dingen uit de context haalt, als je al aan iets heel anders werkt en je diep moet graven naar bugs, kan het je enorm kapot maken.
git commit --all git commit -m 'Stel relative_links in config.rb' tussenpersoon deploy in
Alles zou nu goed moeten werken. De typografie is nog niet perfect, maar ik wil graag verder gaan en je kunt deze dingen verfijnen zodra de site is opgezet zoals we hem nodig hebben. Laten we eens kijken:
Zoals je ziet, missen we de audio-widget; en de lengte van het weergegeven bericht is niet ideaal voor een indexlijst. Laten we het volgende oplossen. Ik wil de kleinere SoundCloud-speler gebruiken om de podcastaflevering in de indexlijst weer te geven. Daarom is het niet logisch om een deel voor de speler uit te pakken voor zowel de index als de detailpagina - elke pagina heeft zijn eigen widget nodig. Als je voor beide indelingen slechts één van de spelers wilt gebruiken, moet je er zeker een deel voor uittrekken. Ik zal die stap aan u overlaten, omdat u al hebt geleerd hoe dit wordt gedaan.
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 %>
Het codevoorbeeld is gericht op de sectie waarin we itereren page_articles. Ik heb een voorwaarde toegevoegd die alleen de audiowidget weergeeft als het artikel een a heeft sound_cloud_id in de frontmatter van het artikel - dat we benaderen via zijn data-attribuut. Het lijkt erg op de manier waarop we dit eerder hebben opgelost. In dit geval hebben we de blokparameter gebruikt artikel voor toegang tot de informatie die we nodig hebben.
Vervolgens wil ik de weergegeven tekst inkorten voordat we een paar stijlen toepassen. In de indexlijst willen we alleen maar iets zien als een samenvatting van 300 tekens - niet te veel maar zeker ook niet te weinig tekst. Experimenteer zelf en kijk wat het beste werkt voor uw behoeften.
Eerst moeten we het juweel toevoegen nokogiri naar onze Gemfile:
gem 'nokogiri'
en bundel het:
bundel installeren
In index moeten we slechts één regel wijzigen. Ik heb een opmerking achtergelaten voor wat er moet worden vervangen. We gebruiken de samenvattingsmethode en geven deze het aantal tekens dat we per artikel in de indexlijst willen zien.
Dus in "source / index.html.erb":
<%# article.body %> <%= article.summary(300) %>
En dan "source / stylesheets / _index_posts.sass":
En we moeten de stijlen voor de kleine SC-speler toevoegen .SoundCloud-player-small naar ons geëxtraheerde bestand "source / stylesheets / _blog_post_extractions.sass":
.berichten p, .post-title, article.article-detail, .soundclould-player-small + shift (2) + span-kolommen (8)
Geef de spaties een beetje een duwtje en we zijn klaar:
.soundclould-player-small margin-bottom: 1em
Oke, we komen er wel. Nu hebben we een indexlijst die zowel artikelen met alleen tekst als podcastafleveringsartikelen weergeeft, ongecompliceerd, zonder fuzz. Als je betere dummy-tekst hebt, zou dit er nu behoorlijk goed uit moeten zien. Laten we ons vastleggen!
git add --all git commit -m 'Voegt artikeloverzicht en kleine widget toe aan index Voegt stijlen toe voor indexlijst SC widget Voegt Nokogiri toe Voegt optionele SC widget toe aan index Voegt 300 karakters samenvatting toe' tussenpersoon deploy
Ik denk dat je op dit moment een cool drankje hebt verdiend, dus we kunnen het voorlopig nog laten. In de volgende en laatste zelfstudie zullen we het een beetje verder aanpassen en ook iets toevoegen om door de site te navigeren.
"Waarom gastheer van de podcast op SoundCloud?", Zou u kunnen vragen. Nou, mijn redenering was simpel: in de eerste plaats (en ik ben op geen enkele manier aan SoundCloud gelieerd) zal het zeker voor lange tijd bestaan - iets dat je niet per se van veel projecten kunt verwachten die aanbieden host je podcast-audiobestanden. Ik wil mezelf er niet toe brengen om met het migreren van tonnen van reeds gepubliceerde audiotracks naar een andere service om te gaan, alleen maar omdat iemand is overgenomen of failliet is gegaan.
Ten tweede is het dood goedkoop om een heleboel nummers te hosten, en ze hebben zelfs een gratis optie voor mensen die slechts af en toe tracks publiceren.
De speler en zijn opties zijn ook goed - ik heb geen enkele reden om te klagen over snelheid of zo iets. De statistieken zijn ook nuttig en er zijn al mensen op het platform die geïnteresseerd zijn in podcasts - wat goed is voor de ontdekkingsfactor. Begrijp me niet verkeerd, er zijn genoeg redenen waarom ik iemand zachtjes om de nek wilde knuffelen als ik te maken had met het uploaden en gekke UX-dingen, maar in vergelijking met de nadelen van grotere hoofdpijn met andere hostingopties leek SoundCloud het meest redelijk keuze in het algemeen. Ten slotte vind ik de aangepaste sites van deze podcast-sites niet leuk. Ze zien er super generiek uit en ik vind het leuk om mijn eigen dingen te bouwen die bij mijn behoeften passen en ik kan mijn eigen visuele identiteit creëren.
