Sayfa, Yerleşim, Alan ve Blok: Her sınır ne kazandırır?

WebBlocks CMS’nin temel içerik modeli tek satıra sığar:

Page -> Layout -> Slots -> Blocks

Bu yapı yararlı bir hiyerarşi gibi de gereksiz bir prosedür gibi de görünebilir. Neden sayfayı tek bir bileşen ağacı olarak saklayıp doğrudan oluşturmuyoruz? Bu yaklaşım birçok ürün için geçerlidir. Dört ayrı katman, ancak her biri farklı bir değişiklik türünün sorumluluğunu üstlendiğinde yerini hak eder.

Sayfa, yayımlanabilir bir belge olarak şu sorulara cevap verir: Hangi siteye aittir, her dildeki herkese açık adresi nedir, taslak mı, incelemede mi, yoksa yayımlanmış mı, hangi yerleşimi kullanır ve hangi üst veriler, dosyalar ve revizyon geçmişi ona aittir?

Görünen içerik değiştiğinde bu özellikler korunur. Bir hero alanını değiştirmek, paragrafı taşımak veya galeri eklemek yeni bir yönlendirme kimliği oluşturmamalıdır.

Tersi de yararlıdır. Sayfa taşımak veya çoğaltmak kontrollü bir sayfa işlemi olarak ele alınabilir. Sistem hangi çevirilerin, alanların, sayfaya ait blok ağaçlarının, dosyaların ve revizyon ilişkilerinin birlikte taşınacağını bilir. Sayfa, bir bileşen dizisinin kök düğümünden fazlasıdır.

Yerleşim, sayfanın hangi bölgelere sahip olabileceğini ve bu bölgelerin herkese açık sayfa kabuğuna nasıl bağlanacağını tanımlar. Varsayılan yerleşim üstbilgi, ana içerik ve altbilgi sağlayabilir; dokümantasyon yerleşimi buna kenar çubuğu ekleyebilir.

Yerleşim sıralamayı, semantik kapsayıcı öğeleri, kapsayıcı sınıflarını ve sayfanın body sınıfını tanımlayabilir. İçeriğin oluşturulduğu dış yapının sahibidir. Böylece blokların şu soruyu çözmesi gerekmez: Nasıl bir sayfa kabuğunun içindeyim?

Dokümantasyon kenar çubuğu, bir içerik bloğu tesadüfen kenar çubuğu kapsayıcısı ürettiği için var olmamalıdır. Bu bölge docs yerleşimine aittir. İçine konan bloklar, gizlice sayfa mimarisine dönüşmeden içerik olarak kalır.

Bunun bir bedeli vardır: Yerleşim değiştirmek yalnızca görsel değil, yapısal bir işlemdir. Bu nedenle WebBlocks, yerleşim seçimi değiştiğinde mevcut sayfa alanlarını sessizce silmez veya yeniden yazmaz. Eksik alanlar açık bir işlemle eklenebilir; fazladan alanlar bildirilir ve korunur.

Alan, yerleşimin yapısal sözleşmesini belirli bir sayfaya bağlar. header, main, sidebar ve footer gibi adlar konumdan fazlasını anlatır. Herkese açık sayfa oluşturucu bölge için semantik bir kapsayıcı seçebilir; araçlar da JSON ağacındaki yerini tahmin etmeden bölgeye erişebilir.

WebBlocks sayfa alanının içerik kaynağı açıktır: page bu sayfaya ait blokları, shared_slot aynı siteye ait uyumlu ve yeniden kullanılabilir blok ağacını oluşturur; disabled ise bölgeyi korur ama içinde blok oluşturmaz.

Böylece yeniden kullanım kopya değil, referans olur. Ortak bir üstbilgi bir kez güncellenip ona başvuran tüm sayfalarda gösterilebilir. Geniş etkisi de görünür kalır: Shared Slots kendi revizyonlarına ve yayın iş akışına sahiptir.

Alan kapsayıcısının sahibi hâlâ onu kullanan sayfadır. Shared Slot yalnızca iç blok ağacını sağlar. Böylece yeniden kullanılabilir içerik, onu kullanan sayfaya ikinci bir sayfa kabuğu taşıyamaz.

