Jekyll ile İçerik Modelleme

Bu tam olarak yeni bir konu değil, ancak son zamanlarda ekibimin çalışmasındaki içerik modelleme becerisini tekrar gözden geçirmek için nedenlerim oldu. Deneyimlerimiz, uygulama şeklimizin sınırlarının netleşmeye başladığı bir noktaya ulaştı. En yaygın sorunumuz, insanların kendilerini ve zihinsel modellerini seçilmiş bir platforma ve onun uzlaşımlarına bağlama eğiliminde olmalarıdır .

İnsanlara içeriği nasıl modelleyeceklerini öğretmek yerine, onlara Drupal'da içeriğin nasıl modelleneceğini veya WordPress'te içeriğin nasıl modelleneceğini öğretiyoruz. Ancak, söz konusu içeriğin hangi platformda olacağına bakılmaksızın, kullanıcıların en iyi çıkarlarına odaklanarak yaklaşmayı tercih ederim.

SmashingMag'de Daha Fazla Okuma :

• Jekyll ve GitHub Sayfalarıyla Bir Blog Oluşturun
• Statik Web Sitesi Üreticileri Neden Sonraki Büyük Şeydir?
• İncelenen Statik Web Sitesi Üreticileri: Jekyll, Middleman, Roots, Hugo
• Stil Rehberine Dayalı Geliştirmeyi Otomatikleştirme

Bu düşünce dizisi beni biraz takıntılı hale geldiğim bir fikre geri getirdi, o da şu ki, belirli fikirleri bir müşteriye iletmek için bir eser yaratmamız gerektiğinde, bu eser ne kadar yakınsa süreç neredeyse her zaman daha iyi gider. bir web sitesinin resmi veya diyagramlarla dolu bir PDF yerine gerçek bir web sitesi için mümkündür.

Böylece kendime sorduğum soru şu oldu: İnsanların içeriği platformdan bağımsız bir şekilde hızlı bir şekilde modellemesine ve aynı anda bir müşteriye veya ekibe amacı iletmek için ideal bir yapı oluşturmasına yardımcı olmak için kullanabileceğim bir araç var mıydı?

Üst Düzey Bir İçerik Modelleme Teorisi

Jekyll'e girmeden önce biraz yön değiştirelim. İçerik modelleme tartışmasından tüm kuralları ve platforma özgü dili kaldırabileceğinizi ve onu üç parçalı bir sistem olarak tanımlayabileceğinizi düşünüyorum:

1. Ana fikir bir nesnedir : bir sitede bir arada tutan bir içerik birimi. Örneğin, bir blog yazısı veya bir kişi, bir sitede bir nesne olabilir.
2. Nesneler, onları tanımlayan niteliklere sahiptir . Bir blog gönderisinin bir başlığı, bir içeriği, bir yazarı olabilir. Bir kişinin adı, fotoğrafı, biyografisi olabilir.
3. Nesnelerin, bir sitede nereye varacaklarını belirleyen ilişkileri vardır ve mizanpajların, bir nesnenin hangi niteliklerinin ve nerede kullanıldığını tanımlayan mantığı vardır. Örnek blog gönderisi nesnemiz, yazarı bir kişi olduğu için bir kişi nesnesine bağlıdır. Gönderi sayfasında yazarın adını ve profiline bir bağlantı veriyoruz ve tam biyografilerini profil sayfalarına çıkarıyoruz.

Ana hatlarıyla belirttiğim üst düzey fikirlere saygı duyan, ancak ekibe belirli platformlara özgü fikirler hakkında endişelenmeden uygun gördükleri şekilde nitelikler ve ilişkiler oluşturma özgürlüğü veren bir sistem oluşturmak istedim. Bunun yerine, kullanıcılar için en iyi olanı temel alarak içeriği tanımlamaya odaklanabilirler . Ve Jekyll'in bunu mümkün kılacak özelliklere sahip olduğu ortaya çıktı.

