Jaka jest zaleta szablonu bez logiki (takiego jak wąsy)?

101

Niedawno natknąłem się na wąsy, które rzekomo są szablonem pozbawionym logiki .

Jednak nie ma żadnego wyjaśnienia, dlaczego jest zaprojektowany w sposób pozbawiony logiki. Innymi słowy, jaka jest zaleta szablonu bez logiki?

Morgan Cheng
źródło

Odpowiedzi:

107

Innymi słowy, zapobiega to strzeleniu sobie w stopę. W dawnych czasach JSP bardzo często zdarzało się, że pliki JSP były posypane kodem Javy, co znacznie utrudniało refaktoryzację, ponieważ kod był rozproszony.

Jeśli zapobiegniesz logice w szablonach przez projekt (tak jak robią to wąsy), będziesz zobowiązany do umieszczenia logiki w innym miejscu, aby Twoje szablony były uporządkowane.

Kolejną zaletą jest to, że jesteś zmuszony myśleć w kategoriach oddzielenia obaw: twój kontroler lub kod logiczny będzie musiał wykonać masowanie danych przed wysłaniem danych do interfejsu użytkownika. Jeśli później zmienisz szablon na inny (powiedzmy, że zaczniesz używać innego silnika szablonów), przejście będzie łatwe, ponieważ musisz tylko zaimplementować szczegóły interfejsu użytkownika (ponieważ w szablonie nie ma logiki, pamiętaj).

Miguel Ping
źródło
30
Dlaczego więc to dobrze, że kod kontrolera MUSI masować dane w dokładnie takiej formie, jaka jest potrzebna do przedstawienia danych w określony sposób? Dlaczego to dobrze, że zmiana prezentacji często wymaga zmiany kodu kontrolera? To wydaje mi się złe. Pomyślałem, że jednym z celów języka szablonów było oddzielenie logiki kontrolera od logiki prezentacji. Głupi szablon, który nie może podejmować żadnych decyzji, wymusza powrót logiki prezentacji do kodu kontrolera. W organizacjach, w których inna osoba pracuje nad prezentacją, nie mogą samodzielnie wykonywać swojej pracy.
jfriend00
8
Nie powinieneś przygotowywać danych do wglądu w swoim kontrolerze. Kontroler służy do sterowania przepływem aplikacji. Zamiast tego należy utworzyć klasę prezentera, która przekształci model w model widoku, który jest następnie używany przez widok. Model widoku to model interfejsu użytkownika, który jest niezależny od modelu będącego częścią logiki biznesowej. Polecam do obejrzenia „Clean Architektury i Wzornictwa” Talk Robert „Bob” Wujek Martin: youtu.be/asLUTiJJqdE
ragol
1
Wymusza pewną logikę prezentacji w kontrolerze, ale pomaga to w pomieszaniu różnych warstw prezentacji. Jeśli chcesz, aby podobne dane były prezentowane jako JSON, HTML lub XML, nie powinieneś przekręcać danych w 100% w szablonie HTML. To spowodowałoby, że JSON i XML miałyby własną logikę wyświetlania. Centralizujesz 80% logiki wyświetlania w kontrolerze, a pozostałe 20% osadzasz w lambdach i filtrach.
chugadie
65

Mam wrażenie, że moim zdaniem jestem prawie sam, ale stanowczo jestem w przeciwnym obozie. Nie wierzę, że możliwe mieszanie logiki biznesowej w twoich szablonach jest wystarczającym powodem, aby nie wykorzystywać pełnej mocy twojego języka programowania.

Zwykłym argumentem przemawiającym za szablonami bez logiki jest to, że jeśli masz pełny dostęp do swojego języka programowania, możesz mieszać logikę, która nie ma miejsca w szablonie. Uważam, że jest to podobne do rozumowania, że ​​do krojenia mięsa należy używać łyżki, ponieważ można skaleczyć się nożem. To bardzo prawda, ale będziesz o wiele bardziej produktywny, jeśli użyjesz tego drugiego, choć ostrożnie.

Weźmy na przykład pod uwagę następujący fragment szablonu wykorzystujący wąsy :

