Share
Dette er en del av en liten serie om Middleman, "en statisk nettstedgenerator som bruker alle snarveiene og verktøyene i moderne webutvikling". De to første opplæringsprogrammene vil dekke grunnleggende, hvoretter vi legger til det vi har lært til handling med et praktisk prosjekt. Middleman krever bruk av Ruby, men ikke nøl med å lese om dette er fremmed for deg; denne serien er helt nybegynnerlig.
Hva er det som skjer i det siste med statiske nettsteder? Vel, de er raske, ganske enkle å sette opp og lette. Siden du ikke serverer noe databaselatert, er statiske nettsteder ganske pålitelige og hurtige. HTML, CSS og om nødvendig JS-det er alt.
Mange bruker statiske nettsteder til å sette opp sine blogger og personlige sider. Landingssider som rammes av trafikk tungt er også en god kandidat. HealthCare.gov fra Obama-administrasjonen brukte jevnlig Jekyll, en annen statisk nettstedgenerator, for deres nettsted. Hvis du trenger noe raskt og enkelt, som er i stand til å skalere ut av boksen, kan statiske steder være fantastiske. Spesielt som du kan være vert for dem gratis på GitHub Pages eller Heroku.
Helt sikkert begynte hele statisk hipthet et par år tilbake da Jekyll kom sammen. Selvfølgelig er statiske nettsteder like gamle som den første "Hello World!" Fra Sir Tim Berners-Lee, men i løpet av de siste 15 årene, ble databaserte apps blitt "alt som betyr noe". Et par år tilbake, en av medgrunnleggerne til GitHub trengte en bedre måte å skrive blogger på, og han kom opp med Jekyll - denne hipstatistiske nettstedgeneratoren for "Blogging like a hacker". Jeg har brukt det ved et par anledninger og har bare gode ting å rapportere. Kjernelaget er også fantastisk. Uansett, for denne serien ble redaktøren min og jeg enige om at det ville være mer interessant å dekke Middleman. Det kan være greit å si at Middleman er litt mindre "bloggbevisst" ut av boksen, men likevel like kraftig og god kvalitetskunnig.
Middleman bruker Ruby, og tilbyr et ganske stort sett med funksjoner for å bygge kule ting. Hvis du noen gang har brukt Rails eller Sinatra, vil du føle deg hjemme. Det virker Middleman og Jekyll er go-to alternativene for statiske steder i Ruby samfunnet. Jeg har også hørt flere og flere designere hevder at de liker å bruke dem til prototyping og for å sette opp egne sider. Hva mange av disse statiske rammebetingelsene har til felles er at de er ganske enkle å bruke.
I denne artikkelen antar jeg at du er minst a bit interessert i Ruby, og har den installert på systemet ditt. Hvis du trenger hjelp, ta en titt på Ruby for Newbies: Installere Ruby og Komme i gang av Andrew Burgess.
Å vite hvordan å håndtere RubyGems er også nødvendig, og igjen, Andrew Burgess 'Ruby for Newbies: Arbeide med Gems vil hjelpe deg å komme i gang hvis det er nødvendig. Jeg vil gjøre mitt beste for ikke å gå over hodet med programmeringskonsepter, men jeg vil ikke dekke programmeringsgrunnleggende som looper, kodeblokker og så videre. For nybegynnere blant dere, vær ikke bekymret, Middleman har ikke så mange bevegelige deler, og jeg skal demonstrere hvor lett det er å lære.
Så har du Ruby og RubyGems under beltet ditt? Flott, så er det godt å gå.
Åpne opp terminalen din og skriv inn:
bash perle installere mellommann
Hvis du nektes tillatelse til å gjøre det, må du legge inn kommandoen med sudo og skriv inn systemadministrasjonspassordet ditt. Etter at denne prosessen er ferdig, vil du kunne bruke et par praktiske mellommannkommandoer via kommandoprompten.
Denne kommandoen starter et nytt prosjekt. Du må gi navnet navnet på appen din, og deretter trykke Enter.
bash middleman init your_fancy_app Det tar også flere argumenter som hvilken mal du vil starte med. Dette gjør det veldig praktisk å tilpasse appene dine med maler fra begynnelsen, og kutte ned på repeterende oppsettoppgaver ganske mye! Vi diskuterer mer om maler i en senere opplæring.
bash middleman init your_fancy_blog --template = blog
bash middleman init your_fancy_mobile_app --template = mobile
Middleman kommer med en lokal server for din utvikling. Ved å starte opp kan du se nettstedet ditt på http: // localhost: 4567 / **. Hvis du bare skriver inn ** mellommann uten noe ekstra argument, vil dette også brenne serveren din opp. Slå av serveren din med CTRL-c.
Når du har noe du er klar til å sette på en Internett-server du må bygge din side. Dette betyr at det du har forberedt på i ditt /kilde mappen vil bli behandlet og den endelige utgangen vil bli sendt til /bygge mappe hvilken mellemann også skaper for deg. Alle filene dine som bruker preprosessorer som Slim, Haml, Sass, CoffeeScript, blir behandlet i sine respektive kolleger og lagt inn i din / bygge katalog.
Når nettstedet ditt er klar til å møte Internett, deponerer denne kommandoen din /bygge mappe på webserveren din. Hver oppdatering du lager vil gå gjennom denne prosessen.
Gjør deg selv en tjeneste med en gang, og aktiver LiveReload for å automatisk oppdatere sidene dine etter endringer i HTML-, Sass- eller JS-filene dine. Dette er veldig praktisk under utvikling - du vil ikke angre på det! Middleman tilbyr disse dager LiveReload ut av boksen-du trenger bare å legge til
rubin perle 'middleman-livereload'
til din Gemfile og uncomment følgende linje inn config.rb:
rubin # Last på nettleseren automatisk når filene endres aktivert: leverelad
Da pakker du Middleman
bash bundle #or bundle exec middleman
Så la oss komme i gang med /kilde og /bygge mapper. Mellom dem er skillelinjen som skiller utviklings- og produksjonsseksjonene dine. Når du bruker din lokale webserver for utvikling, blir kilde vant til å betjene appen din. Mappen / byggemappen brukes av dine ikke-lokale servere til å betjene dine statiske sider. / Bygg blir opprettet hver gang du bruker mellommann bygge i kommandolinjen din. Derfor bør du være forsiktig med ikke å tilfeldigvis bruke koden din i / bygge fordi dette arbeidet vil forsvinne etter byggeprosessen. Generelt må hele din utvikling skje i / kilde.
Byggeprosessen oppretter de statiske nettstedene du vil at serveren skal være vert for. Hver fil i din /kilde mappen vil bli behandlet og deretter lagret i /bygge. Som nevnt tidligere, vil din Sass, CoffeeScript, Slim / Haml og partials prosessere i deres deplyable kolleger. Alle oppsettene vil også bli spisset sammen. Hvis du har aktivert komprimering for disse filene, er dette øyeblikket de blir "uglified" også. Under hele denne shabang blir / build-mappen rejuvinated ved å kvitte seg med filer som ikke har noen referanse i / kilde lenger. Under mellommann bygge, eventuelle endringer du har gjort til filer i / kilde, vil utløse en regenerering av nye tilsvarende statiske filer for / bygge.
Utplasseringsprosessen er det siste trinnet. Med /bygge katalog på plass har du alt du trenger for å sette din app der ute. Min anbefaling er å gjøre dette tidlig for å unngå å løpe inn i noen overraskelser.
La oss sjekke ut grunnstrukturen til en Middleman-app. Hovedkomponentene er:
Som du kan se nedenfor, går mest Jazz inn i /kilde mappe. Det jeg liker om Middleman apps er deres enkle organisasjon. Navigering i dokumentstrukturen er rett frem, selv for nybegynnere.
Hvis du er fornøyd med navnet på noen av disse mappene, kan du endre det i konfigurasjonene dine (config.rb). De samme navnene vil bli brukt til ferdigstillelse /bygge mappe.
"ruby sett: css_dir, 'custom_folder_name'
sett: js_dir, 'custom_folder_name'
sett: images_dir, 'custom_folder_name'
Når du har serveren din kjører, kan du sjekke ut andre alternativer for å konfigurere Middleman rett i nettleseren din: http: // localhost: 4567 / __ middleman / config /. Ikke alle av dem kan være fornuftige, eller er enda viktig å vite på dette stadiet. Gi det et blikk og et mentalt bokmerke er helt tilstrekkelig for nå.
En du løper mellommann bygge du kan kikke inn i /bygge mappe. Alle de vanlige HTML-, CSS- og JS-filene du trenger for å betjene ditt statiske nettsted.
Det er stort sett alt du trenger å vite for å komme i gang og orientere deg selv.
Forslag: På denne ponten ville det være mye fornuftig hvis du begynner å sette sammen en testapp selv. Se deg rundt og få en følelse av hvordan ting er organisert og hvordan brikkene passer sammen.
Begrepet Front Matter kommer fra bokutgivelse, og det refererer til informasjonen på forsiden av en bok. Når det gjelder statiske nettsider, refererer den til blokker av informasjon som er lagret i YAML. Hver side gir deg mulighet til å ha variabler som kan lagres rett øverst inne i en ledende og en etterfølgende tredobbelt bindestrek. For eksempel, her er toppen av en fiktiv fil som heter: some.html.erb.
layout: Bond tittel: Favoritt bond jente navn dato: 2015-11-09 tags: bond, 007
Some_secret: Jeg blir ikke gjengitt før du bruker meg.
bond_girls: - Strawberry Fields - Jill Masterson - Tiffany Case
"
YAML-variablene ser ut som en hash. Du kan få tilgang til de lokale dataene via nåværende side gjenstand:
rubin current_page.data.some_variable
Du bruker ofte dette til å lagre koder, datoer, titler og konfigurasjonsalternativer - som hvilken layout du vil bruke for bestemte sider. Frontmateriell er en YAML-butikk for variablene dine. Du kan også bruke JSON hvis du foretrekker det. Tenk på det som et sted for å sette data som normalt vil ligge i en database. Jeg vil diskutere de ulike alternativene og brukerne underveis når de kommer opp.
Dette er en god mulighet til å gå kort over ERB. ERB lar deg lage dynamiske maler som har innebygd kode i dem. Filnavnene dine må ha en .erb forlengelse og du må sette koden i følgende to "containere".
For kode som blir eksekutert, men ikke "trykt" på siden, bruker du dette:
html <% %>
Tenk på det som "bare beregning".
Ellers, for returverdier som du vil se vises "trykt" på siden, må du legge til et like tegn også. Det er det.
html <%= %>
Begrepene layouts og partials er nært beslektet. La meg gi deg en liten hvirvelvindstur i tilfelle du ikke har spilt med Rails, Sinatra eller lignende før. Jeg tror jeg skal begynne med oppsett først.
Layouts gir deg strukturen for å dele felles merking mellom forskjellige sider - som tilhører samme "familie" av sider. Det er et verktøy for å unngå duplisering og for å øke hastigheten på arbeidet ditt. I stedet for å skrive det samme HTML-skjelettet over hele stedet, skriver du oppsett for spesielle brukstilfeller. Populære eksempler er to forskjellige oppsett for både en admin og en "normal" bruker. De har vanligvis en helt annen opplevelse å se på "samme" side.
Når du starter en enkel mellommannapp, får du automatisk en layout.erb filen inn Kilde / oppsett. Vær oppmerksom på at denne filen slutter i .erb og ikke .html.erb. Layouter skal ikke gjengis til HTML og Middleman vil kaste en feil hvis du lager oppsett med en .html-utvidelse. Hvis du bruker et annet templerende språk som Slim eller Haml, kan layoutene ha sine utvidelser i stedet. Som standard antyder, bør du legge alle layoutene dine inn i / oppsett mappe inn kilde.
Her er et eksempel på kilde / layouter / layout.erb:
"html
"
Denne standardoppsettet er ganske barebones, men gir alt du trenger for å komme i gang. La oss se:
Og derfra kan du tilpasse dette oppsettet til alle dine behov. Et potensielt forvirrende aspekt for Ruby newbies er utbytte søkeord - dette betyr bare at det går gjennom resten av innholdet du lager. Med andre ord, utbytte er en plassholder for dine synspunkter som vil bli gjengitt inn i den. Hvis det konseptet er helt fremmed for deg, husk du ikke å røre det for nå, eller det kan hende at appen din ikke fungerer som forventet. Når du lager dine egne oppsett, har du utbytte der er viktig, ellers vil innholdet ditt ikke vises. Du får tak i det på et blunk, jeg lover.
Hvis du har opprettet forskjellige layouter, kan du spesifisere via forsiden hvilken layout du vil bruke på en side ved side. La oss si at du har et spesielt oppsett for innbydende brukere som er litt mer salgsmessige. Her har vi welcome.html.erb.
layout: salg -
"
Alternativt kan du angi oppsett i config.rb-filen.
ruby side "/welcome.html",: layout => "sales"
Hvis du vil unngå å gjøre dette for hver side manuelt, kan du samle dem på ett sted. Igjen, i config.rb, bruker du et jokertegn (** \ ***) for å samle en haug med sider som bruker samme layout.
ruby side "/ salg / *",: layout => "salg"
Jeg personlig liker å sette denne oppsettinformasjonen i frontmaten. Det er veldig eksplisitt og ikke for repetetivt. Hvis jeg hadde en hel haug med dem, vil jeg helst bruke wildcard-tilnærmingen.
Deler gir deg mulighetene til å inkapslere visningskode som du kan gjenbruke uansett hvor du trenger. Du trenger bare å fortelle din utsikt hvor å sette inn en del og det blir gjengitt rett der inne. Deler er en veldig vanlig teknikk for DRYing opp koden din.
Svært vanlige eksempler er navbars, footers og head sections, som du ikke ønsker å duplisere over alt. Filer for partials starter med en underskrift. Til å begynne med kan du plassere dem under /kilde. Dine oppsett er et godt sted å begynne med å samle inn kode for å trekke seg ut i partier. Når du finner noe du trenger å gjenbruke, vil partials være en nyttig venn.
Her er et eksempel på /source/layouts/layout.erb.
"html
<%= partial "head" %> <%= partial "navbar" %> <%= yield %> <%= partial "footer" %>"
Og den delvise kilden / _head.html.erb:
"html
<%= stylesheet_link_tag “normalize”, “all” %> <%= javascript_include_tag “all” %>"
Noen ganger vil du trekke ut en delvis ikke bare for å unngå duplisering, men for å gjøre visningene dine mer lesbare. Over tid er hovedenheter beryktet for å bli ganske lastet, for eksempel. Innenfor dem kan du ha annen partials som bare omhandler stil eller JS-filer.
Du vil innse hvor praktisk delene er når du kan bruke endringer som krøp gjennom hele appen din, uansett hvor du inkluderte den delvise. Det er ikke nødvendig å gå gjennom en haug med filer for å bruke den samme forandringen om og om igjen.
Hjelpere er metoder du kan bruke til mange daglige oppgaver i dine synspunkter. Jeg tror dette var banebrytende i Rails land og ble raskt allestedsnærværende for web moderne webutvikling. Du har allerede sett hjelpere som inkluderer stilark og JavaScript-filer. Det er mye mer hvor dette kommer fra skjønt.
Her er vår /source/_head.html.erb delvis igjen:
"html
<%= stylesheet_link_tag "normalize", "all" %> <%= javascript_include_tag "all" %>"
Disse hjelperne er ment å hjelpe deg med å skrive renere og mer konsis visningskode. I hjelpelisten nedenfor finner du mange nyttige ting som kommer ut av boksen. Du er ikke begrenset av disse skjønt. Skriv dine egne hjelpemetoder i config.rb eller samle dem separat i en modul.
Det virker slik: I config.rb oppretter du en hjelpere blokkere og legg inn alle dine hjelpemetoder inni. Det er det. Nå har dine synspunkter tilgang til dem.
Eksempel: /source/_navbar.erb.
"html
"
Og i config.rb:
"Ruby hjelpere gjør
def random_username "# lorem.first_name # lorem.last_name" avslutte
def random_image image_tag "# lorem.image ('30x40',: background_color => '333',: color => 'fff')" slutt
slutt"
Disse hjelpene kan komme til nytte når jeg raskt vil prototype noe og vil unngå å sette opp dummy bilder og tekst selv. Samlet sett bør du se etter kode som du vil være mer konsistent eller at du dupliserer igjen og igjen. Hjelpere er ofte et godt hjem for det.
I disse tilpassede hjelpene brukte jeg andre Middleman-hjelpere for å skape img merker gjennom IMAGE_TAG samt lorem objekt for noen tilfeldige brukernavn og bildeplassholdere. Disse lorem thingies kan være litt tilpasset for dine behov.
Bruk modulmodusen, men du trenger en egen fil for modulen din. Opprett en "lib" -katalog i rotmappen din (samme nivå som "kilde" og "bygge") og opprett en fil for dine hjelpere.
Her har vi /lib/helpers.rb:
"rubinmodul PrototypingHjelpere def random_image image_tag" # lorem.image ('300x400',: background_color => '333',: color => 'fff') "ende
def random_username "# lorem.first_name # lorem.last_name" slutten "
Deretter må du la config.rb-filen din vite at du vil bruke disse hjelpene:
rubin krever 'lib / helpers' helpers PrototypingHelpers
Boom! Du er klar til å rulle. Generelt vil jeg gå med modulen tilnærmingen med en gang. Det føles mye renere for meg, pluss at du unngår å forurense konfigurasjonsfilen din med for mange ting.
Jeg vil også se på utgangshjelpere og content_for særlig siden de kan være litt forvirrende for nybegynnere. Dette lar deg fange en masse innhold som du kan gi / gjenbruk annet sted. Det er en minature delvis av sorter. Jeg ville personlig gå med delvis mesteparten av tiden, men nå og da når du vil bruke on-off endringer mer kirurgisk, er dette nyttig å vite:
Her er index.html.erb:
"html <% content_for :navigation do %>
<% end %>
... "
Og admin_index.html.erb:
"html <% content_for :admin_navigation do %>
<% end %>
<% content_for :admin_javascript do %> <%= javascript_include_tag “admin” %> <%= javascript_include_tag “some_library” %> <% end %>
... "
Så i layout.erb:
"html
<% if content_for?(:admin_javascript) %> <%= yield_content :admin_javascript %> <% else %> <%= javascript_include_tag "all" %> <% end %> <%= yield %> <%= partial "footer" %>"
Nøkkelen bruker yield_content som setter det samlede innholdet fra den enkelte siden inn i oppsettet - hvis det er funnet. Det er ikke nødvendig å bare bruke dem bare med oppsett heller. Når du trenger å gjøre dette litt mer involvert, bruk content_for? å se etter bestemte innholdsblokker før du setter dem inn. Det er praktisk når du vil lage små tilpasninger for seksjoner som bare er litt forskjellig. Det er flott at du kan lagre dette innholdet litt som en konfigurasjon på de aktuelle sidene selv og "aktiver" den bare når det er nødvendig. Du bør nok ikke bli for smart med disse tingene skjønt.
Et ord om link til hjelper jeg brukte ovenfor. Dette er probaly den du kommer til å mestre inn i. Du legger i hovedsak metoden et navn og en URL eller sti hvor denne koblingen skal peke på. Jeg erstattet den siste delen med en plassholder for korthet.
Nedenfor er en oversikt over hvilke hjelpere som er ute av boksen til din disposisjon. Jeg tror navnene er for det meste selvforklarende og jeg bør ikke gå over hva hver av disse kan hjelpe deg med. Lag et mentalt bokmerke av hva som er der ute og sjekk tilbake med dokumentasjonen hvis de gir deg noen problemer.
Accentsconagua
stikkordlink tilinput_tagfavicon_tagstylesheet_link_tagjavascript_include_tagcontent_forcontent_for?capture_htmlyield_contentconcat_contentform_taglabel_tagselect_tagsubmit_tagfield_set_tagtext_field_tagcheck_box_tagpassword_field_tagavkortepluralizeword_wrapescape_htmlsimple_formatjs_escape_htmltime_ago_in_wordsdistance_of_time_in_wordslorem.datelorem.wordlorem.namelorem.emaillorem.imagelorem.wordslorem.sentencelorem.last_namelorem.paragraphlorem.first_namelorem.paragraphsJeg tror dette er et godt utgangspunkt for å begynne å leke med en leketøyapp. Du bør ha en god følelse av hva Middleman tilbyr og hvordan man navigerer i rammen. I neste del av denne serien tar vi ting videre og dykker litt dypere inn i rammen. Middleman-teamet har virkelig gjort en god jobb med å designe API og å holde ting enkelt.
Forhåpentligvis kan du se nå hvorfor dette rammeverket har fått popularitet, og hvorfor det er et godt valg for alle slags statiske prosjekter.