Jekyll'e girin

Jekyll, statik bir bloglama çerçevesidir. Ve yorum kısmına geçmeden önce evet, başlı başına bir platform olarak görmenin doğru olduğunun farkındayım. Ancak, Drupal veya WordPress gibi bir şeye göre birkaç avantajı vardır.

Jekyll sadeliği ciddiye alır. Bir veritabanına sahip değildir, bunun yerine düz dosyalara ve düz eski HTML oluşturan bazı Liquid şablon etiketlerine dayanır. Sıvı sınırlıdır, basittir ve son derece insan tarafından okunabilir. Birisine Liquid etiketleriyle oluşturulmuş bir şablon gösterebileceğimi ve ön uç koduyla biraz deneyime sahip oldukları sürece şablonun ne yaptığını anlayabileceklerini öğrendim.

Bunun güzel yanı, birine bir veritabanını nasıl çalıştıracaklarını, şablonlarını ona nasıl bağlayacaklarını, CMS'lerinin yönetici alanını şablonlarıyla çalışacak şekilde nasıl yapılandıracaklarını vb. göstermek zorunda kalmamamızdır. Bunun yerine, Jekyll'i kurabilir ve bir sunucunun nasıl başlatılacağını öğretebiliriz. Kullanıcı bir Mac kullanıyorsa, bunun sadece ilk denediğimizde işe yarayan iki dakikalık bir süreç olması için mükemmel bir şans var.

Jekyll ayrıca kullanıcının boğazından aşağı çok fazla kural koymaz. Tercih ettiğiniz dosya yapısını ve varlık hattını oluşturma, dosyalar arasında kendi ilişkilerinizi kurma ve en sevdiğiniz şekilde işaretleme yazma özgürlüğüne sahipsiniz. Sahip olduğu birkaç kural, tarzınıza uyacak şekilde kolayca yeniden yapılandırılabilir.

Nesneleri Oluşturmak ve İçermek İçin Koleksiyonları Kullanma

Hâlâ deneysel bir özellik olarak kabul edilse de, Jekyll, tarif ettiğim sistemi oluşturmamıza izin verecek koleksiyonlar denen bir şeye sahiptir.

Temel olarak, bir klasör oluşturursunuz ve onu, oluşturduğunuz nesne türünden sonra adlandırırsınız. Sonra o klasöre dosyalar eklersiniz ve her dosya o koleksiyondaki bir nesneyi temsil eder. Nesneleriniz olduğunda, her dosyanın başında YAML kullanarak onlar için nitelikler oluşturabilirsiniz. YAML, bilgileri kolayca depolayan anahtar/değer çiftlerini tanımlamanıza izin veren bir sözdizimidir.

Bu sistemin güzel yanı, inanılmaz derecede basit olmasıdır. Her şey insan tarafından okunabilir ve yeni bir kullanıcının öğrenmesi kolay bir şekilde çalışır. Nihai sistemde birinin içeriği ve ilişkileri nasıl oluşturması gerektiğine dair çok sayıda belge oluşturmak yerine, onu oluşturabilirsiniz. Tasarımcılar, tasarım sistemlerini planlayabilmeleri için nesnelerin ve niteliklerinin ne olduğunu görebilirler. Ön uç geliştiriciler, biçimlendirmelerini ve CSS'lerini tasarlamak için işleyen bir web sitesine sahiptir.

Belirli bir sistemi veya konvansiyonu kullanmak zorunda olmadıkları için, proje için tercih ettikleri veya son platformun konvansiyonlarını kullanabilirler. Ve arka uç geliştiriciler, şablonlar ve mantık üzerinden, kullanmaya karar verdikleri herhangi bir CMS'ye aktarırken tasarımcının amacını kolayca belirleyebilirler, çünkü zaten onlar için yazılmıştır.

Nesneler ve İlişkilerle Basit Bir Site Oluşturalım