{{name}}:
<ul>
  {{#items}}
    <li>{{.}}</li>
  {{/items}}
</ul>

Rozumiem to, ale uważam, że następujące elementy ( podkreślenie ) są znacznie prostsze i bardziej bezpośrednie:

<%- name %>:
<ul>
<% _.each(items, function(i){ %>
  <li><%- i %></li>
<% }); %>
</ul>

Biorąc to pod uwagę, rozumiem, że szablony bez logiki mają zalety (na przykład mogą być używane z wieloma językami programowania bez zmian). Myślę, że te inne zalety są bardzo ważne. Po prostu nie sądzę, że ich pozbawiona logiki natura jest jedną z nich.

ćwiek
źródło
135
Dziwię się, że wydaje Ci się, że szablon podkreślenia jest prostszy… wydaje mi się o wiele mniej czytelny. Tylko opinia :-)
Ben Clayton
9
@ ben-clayton Zgadzam się, że pierwsza składnia jest ładniejsza i być może bardziej czytelna. Jednak jest to złożoność, do której zmierzam, kiedy mówię „proste”.
brad
1
Czasami użycie wyrażenia trójskładnikowego jest odpowiednie w szablonie bez względu na posiadaną logikę. A co, jeśli chcę wyświetlić liczbę elementów w tablicy? Nie wiem, jak mogłem używać wąsów, wydaje się, że brakuje takich rzeczy.
Paul Shapiro,
5
@PaulShapiro Możesz wygenerować liczbę elementów w tablicy poza szablonem i zapisać ją w osobnej zmiennej.
Seun Osewa
4
@brad, szablon podkreślenia wprowadził dziurę w XSS: namei itemsmoże zawierać JavaScript.
Matthew
28

Wąsy są pozbawione logiki?

Czy to nie jest:

{{#x}}
  foo
{{/x}}
{{^x}}
  bar
{{/x}}

Całkiem podobny do tego?

if x
  "foo"
else
  "bar"
end

I czy nie jest to całkiem podobne do (czytaj: prawie definicji) logiki prezentacji?

pje
źródło
17
Tak, jeśli tylko oceniasz prawdziwość obiektu, ale próba zrobienia czegoś bardziej skomplikowanego nie jest możliwa ( if x > 0 && x < 10) ... Tak więc, chociaż możliwe jest użycie Wąsów z logiką lub bez, to zależy od Ciebie. W końcu to tylko narzędzie.
Tom Ashworth
5
Patrzysz na to w niewłaściwy sposób. Tylko dlatego, że możesz zrobić kilka rzeczy w języku, który nie jest dokładnie zgodny z jego ogólnym paradygmatem, nie oznacza, że ​​język nie jest z tego paradygmatu. Możesz napisać kod imperatywny w Javie lub Haskell, ale nie powiedziałbyś, że Java nie jest językiem OO, a Haskell nie jest językiem funkcjonalnym. Spójrz na to, co język pozwala ci łatwo robić i do czego prowadzi, aby zobaczyć, jaki to jest język.
cjs
@ CurtJ.Sampson, twoja analogia miałaby sens, gdyby Java sprzedawała się jako „bezfunkcjonalna” lub gdyby Haskell sprzedawał się jako „zorientowany obiektowo”. Ta odpowiedź pokazuje, że określenie „bez logiki” jest w najlepszym razie mylące.
Corey
1
Myślę, że zgadzasz się ze mną, że kiedy nazywamy język „funkcjonalnym”, mamy na myśli „dążenie do funkcjonalnego”. Nie zgadza się, że definiuję „bez X” jako „oddalający się od X”, podczas gdy ty definiujesz to jako „całkowicie niezdolne do X”.
cjs
13

Szablon pozbawiony logiki to szablon zawierający dziury do wypełnienia, a nie sposób ich wypełnienia. Logika jest umieszczana w innym miejscu i odwzorowywana bezpośrednio na szablon. To oddzielenie obaw jest idealne, ponieważ wtedy szablon można łatwo zbudować z inną logiką, a nawet z innym językiem programowania.

Z podręcznika wąsów :

Nazywamy to „bez logiki”, ponieważ nie ma instrukcji if, klauzul else ani pętli for. Zamiast tego są tylko tagi. Niektóre tagi są zastępowane wartością, inne niczym, a inne serią wartości. W tym dokumencie wyjaśniono różne typy tagów Mustache.

Jeremy
źródło
6
Opis jest nieco wyrafinowany, ponieważ sekcje działają raczej jak warunkowe i pętle, tylko bardzo ograniczone. Możliwość odwoływania się do wywołań w skrócie pozwala również przekształcić sekcje w podstawowy język programowania. Mimo to, przynajmniej utrudnia to podążanie tą drogą, a nie zachęca.
Tom Anderson,
1
Jasne, ale system szablonów bez bloków dla warunków i iteracji byłby stosunkowo bezużyteczny. Sam szablon nie określa, do czego służy blok ani jak jest obsługiwany.
Jeremy
12

Drugą stroną medalu jest to, że w desperackiej próbie utrzymania logiki biznesowej poza prezentacją, w końcu umieszczasz w modelu dużo logiki prezentacji. Typowym przykładem może być to, że chcesz umieścić „nieparzyste” i „parzyste” klasy w naprzemiennych wierszach tabeli, co można zrobić za pomocą prostego operatora modulo w szablonie widoku. Ale jeśli twój szablon widoku nie pozwala ci tego zrobić, to w danych modelu musisz nie tylko zapisać, który wiersz jest nieparzysty lub parzysty, ale w zależności od tego, jak ograniczony jest twój silnik szablonu, może być nawet konieczne zanieczyszczenie modelu z nazwami aktualnych klas CSS. Widoki powinny być oddzielone od modeli, kropka. Ale modele powinny być również niezależne od widoku i właśnie o tym zapomina wiele z tych silników szablonów „bez logiki”. Logika działa w obu miejscach,faktycznie robi, aby prawidłowo zdecydować, dokąd zmierza. Czy chodzi o prezentację, czy o biznes / dane? Chcąc mieć w 100% nieskazitelny widok, zanieczyszczenie ląduje w innym mniej widocznym, ale równie nieodpowiednim miejscu.

Istnieje rosnący ruch z powrotem w innym kierunku i miejmy nadzieję , że sprawy skupią się gdzieś na bardziej rozsądnym poziomie pośrednim.

mattmc3
źródło
6
Muszę się z tobą nie zgodzić. Logika prezentacji dla szablonów bez logiki nie jest umieszczana w modelu, ale w widoku, do którego należy. Widok pobiera surowe dane modelu i w razie potrzeby masuje (dodając adnotacje do nieparzystych / parzystych wierszy itp.), Aby przygotować go do prezentacji.
acjay
1
Dlaczego widoki nie mogą być czymś więcej niż szablonami i zawierać kod do masowania danych dla szablonu?
LeeGee,
1
acjohnson55 - Zgadzam się z tobą co do tego, gdzie to powinno iść (zobacz), ale szablony pozbawione logiki często temu zapobiegają. @LeeGee - Myślę, że istnieje ostry sprzeciw wobec zbyt dużej logiki w widokach, ale sprawy poszły zbyt daleko w innym kierunku, aby uniemożliwić nawet logikę specyficzną dla prezentacji w widokach.
mattmc3
4
Wiem, że jestem spóźniony na imprezę, ale n-ty element CSS (nieparzysty) powinien być używany do zmieniania kolorów wierszy.
DanRedux
1
Nie ma nic złego w posiadaniu pośredniego obiektu prezentacji utworzonego przez widok z modeli i kolekcji lub jakichkolwiek innych danych. W ten sposób widoki tworzą dane prezentacji, które są łączone z szablonem w celu renderowania widoku.
wprl
11

Sprawia, że ​​szablony są bardziej przejrzyste i zmusza do zachowania logiki w miejscu, w którym można ją odpowiednio przetestować jednostkowo.

bałwan
źródło
2
Czy możesz to wyjaśnić bardziej szczegółowo?
Morgan Cheng,
29
Poświęć trzy miesiące na pracę nad systemem przy użyciu logicznego języka szablonów, takiego jak JSP, z programistami, którzy nie są gorliwi w oddzielaniu logiki od prezentacji. Przekonasz się, że zbudujesz system, który zasadniczo ma programowanie na stronie - arytmetykę układu tabeli, warunki warunkowe dotyczące wyświetlania informacji o cenach i tak dalej. Języki tworzenia szablonów są bardzo słabymi językami programowania, więc jest to koszmar rozwoju i konserwacji. Coś takiego jak Mustache nie pozwala ci wejść w tę sytuację w pierwszej kolejności.
Tom Anderson
Jeśli logika ma postać funkcji, może być używana przez system mikro-szablonów, który obsługuje wbudowaną logikę i jest testowany jednostkowo. Wydaje mi się, że najgorszym pomysłem są „pomocnicy” kierownicy (patrz spin.atomicobject.com/2011/07/14/… „Zaawansowane użycie”) - wydaje mi się, że nie da się ich przetestować jednostkowo, ponieważ znajdują się w skrypcie / tagi typu / tekstowe zamiast zwykłych starych tagów skryptowych (/ type / javascript)
Dexygen
8

Ta rozmowa sprawia wrażenie, jakby średniowieczni mnisi zastanawiali się, ile aniołów zmieści się na końcu szpilki. Innymi słowy, zaczyna wydawać się religijny, daremny i nieprawidłowo skoncentrowany.

Następuje mini-rant (nie krępuj się zignorować):

Jeśli nie chcesz kontynuować czytania… Moja krótka odpowiedź na powyższy temat brzmi: Nie zgadzam się z szablonami pozbawionymi logiki. Myślę o tym jako o programowej formie ekstremizmu. :-) :-)

Teraz mój rant trwa pełną parą: :-)