Bloklar, bir alana yerleştirilen editoryal birimlerdir. Başlık, zengin metin, görsel, gezinme, galeri veya stack ve grid gibi yerleşim yapılarını temsil edebilirler. Desteklenen bloklar alt bloklar içerebildiği için alan içindeki içerik de bir ağaç oluşturabilir.

Asıl sınır, blokların sahip olmadığı şeylerdir. Blok sayfa rotasına, iş akışı durumuna veya dış kabuğa karar vermemelidir. Kendi içeriğine, çevirilerine, ayarlarına, ilişkilerine ve kendisine verilen bölgedeki görüntüleme davranışına sahiptir.

Bu, doğrulamayı kolaylaştırır. Başlık bloğunun sözleşmesi galeriden farklıdır. Otomasyon aracı sınırsız bir sayfa belgesini düzenlemek yerine türlendirilmiş şemaları keşfedebilir. Görüntüleme ve migration süreçleri belirsiz bir veri yığınını çözmek yerine ilişkileri inceleyebilir.

İlişkisel depolama kendiliğinden JSON’dan üstün değildir. Bazı bütünlük kurallarını ve migration işlemlerini daha açık hale getirirken daha fazla tablo ve join getirir. WebBlocks, çoklu site, yerelleştirme, revizyon ve otomasyon akışlarında açık sahiplik önemli olduğu için bu maliyeti kabul eder.

Bir dokümantasyon sitesindeki kurulum sayfasını düşünelim:

Artık her değişikliğin doğal bir sahibi vardır. /docs/installation adresini değiştirmek sayfa çevirisi ve yönlendirme akışına aittir. Yapısal bir bölge eklemek yerleşime aittir. Dokümantasyon gezinmesini değiştirmek kenar çubuğu alanına veya onun Shared Slot’una aittir. Kurulum komutunu düzenlemek ise Code bloğuna aittir.

Hiyerarşi yararlıdır; çünkü hem insanlara hem araçlara değişikliğin hangi katmana ait olduğunu söyler.

Açık mimari, anlaşılır bir editörü garanti etmez. Bir cümleyi düzeltmek için her seferinde Page -> Layout -> Slot -> Block katmanlarını elle dolaşmak gerekiyorsa model iş akışına sızıyordur. Arama, yararlı özetler, doğrudan düzenleme bağlantıları ve mantıklı varsayılanlar, katmanları sistemden silmeden rutin işlerin onları atlamasını sağlamalıdır.

Model gereğinden fazla tasarlanmış da olabilir. Tek sabit şablonu ve birkaç alanı olan bir site, yapılandırılabilir yerleşimlerden veya yeniden kullanılabilir alan ağaçlarından yarar görmeyebilir. Türlendirilmiş bir sayfa modeli veya basit bir Markdown belgesi daha uygun araç olabilir.

Bir katmanın yerini hak edip etmediğini dört soruyla değerlendirebilirsiniz:

1. Ayrı bir değişiklik türünün sorumluluğunu üstleniyor mu?
2. Bu değişiklik bağımsız olarak doğrulanabiliyor mu?
3. Sınır gerçek bir geçersiz durumu önlüyor mu?
4. Rutin düzenleme, tüm karmaşıklığın bedelini ödemeden yapılabiliyor mu?

İlk üç sorunun cevabı hayırsa katman gereksiz bir prosedür olabilir. Dördüncünün cevabı hayırsa mimari doğru olsa da ürün deneyimi hâlâ iyileştirme gerektiriyor olabilir.

Page -> Layout -> Slot -> Block yeni bir buluş olarak sunulmuyor. Bölgeler, bileşenler ve yapılandırılmış içerik CMS ürünlerinde uzun zamandır var.

Amaç açık sahipliktir. Sayfalar kimliğe ve iş akışına, yerleşimler kabuğa, alanlar adlandırılmış konuma ve içerik kaynağına, bloklar ise içeriğe sahiptir.

Birindeki değişiklik diğerlerini de değişmiş gibi davranmaya zorlamadan yapılabiliyorsa bu sınırlar yerini hak eder.

Blok tabanlı bir CMS’de sayfa yapısıyla içerik arasındaki sınırı nerede çizersiniz; editörler için en çok sürtünmeyi hangi sınır yaratır?