Bu fikri bir dönüş için alacaksak, basit bir Jekyll sitesi kurmamız ve ardından nesnelerimizi ve ilişkilerimizi oluşturmamız gerekecek. Nihai ürünü görmek istiyorsanız, bu GitHub deposundan alabilirsiniz. (Not: Bunun bir kısmı için terminali kullanmanız gerekecek, ancak bu oldukça basit bir kullanım, söz veriyorum.)

Jekyll'ı Yükleme

Mac kullanıyorsanız, bu oldukça kolaydır. Ruby zaten kurulu, sadece Jekyll'i kurmanız gerekiyor. Terminali açın ve şunu yazın:

 gem install jekyll

Bu, Jekyll Ruby gem ve bağımlılıklarını kuracaktır. Çalıştırmayı bitirdiğinde, işte bu kadar: Jekyll'ınız var.

Sitenizi Kurma

Şimdi bir Jekyll iskelesini başlatmamız gerekiyor. Tüm web projelerimi Mac'imde ana klasörde Sites adlı bir klasörde saklıyorum. Bu yüzden önce onunla gezinmem gerekiyor:

 cd ~/Sites

Sonra bu komutla uygun dosya ve yapıya sahip bir klasör oluşturabilirim:

 jekyll new my-new-site

“Yeni sitem”i projenize ne ad vermek istiyorsanız onu değiştirebilirsiniz. Alacağınız şey, bu ada sahip bir klasör ve içindeki tüm doğru dosyalar.

Finder'ı açın ve içinde ne olduğunu görmek için yeni klasörünüze gidin. Bunun gibi bir şey görmelisiniz:

Jekyll'in sunduğu her şeye ihtiyacımız olmadığı için önce birkaç dosya ve klasörü sileceğiz. /_includes , /_posts , /_sass , about.md ve feed.xml öğelerini atalım .

Yapılandırma

Şimdi site çapında yapılandırmalarımızı ayarlayacağız. _config.yml dosyasını açın. İçeride bir sürü tanıtım malzemesi var. Bunu silip tercih ettiğim konfigürasyonlarla değiştireceğim. İşte bu proje için yeni konfigürasyon:

 permalink: pretty collections: projects people

URL'lerimin /path/to/file.html yerine /path/to/file/ gibi görünmesi için yaptım ki bu sadece kişisel bir tercihtir. Ayrıca iki koleksiyon oluşturdum: projeler ve insanlar . Yapılandırma dosyasına herhangi bir yeni koleksiyon eklenmelidir.

Artık projemde bu koleksiyonlar için klasörler oluşturabilirim:

Jekyll'in onlarla ne yapacağını bilmesi için klasör adları _ (alt çizgi) karakteriyle başlamalıdır.

Bazı Nesneler Yapmak

Yapacağımız ilk nesneler insanlarımız olacak. Bu dosyaları oluşturmak için Markdown'ı kullanacağız, böylece güzel ve temiz olacaklar ama yine de uygun, anlamsal HTML üretecekler. Amerikan tarihinden rakamlar için bazı dosyalar hazırladığımı görebilirsiniz (bu, bir aydır durmadan Hamilton'ı dinlememle ilgili olabilir veya olmayabilir):

Bir kişi için dosyamıza koyacağımız nitelikler şöyle olacaktır:

 --- object-id: first-name: last-name: job: listing-priority: wikipedia-url: ---