Myślę, że kiedy doprowadzasz wiele pomysłów do skrajności, wynik staje się absurdalny. Czasami (np. W tym temacie) problemem jest to, że doprowadzamy „zły” pomysł do skrajności.

Usunięcie całej logiki z tego widoku jest „niedorzeczne” i jest złym pomysłem.

Cofnij się na chwilę.

Pytanie, które musimy sobie zadać, brzmi: po co usuwać logikę? Koncepcja polega oczywiście na rozdzieleniu obaw . Zachowaj jak najbardziej oddzielne przetwarzanie widoku od logiki biznesowej. Czemu to robić? Pozwala nam na wymianę widoków (dla różnych platform: mobilna, przeglądarka, komputer stacjonarny itp.) I pozwala nam łatwiej zamieniać przepływ kontroli, kolejność stron, zmiany walidacji, zmiany modelu, dostęp bezpieczeństwa itp. Również wtedy, gdy logika jest usunięte z widoków (zwłaszcza widoków internetowych), sprawia, że ​​widoki są znacznie bardziej czytelne, a zatem łatwiejsze w utrzymaniu. Rozumiem i zgadzam się z tym.

Jednak nadrzędny nacisk powinien być położony na oddzielenie obaw. Nie w 100% pozbawione logiki widoki. Logika w widokach powinna odnosić się do sposobu renderowania „modelu”. Jeśli o mnie chodzi, logika w widokach jest w porządku. Możesz mieć logikę widoku, która nie jest logiką biznesową.

