Szablony Jekylla używające płynnych bloków/dziedziczenia typu Django

Dostaję się do Jekyll w wielkim stylu i chciałbym go używać jako ogólnej platformy programistycznej, ale podążam wbrew ograniczeniom języka szablonów Liquid. , w szczególności jego różnica z szablonem Django.Szablony Jekylla używające płynnych bloków/dziedziczenia typu Django

Odkryłem klejnotowy spadek cieczy, który dodaje najważniejszą składnię Extends i Block z Django. Ten blogu rozciąga gem dodatkowo dostosowane system plików Jekyll'a: http://www.sameratiani.com/2011/10/22/get-jekyll-working-with-liquid-inheritance.html

Problemem jest to, że nie wydaje się, aby wdrożyć bloków w dokładnie ten sam sposób, co robi Django istocie czyni gem bezużyteczne.

Mam dwa "układy" jekyll nazwane - ze względu na zrozumienie - parent.html i child.html. Żadne z nich nie zawiera sekcji YAML.

nadrzędna

<html> 
{% block foo %} {% endblock %} 
</html>

Dziecko

{% extends _layouts/parent.html %} 
{% block foo %} 
    <div> 
    Bar comes next: 
    {% block bar %} {% endblock %} 
    </div> 
{% endblock %}

A potem Mam stronę Jekyll, który zawiera sekcję YAML tak:

--- 
title: test 
--- 

{% extends _layouts/child.html %} 
{% block bar %}My title is {{ page.title }} {% endblock %}

czego można oczekiwać:

<html> 
    <div> 
    Bar comes next: 
    My title is test 
    </div> 
</html>

Co dostaję:

<html> 
    <div> 
    Bar comes next: 
    </div> 
</html>My title is test

Wydaje się coś nie udaje się leczyć bloki w mojastrona.html jako kwalifikujące się do umieszczania w odpowiednich miejscach rodzica/dziecka, choć to oczywiście wciąż robi coś.

Nie jestem programistą ruby i jestem całkiem nowy w Jekyll, potrzebuję więc pomocy w określeniu, która część tego stosu zawodzi. Problemy z dziedziczeniem cieczy na github sugerują, że inni doświadczają tego problemu z zagnieżdżaniem bloku: https://github.com/danwrong/liquid-inheritance/issues/3

Próbowałem kilku rozwidleń płynności - wiele z nich najwyraźniej rozwiązuje ten problem, ale żaden z nich nie rozwiązuje tego problemu.

Czy to, co robię, robię zasadniczo niemożliwe? Wygląda na to, że mam co najmniej 85% drogi, a ostateczna wersja wymaga naprawy.

Źródło

2012-10-26 xcession

Nie jestem pewien, czy kiedykolwiek zadziała w Jekyll. Może się mylę, ale tutaj jest moje rozumowanie:

Każda strona jest renderowane przy użyciu do_layout w https://github.com/mojombo/jekyll/blob/master/lib/jekyll/convertible.rb

To działa rekursywnie - przetwarza zawartość strony, a następnie przetwarza układ na stronie, a następnie układ, który layout i tak dalej i tak dalej, przekazując zmienne YAML w górę łańcucha (więc są zawsze dostępne w szablonach nadrzędnych jako {{page.whatever}}).

Oznacza to, że jedyne rzeczy, które można pominąć, to wartości YAML i niezależnie od wartości "zawartości" po przetworzeniu przez Liquid. Nie wiem, jak to się robi gdzie indziej, ale wydaje się to nie do pogodzenia z ideą bloków, ponieważ wymagałoby to przekazania osobno dwóch bloków.

Zasadniczo wydaje mi się, że problem polega na tym, że Jekyll ma już prostą formę dziedziczenia - poprzez atrybut "layout", który można nadać układowi. Zasadniczo uważam, że jest to zgodne z szablonami płynnymi.

Wszystko, co powiedziałem, nie jestem pewien, czy wyczerpałeś limity używania logiki YAML, _includes i template. Jeśli jesteś w momencie oddania Django stylu bloki do zawartości, dlaczego nie po prostu zrobić coś takiego:

Treść:

--- title: some title secondary_content: | Here is some *secondary* content that will be [markdownified](http://example.com). It can run to multiple lines and include * Lists * Good things * Etc --- And here is the main content, as per usual

Szablon:

<html> <article> <h1>{{ page.title }}</h1> {{ content }} </article> <aside> {{ page.secondary_content | markdownify}} </aside>

Jeśli chciał zachować czyste szablony i mieć różne treści dla różnych typów stron, można użyć różnych obejmuje:

Szablon:

<aside> {% include sidebar_negotiation.html %} </aside>

_includes/sidebar_negotiation.html:

{% if page.type = 'foo' %} {% include sidebar_foo.html %} {% else if page.type = 'bar' %} {% include sidebar_bar.html %} {% endif %}

a następnie umieścić swoje konkretne rzeczy typu strona w tych plikach. Oczywiście można go zawrzeć bezpośrednio, ale prawdopodobnie dobrze jest je rozrysować. Te załączniki otrzymają wszystkie zmienne w YAML.

Jeśli nic z tego nie jest wygraną, zawsze możesz spróbować Hyde: http://hyde.github.com/, która jest napisana w Pythonie, używa Jinja2 (w zasadzie szablony Django ++) i robi to samo.

Źródło

2012-10-31 20:51:39 heliotrope

Po prostu przetestowałem i okazało się, że chociaż dziedziczenie płynów działa poprawnie na * układach *, to kończy się niepowodzeniem, gdy dojdziesz do rzeczywistych stron * zawartości *, co moim zdaniem jest tam, gdzie powstaje twój problem (który - jak już powiedziałem - kiedy przejdziesz do określonego fragmentu treści, nadal jestem przekonany, że YAML jest lepszym sposobem na dołączanie treści pomocniczych niż umieszczanie bloków w obszarze treści ... – heliotrope

YAML to zdecydowanie najlepszy sposób na zrobienie tego, ale staje się niepotrzebnie skomplikowane, jeśli większość twoich treści to po prostu duże bloki nierozłącznego kodu HTML. Oprócz tytułu, nie ma zbyt wielu nieprzetworzonych danych, których naprawdę potrzebuję _proces_. Wystarczy wstawić duże fragmenty kodu HTML do , nieciągłe regiony strony. Opisywanie tego HTML-a w YAML jest niezdarne i nie do zniesienia. – xcession

Szablony Jekylla używające płynnych bloków/dziedziczenia typu Django

Odpowiedz

Powiązane problemy