Daha sonra bu nesnelerden herhangi birine özel olarak atıfta bulunmak için object-id kullanacağız. Çeşitli yerlerde hangi kombinasyonun kullanılacağını seçebilmemiz için adı ve soyadını ayıracağız (sisteminiz bunu gerektiriyorsa) ve ne yaptıklarını tanımlamak için job kullanacağız. ('Başlık'tan kaçınıyorum çünkü bu zaten Jekyll'deki sayfaların varsayılan olarak sahip olduğu bir değişkendir.) Ayrıca, her bir kişiyi kaprislerine göre sıralamama izin verecek olan listeleme önceliği için bir öznitelik ekledim, ama aynı zamanda buna göre de sıralayabilirsiniz. alfabetik veya sayısal gibi bazı yerleşik yöntemler. Son olarak, kişinin Wikipedia sayfasına bağlantı için bir alanımız var.

Tüm bunlar, onu YAML ön maddesi olarak tanımlamak için üstte ve altta üç kısa çizgi arasında bulunur. Her biyografinin içeriği YAML'den sonra gelecek ve keyfi bir miktar ve HTML yapısı olabilir (ancak her şeyi güzel ve temiz tutmak için Markdown biçimlendirmesini kullanacağız).

Tamamen doldurulmuş bir kişi nesnesi şöyle görünür (içerik netlik için kısaltılmıştır):

 --- object-id: alexander-hamilton first-name: Alexander last-name: Hamilton job: 1st United States Secretary of the Treasury listing-priority: 1 wikipedia-url: https://en.wikipedia.org/wiki/Alexander_Hamilton --- Alexander Hamilton (January 11, 1755 or 1757 – July 12, 1804) was...

Ve işte bir proje nesnesi (içerik netlik için kısaltılmıştır):

 --- object-id: united-states-coast-guard title: United States Coast Guard featured: true featured-priority: 2 listing-priority: 1 architect-id: alexander-hamilton wikipedia-url: https://en.wikipedia.org/wiki/United_States_Coast_Guard --- The United States Coast Guard (USCG) is...

Bunun birkaç farklılığı var. Öne çıkan bir featured ayarladım. Bir proje öne çıkarsa, ana sayfada listelenir. Tüm projeler projeler sayfasında listelenecektir. Ayrıca her yerleşim için tercih ettiğimiz sıralama düzenine sahibiz. Ve projeyi oluşturan kişinin id bir referans ekledik, böylece onlara daha sonra doğrudan başvurabiliriz.

Nesnelerimizden Sayfalar Oluşturma

_config.yml dosyamı değiştirerek bu nesnelerin her biri için sayfalar oluşturabilirim.

 permalink: pretty collections: projects: output: true people: output: true

Her koleksiyonda output: true ayarı, içindeki her nesne için bir sayfa oluşturulmasına neden olur. Ancak nesnelerimizin dosyalarında içerik bulunmadığından, şu anda herhangi bir veri çıkışı yapmıyorlar, bu da sadece boş sayfalar alacağımız anlamına geliyor. Bunu bizim için yapacak bir düzen şablonu oluşturalım.

Bu dosya _layouts klasörüne gidecek. Ama önce, ilgilenmemiz gereken bir default.html dosyamız var. Bu, tüm HTML dosyalarımızda tutarlı olan herhangi bir işaretlemeyi tutacaktır.

 <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> <title>{{ page.title }}</title> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <link rel="stylesheet" href="/css/styles.css" /> </head> <body> <header role="banner"> ... </header> <div role="main"> <div class="container"> {{ content }} </div> </div> <footer role="contentinfo"> ... </footer> </body> </html>

Şuna benzeyen bir Liquid etiketi göreceksiniz: {{ content }} . Jekyll tarafından bir sayfaya dönüştürülen her dosyanın kendisi için belirlenmiş bir şablona ihtiyacı vardır. Şablonunu belirttiğinizde, o dosyadaki içerik, yerleşim şablonundaki {{ content }} etiketinin konumuna işlenir. Artık her sayfada olacak şeyleri tekrar etmemize gerek yok.

Ardından, kişi nesnelerimiz için benzersiz bir yerleşim şablonu oluşturacağız. Bu şöyle görünecek:

 --- layout: default --- <header class="intro person-header"> <h1>{{ page.first-name }} {{ page.last-name }}</h1> <h2>{{ page.job }}</h2> </header> <div class="person-body"> {{ page.content }} <a href="{{ page.wikipedia-url }}">Read more about {{ page.first-name }} {{ page.last-name }} on Wikipedia</a> </div>

Bu dosya, kodunun varsayılan yerleşim şablonuna ekleneceğini ve ardından biçimlendirmesinin kişi nesne dosyalarındaki verilerden doldurulacağını belirtir.

Son adım, her bir kişi nesnesinin, person.html düzen dosyasını kullandığını belirttiğinden emin olmaktır. Normalde, bunu kişisel dosyalarımızdaki YAML'ye şöyle eklerdik:

 --- object-id: first-name: last-name: job: listing-priority: wikipedia-url: layout: person ---

Ancak, nesne dosyalarımdaki verilerin yalnızca içerik modeliyle ilgili öznitelikleri içermesini tercih ederim. Neyse ki, _config.yml dosyamı bunu benim için halledecek şekilde değiştirebilirim:

 exclude: - README.md permalink: pretty collections: projects: output: true people: output: true defaults: - scope: type: projects values: layout: project - scope: type: people values: layout: person

Artık sitem, proje koleksiyonundaki herhangi bir nesnenin proje düzeni şablonunu kullanması gerektiğini ve kişi koleksiyonundaki herhangi bir nesnenin kişi düzenini kullanması gerektiğini biliyor. Bu, içerik nesnelerimi güzel ve temiz tutmama yardımcı oluyor.

Bir Liste Sayfasında Nesneleri Görüntüleme

Nesnelerimiz için sayfalar çıkarmayı seçsek de seçmesek de, onları listeleyebilir ve farklı parametrelere göre sıralayabiliriz. Tüm projelerimizi bir sayfada şu şekilde listeleyeceğiz:

 --- layout: default title: Projects --- <header class="intro"> <h1>{{ page.title }}</h1> </header> <div class="case-studies-body"> <ul class="listing"> {% assign projects = site.projects | sort: 'listing-priority' %} {% for project in projects %} <li> <h2><a href="{{ project.url }}">{{ project.title }}</a></h2> {{ project.content }} </li> {% endfor %} </ul> </div>

Yaptığımız, listemizi içine koymak için bir <ul> oluşturmak. Ardından, sayfada projects adında bir değişken oluşturup tüm proje nesnelerimizi ona atadık ve her birinde oluşturduğumuz listing-priority değişkene göre sıraladık. Son olarak, projects değişkenimizdeki her proje için, her dosyadaki özniteliklerden gelen verileri içeren bir <li> çıktısı alırız. Bu bize, benzersiz sayfalarına bağlantılar içeren proje nesnelerimizin son derece kontrol edilebilir bir listesini verir.

Ana sayfada, tüm projeleri görüntülemek yerine yalnızca öne çıkanlarımızı göstereceğiz:

 <ul class="listing"> {% assign projects = site.projects | where: "featured", "true" | sort: 'featured-priority' %} {% for project in projects %} <li> <h3>{{ project.title }}</h3> <a href="{{ project.url }}">Learn about {{ project.title }}</a> </li> {% endfor %} </ul>

Özellik özelliği true olarak ayarlanmış herhangi bir proje nesnesi bu sayfada işlenecek ve featured çıkan projeler için belirlediğimiz özel öncelik sırasına göre sıralanacaktır.

Bunlar nesnelerin nasıl çıktı alınacağına ve sıralanacağına dair oldukça basit örneklerdir, ancak içeriği düzenlemek için yaratabileceğimiz farklı yetenekleri gösterirler.

Belirli Bir Nesneye Bağlama

İnşa edeceğimiz son özellik, belirli bir nesneye bağlanmaktır. Bu, bir yazarı bir blog gönderisine veya benzer bir şeye bağlarsanız yapmak isteyebileceğiniz bir şeydir. Bizim durumumuzda, genellikle ilişkili oldukları projeye bir kişiyi ekleyeceğiz. Hatırlarsanız, proje nesnemizin bir architect-id özniteliği var ve çalışanlarımızın her birinin bir object-id özniteliği var. Bu özellikleri kullanarak doğru kişiyi belirli bir projeye ekleyebiliriz.

İşte proje düzeni şablonumuz:

 --- layout: default --- {% assign architect = site.people | where: "object-id", page.architect-id | first %} <header class="intro project-header"> <h1>{{ page.title }}</h1> <p>Architected by: <a href="{{ architect.url }}">{{ architect.first-name }} {{ architect.last-name }}</a></p> </header> <div class="project-body"> {{ page.content }} <a href="{{ page.wikipedia-url }}">Read more about {{ page.title }} on Wikipedia</a> </div>

Satır 4, architect adlı bir değişken oluşturur ve bir projedeki architect-id özniteliğiyle eşleşen object-id sahip tüm insan nesnelerini arar. Yalnızca bir sonucun döndürülmesi için object-id s atamalıyız, ancak yalnızca bir yanıt aldığımızdan ve bir öğe listemiz yerine ona başvurduğumuzdan emin olmak için, | first | first olarak {% assign %} Liquid etiketimizin sonunda. Bu, koleksiyonlardaki nesnelerin başlangıçta benzersiz kimliklere sahip olmadığı bir Jekyll sınırlamasını ortadan kaldırır. Veri adı verilen ve benzersiz kimliklere izin veren başka bir özellik daha vardır, ancak bu, kolayca sayfa çıktısı vermez veya bize nesnelerimizi sıralama yeteneği vermez; koleksiyonların sınırlarını aşmak, istediğimiz işlevselliği elde etmenin daha kolay ve temiz bir yoluydu.

Artık sayfanın o projenin mimarını temsil eden benzersiz bir nesnesi olduğuna göre, özelliklerini mimarın adı ve Wikipedia sayfasının URL'si gibi şeylerle çağırabiliriz. işte! Benzersiz kimlik ile nesnelere kolay bağlantı.

Toplama

Jekyll belgelerini daha ayrıntılı olarak inceleyerek oluşturulabilecek bazı başka harika özellikler de var, ancak burada sahip olduğumuz şey, iyi bir içerik modelleme prototipinin temelleri: farklı türde nesneleri tanımlama yeteneği, bu nesnelere eklenen nitelikler, ve belirli nesneleri herhangi bir yerden aramamıza izin veren kimlikler. Ayrıca, nesnelerimizi çeşitli yerlerde şablonlamak ve çıktı almak için oldukça esnek bir mantık elde ediyoruz. Hepsinden iyisi, tüm sistem basit ve insan tarafından okunabilir ve gerekirse başka yerlerde kullanılmak üzere düz HTML çıktısı verir.

İletişim amacıyla, artık sistemi bir dizi diyagram içeren bir PDF'den daha iyi tanımlayacak, platformdan bağımsız tıklanabilir bir prototipimiz (gerçek bir web sitesi) var. Yeni şeyler öğrendikçe ve uyum sağlamamız gerektiğinden, içerik modelimizi anında değiştirebiliriz. Tasarımcı ve geliştiriciyi, kalıplarını ve ön uç mimarisini oluşturmaları için sisteme alabiliriz çünkü kullanmak istedikleri herhangi bir işaretlemeyi ve CSS'yi kabul edecektir. Hatta bir GitHub GUI veya Prose.io, GitHub Pages, CloudCannon veya Netlify gibi görsel bir düzenleyicinin kullanılmasına izin veren bir barındırma platformu aracılığıyla erişimle ayarlayarak içerik editörlerini bile buna dahil edebiliriz.

Ve bunların hiçbiri bir kişiyi platforma özgü çalışma yöntemlerini öğrenmeye bağlamaz, bunun yerine teknolojiye değil kullanıcılara odaklanan kavramsal bir düzeyde çalışmasına izin verir.