Tak, w czasach, gdy pisaliśmy strony JSP, PHP lub ASP z niewielką lub żadną separacją logiki kodu i logiki widoku, utrzymanie tych aplikacji internetowych było absolutnym koszmarem. Uwierz mi, wiem, stworzyłem i utrzymywałem niektóre z tych potworności. To właśnie podczas tej fazy utrzymania naprawdę zrozumiałem (wewnętrznie) błąd mojego i moich kolegów. :-) :-)

Tak więc edykt z góry (eksperci z branży) stał się, musisz tworzyć strukturę swoich aplikacji internetowych za pomocą czegoś w rodzaju kontrolera widoku z przodu (który jest wysyłany do programów obsługi lub działań [wybierz strukturę sieciową]), a widoki nie mogą zawierać kodu . Widoki miały stać się głupimi szablonami.

Generalnie zgadzam się więc z powyższym sentymentem, nie ze względu na specyfikę treści edyktu, ale raczej z motywacji, która za nim stoi - jaką jest chęć rozdzielenia obaw na pogląd i logikę biznesową.

W jednym projekcie, w którym byłem zaangażowany, staraliśmy się podążać za koncepcją poglądów pozbawionych logiki do absurdalnej skrajności. Mieliśmy własny silnik szablonów, który pozwolił nam renderować obiekty modelu w html. Był to prosty system oparty na tokenach. To było straszne z jednego bardzo prostego powodu. Czasami musieliśmy zdecydować, czy powinienem wyświetlić ten mały fragment HTML… czy nie… Decyzja jest zwykle oparta na jakiejś wartości w modelu. Kiedy nie masz absolutnie żadnej logiki w widoku, jak to robisz? Nie możesz. Odbyłem w tej sprawie poważne spory z naszym architektem. Ludzie z front-endu HTML piszący nasze widoki byli kompletnie sparaliżowani, kiedy mieli do czynienia z tym i byli bardzo zestresowani, ponieważ nie mogli osiągnąć swoich skądinąd prostych celów. Dlatego wprowadziłem koncepcję prostej instrukcji IF w naszym silniku szablonów. Nie potrafię opisać ci ulgi i spokoju, które nastąpiły. Problem został rozwiązany za pomocą prostej koncepcji instrukcji IF w naszych szablonach! Nagle nasz silnik szablonów stał się dobry.

Jak więc znaleźliśmy się w tej głupiej, stresującej sytuacji? Skupiliśmy się na złym celu. Postępowaliśmy zgodnie z zasadą, że nie możesz mieć logiki w swoich poglądach. To było złe. Myślę, że „praktyczną zasadą” powinno być zminimalizowanie tej logiki w swoich poglądach. Bo jeśli tego nie zrobisz, możesz niechcący pozwolić logice biznesowej wkradać się do widoku - co narusza rozdzielenie obaw.

Rozumiem, że kiedy deklarujesz, że „nie możesz mieć logiki w widokach”, łatwo jest rozpoznać, kiedy jesteś „dobrym” programistą. (Jeśli to jest twoja miara dobroci). Teraz spróbuj zaimplementować aplikację internetową o nawet średniej złożoności, stosując powyższą regułę. Nie jest to takie łatwe.

Dla mnie reguła logiki w poglądach nie jest tak jednoznaczna i szczerze mówiąc, tak właśnie chcę.

Kiedy widzę dużo logiki w widokach, wykrywam zapach kodu i staram się wyeliminować większość logiki z widoków - staram się, aby logika biznesowa znajdowała się gdzie indziej - staram się oddzielić obawy. Ale kiedy zaczynam rozmawiać z ludźmi, którzy mówią, że musimy usunąć wszelką logikę z widoku, cóż, dla mnie, to po prostu trąci fanatyzmem, ponieważ wiem, że możesz skończyć w sytuacjach takich, jak opisałem powyżej.

Skończyłem z rantem. :-)

Twoje zdrowie,

David

David Balme
źródło
świetna odpowiedź, chodzi o dobre praktyki programistyczne ... a tak przy okazji, ponowne użycie szablonów bez logiki na serwerze i kliencie nie jest DRY, ponieważ będziesz musiał zduplikować logikę w obu ...
mateusmaso
5

Najlepszym argumentem, jaki wymyśliłem dla szablonów bez logicznych, jest to, że możesz używać dokładnie tych samych szablonów zarówno na kliencie, jak i na serwerze. Jednak tak naprawdę nie potrzebujesz bez logiki, wystarczy taki, który ma swój własny „język”. Zgadzam się z ludźmi, którzy narzekają, że wąsy bezcelowo ograniczają. Dzięki, ale jestem dużym chłopcem i mogę utrzymać moje szablony w czystości bez Twojej pomocy.

Inną opcją jest po prostu znalezienie składni szablonów, która używa języka, który jest obsługiwany zarówno na kliencie, jak i na serwerze, a mianowicie javascript na serwerze za pomocą node.js lub możesz użyć interpretera js i json przez coś takiego jak therubyracer.

Wtedy możesz użyć czegoś takiego jak haml.js, który jest znacznie czystszy niż którykolwiek z dotychczas dostarczonych przykładów i działa świetnie.

eagspoo
źródło
Całkowicie się zgadzam. Po lekturze doszedłem do wniosku, że możliwość tworzenia szablonów w JS zarówno po stronie klienta, jak i serwera, spełnia moje potrzeby lepiej niż kilka specyficznych języków szablonów
christofr
4

Jednym zdaniem: bez logiki oznacza, że ​​sam silnik szablonów jest mniej złożony i dlatego zajmuje mniej miejsca i istnieje mniej sposobów, aby zachowywał się nieoczekiwanie.

Kernel James
źródło
3

Mimo że pytanie jest stare i na które udzielono odpowiedzi, chciałbym dodać moje 2 centy (co może brzmieć jak tyrada, ale tak nie jest, dotyczy ograniczeń i kiedy stają się nie do przyjęcia).

Celem szablonu jest renderowanie czegoś, a nie wykonywanie logiki biznesowej. Teraz jest cienka granica między niemożnością zrobienia tego, co trzeba zrobić w szablonie, a posiadaniem w nich „logiki biznesowej”. Mimo że byłem bardzo pozytywnie nastawiony do Mustache i próbowałem go używać, w dość prostych przypadkach nie byłem w stanie zrobić tego, czego potrzebowałem.

„Masowanie” danych (aby użyć słów w zaakceptowanej odpowiedzi) może stać się prawdziwym problemem - nie są obsługiwane nawet proste ścieżki (coś, co adresuje Handlebars.js). Jeśli mam widok danych i muszę to poprawić za każdym razem, gdy chcę coś renderować, ponieważ mój silnik szablonów jest zbyt ograniczony, ostatecznie nie jest to pomocne. I pokonuje część niezależności platformy, którą wąsy domagają się dla siebie; Muszę wszędzie powielać logikę masowania.

To powiedziawszy, po pewnej frustracji i po wypróbowaniu innych silników szablonów, w końcu stworzyliśmy własny (... jeszcze inny ...), który wykorzystuje składnię inspirowaną szablonami .NET Razor. Jest analizowany i kompilowany na serwerze i generuje prostą, niezależną funkcję JS (właściwie jako moduł RequireJS), którą można wywołać w celu „wykonania” szablonu, zwracając w rezultacie ciąg znaków. Próbka podana przez brada wyglądałaby tak podczas korzystania z naszego silnika (który osobiście uważam za znacznie lepszy w porównaniu z Mustache i Underscore):

@name:
<ul>
@for (items) {
  <li>@.</li>
}
</ul>

Kolejne ograniczenie pozbawione logiki dotknęło nas, gdy wywołujemy podszewki z Mustache. Chociaż częściowe są obsługiwane przez Mustache, nie ma możliwości dostosowania danych, które mają być przekazane jako pierwsze. Więc zamiast być w stanie stworzyć modułowy szablon i ponownie wykorzystać małe bloki, skończę z tworzeniem szablonów z powtórzonym kodem.

Rozwiązaliśmy ten problem, wprowadzając język zapytań inspirowany XPath, który nazwaliśmy JPath. Zasadniczo zamiast używać / do przechodzenia do dzieci używamy kropek, a obsługiwane są nie tylko ciągi, liczby i literały boolowskie, ale także obiekty i tablice (tak jak JSON). Język jest wolny od efektów ubocznych (co jest konieczne przy tworzeniu szablonów), ale umożliwia „masowanie” danych w razie potrzeby poprzez tworzenie nowych obiektów literału.

Powiedzmy, że chcemy wyrenderować tabelę „siatki danych” z dostosowywanymi nagłówkami i linkami do działań w wierszach, a później dynamicznie dodawać wiersze za pomocą jQuery. Dlatego wiersze muszą być w części, jeśli nie chcę powielać kodu. I tutaj zaczyna się problem, jeśli dodatkowe informacje, takie jak kolumny, które mają być renderowane, są częścią modelu widoku i są takie same dla tych działań w każdym wierszu. Oto trochę działającego kodu używającego naszego szablonu i silnika zapytań:

Szablon tabeli:

<table>
    <thead>
        <tr>
            @for (columns) {
                <th>@title</th>
            }
            @if (actions) {
                <th>Actions</th>
            }
        </tr>
    </thead>
    <tbody>
        @for (rows) {
            @partial Row({ row: ., actions: $.actions, columns: $.columns })
        }
    </tbody>
</table>

Szablon wiersza:

<tr id="@(row.id)">
    @for (var $col in columns) {
        <td>@row.*[name()=$col.property]</td>
    }
    @if (actions) {     
        <td>
        @for (actions) {
            <button class="btn @(id)" value="@(id)">@(name)...</button>
        }
        </td>
    }
</tr>

Wywołanie z kodu JS:

var html = table({
    columns: [
        { title: "Username", property: "username" },
        { title: "E-Mail", property: "email" }
    ],
    actions: [
        { id: "delete", name: "Delete" }
    ],
    rows: GetAjaxRows()
})

Nie ma w sobie żadnej logiki biznesowej, ale można go wielokrotnie używać i konfigurować, a także nie ma skutków ubocznych.

Lucero
źródło
13
Szczerze mówiąc, nie widzę sensu tej odpowiedzi, w ogóle nie odpowiada na pytanie. Mówisz, że istnieją ograniczenia, nie opisując w rzeczywistości, czym one są ani jak się pojawiają. W końcu rozpoczynasz dyskusję na temat własnego systemu, który nie jest dostępny dla nikogo innego, w rzeczywistości może być do niczego i pewnego dnia może skończyć się na dailywtf, ale nigdy byśmy się nie dowiedzieli. Otwórz kod źródłowy, połącz się z nim i pozwól nam zdecydować!
mattmanser
1
@mattmanser, piszę o ograniczeniach, które doprowadziły do ​​niestosowania Mustache (i Handlebars): brak wsparcia dla ścieżek, predykatów, zmiennych, transformacji danych do wywoływania podrzędnych. To wszystko było dla nas ważne. Prawdopodobnie pewnego dnia otworzymy kod, ale ponieważ jest to rozwiązanie po stronie serwera (lub, jeśli chcesz, kompilacji), które kompiluje szablony do kodu JS, nie będzie miało takiej samej dużej liczby odbiorców jak Mustache. Jeśli chcesz się ze mną skontaktować, zapraszam do kontaktu - jestem również autorem kodu bsn GoldParser w Google (gdzie łatwo znaleźć mój e-mail w pliku readme).
Lucero
Podoba mi się pomysł twojego silnika przypominającego brzytwę ... czy to open source?
Cracker
@Cracker, nie, to nie jest (jeszcze) - "problem" z tym polega na tym, że obecnie szablony są kompilowane do kodu JS na serwerze z uruchomionym ASP.NET MVC, a więc docelowa grupa odbiorców nie jest tak duża jak w przypadku innych silników szablonów . Oprócz tego jest częścią większej biblioteki, którą najpierw musimy rozebrać, aby móc ją udostępniać.
Lucero,
1
@Esailija Pozwala dynamicznie określać nazwy właściwości, które mają być pobierane z rowobiektu, zamiast używać nazw statycznych. Np. Jeśli $col.property == 'Something'to dałoby zawartość row.Something.
Lucero
2

Oto 3 sposoby renderowania listy z liczbą znaków. Wszystkie, z wyjątkiem pierwszego i najkrótszego, są w językach pozbawionych logiki szablonów.

CoffeeScript (z konstruktorem Reactive Coffee DSL) - 37 znaków

"#{name}"
ul items.map (i) ->
  li i

Knockout - 100 znaków

<span data-bind="value: name"/>
<ul data-bind="foreach: items">
   <li data-bind="value: i"/>
</ul>

Kierownica / Wąsy - 66 znaków

{{name}}:
<ul>
  {{#items}}
    <li>{{.}}</li>
  {{/items}}
</ul>

Podkreślenie - 87 znaków

<%- name %>:
<ul>
<% _.each(items, function(i){ %>
  <li><%- i %></li>
<% }); %>
</ul>

Obietnica szablonów pozbawionych logiki była, jak przypuszczam, taka, że ​​ludzie z szerszymi umiejętnościami byliby w stanie zarządzać szablonami pozbawionymi logiki bez strzelania sobie w stopę. Jednak w powyższych przykładach widać, że po dodaniu języka logiki minimalnej do znaczników opartych na ciągach wynik jest bardziej złożony, a nie mniej. Poza tym wyglądasz, jakbyś robił oldschoolowe PHP.

Oczywiście nie sprzeciwiam się utrzymywaniu „logiki biznesowej” (obszernych obliczeń) poza szablonami. Ale myślę, że dając im pseudo-język do logiki wyświetlania zamiast języka pierwszej klasy, cena jest płacona. Nie tylko więcej do pisania, ale ohydna mieszanka przełączania kontekstów, które ktoś musi przeczytać.

Podsumowując, nie widzę logiki szablonów pozbawionych logiki, więc powiedziałbym, że ich przewaga jest dla mnie zerowa, ale szanuję, że wielu członków społeczności widzi to inaczej :)

Dean Radcliffe
źródło
@brad, co myślisz o tym porównaniu?
Dean Radcliffe
2

Główne zalety korzystania z szablonów bez logiki to:

  • Ściśle wymusza separację widoku modelu , szczegółowe informacje można znaleźć w tym dokumencie (wysoce zalecane)
  • Bardzo łatwy do zrozumienia i użycia , ponieważ nie jest potrzebna logika programowania (i wiedza!), A składnia jest minimalna
  • (zwłaszcza Mustache) wysoce przenośny i niezależny od języka, może być używany bez modyfikacji w prawie wszystkich środowiskach programistycznych
rmuller
źródło
świetna zwięzła odpowiedź!
MrWatson
1

Zgadzam się z Bradem: underscorestyl jest łatwiejszy do zrozumienia. Ale muszę przyznać, że cukier syntaktyczny może nie wszystkim zadowolić. Jeśli _.eachjest nieco mylące, można użyć tradycyjnej forpętli.

  <% for(var i = 0; i < items.length; i++) { %>
    <%= items[i] %>
  <% } %>

Zawsze dobrze jest, jeśli możesz wrócić do standardowych konstrukcji, takich jak forlub if. Po prostu użyj <% if() %>lub <% for() %>podczas Mustacheużywania nieco neologizmu dla if-then-else(i mylące, jeśli nie przeczytałeś dokumentacji):

{{#x}}
  foo
{{/x}}
{{^x}}
  bar
{{/x}}

Silnik szablonów jest świetny, gdy można łatwo uzyskać zagnieżdżone szablony ( underscorestyl):

<script id="items-tmpl" type="text/template">
    <ul>
        <% for(var i = 0; i < obj.items.length; i++) { %>
            <%= innerTmpl(obj.items[i]) %>
        <% } %>
    </ul>
</script>

<script id="item-tmpl" type="text/template">
    <li>
        <%= name %>
    </li>
</script>

var tmplFn = function(outerTmpl, innerTmpl) {
    return function(obj) {
        return outerTmpl({obj: obj, innerTmpl: innerTmpl});
    };
};

var tmpl = tmplFn($('#items-tmpl').html(), $('#item-tmpl').html());
var context = { items: [{name:'A',{name:'B'}}] };
tmpl(context);

Zasadniczo przekazujesz swoje wewnętrzne tmpl jako właściwość swojego kontekstu. I nazwij to odpowiednio. Słodkie :)

Nawiasem mówiąc, jeśli jedyne, co Cię interesuje, to silnik szablonów, użyj samodzielnej implementacji szablonu. Po zminimalizowaniu ma tylko 900 znaków (4 długie linie):

https://gist.github.com/marlun78/2701678

roland
źródło