Apa keuntungan dari template tanpa logika (seperti kumis)?

Baru-baru ini, saya menemukan kumis yang diklaim sebagai templat tanpa logika .

Namun, tidak ada penjelasan mengapa ini dirancang dengan cara tanpa logika. Dengan kata lain, apa keuntungan dari template tanpa logika?

Dengan kata lain, ini mencegah Anda menembak diri sendiri di kaki. Di masa lalu JSP, sangat umum untuk memiliki file JSP yang ditaburi kode Java, yang membuat pemfaktoran ulang jauh lebih sulit, karena kode Anda tersebar.

Jika Anda mencegah logika dalam templat dengan desain (seperti yang dilakukan kumis), Anda akan diwajibkan untuk meletakkan logika di tempat lain, sehingga templat Anda tidak akan berantakan.

Keuntungan lainnya adalah Anda dipaksa untuk berpikir dalam hal pemisahan masalah: pengontrol atau kode logika Anda harus melakukan pemijatan data sebelum mengirim data ke UI. Jika nanti Anda mengganti template dengan template lain (misalkan Anda mulai menggunakan mesin template yang berbeda), transisi akan mudah karena Anda hanya perlu menerapkan detail UI (ingat, karena tidak ada logika pada template).

Menurut pendapat saya, saya merasa hampir sendirian, tetapi saya berada di kubu yang berlawanan. Saya tidak percaya bahwa kemungkinan pencampuran logika bisnis di template Anda adalah alasan yang cukup untuk tidak menggunakan kekuatan penuh bahasa pemrograman Anda.

Argumen umum untuk templat tanpa logika adalah jika Anda memiliki akses penuh ke bahasa pemrograman Anda, Anda mungkin mencampur logika yang tidak memiliki tempat di dalam templat. Saya menemukan ini mirip dengan alasan bahwa Anda harus menggunakan sendok untuk mengiris daging karena Anda bisa memotong diri sendiri jika menggunakan pisau. Ini sangat benar, namun Anda akan jauh lebih produktif jika Anda menggunakan yang terakhir, meskipun dengan hati-hati.

Misalnya, pertimbangkan cuplikan template berikut menggunakan mustache :

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

Saya dapat memahami ini, tetapi saya menemukan yang berikut (menggunakan garis bawah ) jauh lebih sederhana dan langsung:

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

Karena itu, saya memahami bahwa template tanpa logika memiliki kelebihan (misalnya, template dapat digunakan dengan banyak bahasa pemrograman tanpa perubahan). Saya pikir keuntungan lain ini sangat penting. Saya hanya tidak berpikir sifat tanpa logika mereka adalah salah satunya.

Kumis tanpa logika?

Bukankah ini:

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

Sangat mirip dengan ini?

if x
  "foo"
else
  "bar"
end

Dan bukankah itu sangat mirip dengan (baca: hampir merupakan definisi dari) logika presentasi?

Templat tanpa logika adalah templat yang berisi lubang untuk Anda isi, dan bukan cara Anda mengisinya. Logika ditempatkan di tempat lain dan langsung dipetakan ke template. Pemisahan masalah ini ideal karena templat dapat dengan mudah dibangun dengan logika yang berbeda, atau bahkan dengan bahasa pemrograman yang berbeda.

Dari manual kumis :

Kami menyebutnya "tanpa logika" karena tidak ada pernyataan if, klausa lain, atau untuk loop. Sebaliknya hanya ada tag. Beberapa tag diganti dengan nilai, beberapa tidak ada, dan lainnya dengan serangkaian nilai. Dokumen ini menjelaskan berbagai jenis tag Mustache.

Sisi lain dari koin ini adalah bahwa dalam upaya putus asa untuk menjauhkan logika bisnis dari presentasi, Anda akhirnya memasukkan banyak logika presentasi ke dalam model. Contoh umum mungkin Anda ingin menempatkan kelas "ganjil" dan "genap" pada baris bergantian dalam tabel, yang dapat dilakukan dengan operator modulo sederhana dalam template tampilan. Tetapi jika templat tampilan Anda tidak memungkinkan Anda melakukan itu, maka dalam data model Anda, Anda tidak hanya harus menyimpan baris mana yang ganjil atau genap, tetapi tergantung pada seberapa terbatas mesin templat Anda, Anda bahkan mungkin perlu mencemari model Anda. dengan nama kelas CSS yang sebenarnya. Tampilan harus terpisah dari Model, sepenuhnya. Tetapi Model juga harus View agnostic, dan itulah yang banyak dari mesin template "tanpa logika" ini membuat Anda lupa. Logika ada di kedua tempat,sebenarnya tidak untuk memutuskan dengan benar kemana perginya. Apakah ini masalah presentasi, atau bisnis / data? Dalam upaya untuk memiliki 100% pemandangan murni, polusi hanya mendarat di tempat lain yang kurang terlihat tetapi sama-sama tidak pantas.

Ada gerakan yang berkembang kembali ke arah lain, dan mudah-mudahan segalanya akan berpusat di suatu tempat di jalan tengah yang lebih masuk akal.

Itu membuat templat Anda lebih bersih, dan memaksa Anda untuk menyimpan logika di tempat yang dapat diuji unitnya dengan benar.

Percakapan ini terasa seperti ketika para biksu abad pertengahan memperdebatkan berapa banyak malaikat yang bisa muat di ujung pin. Dengan kata lain itu mulai terasa religius, sia-sia dan salah fokus.

Kata-kata kasar kecil terjadi kemudian (abaikan saja):

Jika Anda tidak ingin melanjutkan membaca .. Tanggapan singkat saya untuk topik di atas adalah: Saya tidak setuju dengan template tanpa logika. Saya menganggapnya sebagai bentuk pemrograman ekstremisme. :-) :-)

Sekarang kata-kata kasar saya terus berlanjut: :-)

Saya pikir ketika Anda mengambil banyak ide secara ekstrem, hasilnya menjadi menggelikan. Dan terkadang (yaitu topik ini) masalahnya adalah bahwa kita mengambil ide yang "salah" secara ekstrem.

Menghapus semua logika dari tampilan adalah "menggelikan" dan ide yang salah.

Mundur sejenak.

Pertanyaan yang perlu kita tanyakan pada diri kita sendiri adalah mengapa menghilangkan logika itu? Konsepnya, jelas adalah pemisahan perhatian . Jaga agar pemrosesan tampilan terpisah dari logika bisnis sebisa mungkin. Kenapa melakukan ini? Ini memungkinkan kita untuk menukar tampilan (untuk platform yang berbeda: seluler, browser, desktop dll) dan ini memungkinkan kita untuk lebih mudah menukar aliran kontrol, urutan halaman, perubahan validasi, perubahan model, akses keamanan, dll. Juga ketika logika dihapus dari tampilan (terutama tampilan web), ini membuat tampilan jauh lebih mudah dibaca dan karenanya lebih mudah dipelihara. Saya mengerti dan setuju dengan itu.

Namun fokus utama harus pada pemisahan perhatian. Bukan 100% tampilan tanpa logika. Logika di dalam view harus berhubungan dengan cara merender "model". Sejauh yang saya ketahui, logika dalam tampilan baik-baik saja. Anda dapat memiliki logika tampilan yang bukan logika bisnis.

Ya, kembali pada hari ketika kami menulis halaman JSP, PHP atau ASP dengan sedikit atau tanpa pemisahan logika kode dan logika tampilan, pemeliharaan aplikasi web ini benar-benar mimpi buruk. Percayalah, saya tahu, saya menciptakan dan kemudian memelihara beberapa monstrositas ini. Selama fase pemeliharaan itulah saya benar-benar memahami (secara naluriah) kesalahan cara saya dan kolega saya. :-) :-)

Jadi dekrit dari atas (pakar industri) menjadi, Anda harus menyusun aplikasi web Anda menggunakan sesuatu seperti pengontrol tampilan depan (yang dikirim ke penangan atau tindakan [pilih kerangka kerja web Anda]) dan pandangan Anda tidak boleh berisi kode . Pandangan itu menjadi template bodoh.

Jadi saya setuju secara umum dengan sentimen di atas, bukan untuk spesifik item fatwa, melainkan motivasi di balik fatwa - yaitu keinginan untuk pemisahan perhatian antara pandangan dan logika bisnis.

Dalam satu proyek yang saya ikuti, kami mencoba mengikuti gagasan pandangan tanpa logika hingga ke ekstrem yang menggelikan. Kami memiliki mesin template buatan sendiri yang memungkinkan kami merender objek model dalam html. Itu adalah sistem berbasis token sederhana. Itu mengerikan karena satu alasan yang sangat sederhana. Terkadang dalam sebuah tampilan kita harus memutuskan, haruskah saya menampilkan potongan kecil HTML ini .. atau tidak .. Keputusan tersebut biasanya didasarkan pada beberapa nilai dalam model. Jika Anda sama sekali tidak memiliki logika dalam tampilan, bagaimana Anda melakukannya? Anda tidak bisa. Saya memiliki beberapa argumen utama dengan arsitek kami tentang ini. Orang-orang HTML front-end yang menulis pandangan kami benar-benar lumpuh ketika mereka dihadapkan dengan ini dan sangat tertekan karena mereka tidak dapat mencapai tujuan sederhana mereka. Jadi saya memperkenalkan konsep pernyataan IF sederhana di dalam mesin template kami. Saya tidak bisa menjelaskan kepada Anda kelegaan dan ketenangan yang terjadi. Masalah diselesaikan dengan konsep Pernyataan IF sederhana di templat kami! Tiba-tiba mesin templating kami menjadi baik.

Jadi, bagaimana kita bisa masuk ke dalam situasi stres yang konyol ini? Kami fokus pada tujuan yang salah. Kami mengikuti aturan, Anda tidak boleh memiliki logika dalam pandangan Anda. Itu salah. Saya pikir "aturan praktis" harusnya adalah, minimalkan jumlah logika dalam pandangan Anda. Karena jika tidak, Anda dapat secara tidak sengaja membiarkan logika bisnis menyusup ke dalam pandangan - yang melanggar pemisahan masalah.

Saya memahami bahwa ketika Anda menyatakan bahwa "Anda tidak boleh memiliki logika dalam tampilan", akan mudah untuk mengetahui kapan Anda menjadi programmer yang "baik". (Jika itu ukuran kebaikan Anda). Sekarang coba terapkan aplikasi web dengan kompleksitas menengah dengan aturan di atas. Ini tidak mudah dilakukan.

Bagi saya, aturan logika dalam pandangan tidak begitu jelas dan terus terang itulah yang saya inginkan.

Ketika saya melihat banyak logika dalam tampilan, saya mendeteksi code-bau dan mencoba menghilangkan sebagian besar logika dari pandangan - saya mencoba memastikan logika bisnis ada di tempat lain - saya mencoba memisahkan masalah. Tetapi ketika saya mulai mengobrol dengan orang-orang yang mengatakan kita harus menghapus semua logika dari pandangan, bagi saya, itu hanya berbau fanatisme seperti yang saya tahu Anda bisa berakhir dalam situasi seperti yang saya jelaskan di atas.

Saya sudah selesai dengan kata-kata kasar saya. :-)

Bersulang,

David

Argumen terbaik yang saya temukan untuk templat tanpa logika adalah Anda dapat menggunakan templat yang sama persis pada klien dan server. Namun Anda tidak benar-benar membutuhkan logika, hanya satu yang memiliki "bahasa" sendiri. Saya setuju dengan orang-orang yang mengeluh bahwa kumis membatasi tanpa tujuan. Terima kasih, tapi saya sudah dewasa dan saya dapat menjaga templat saya tetap bersih tanpa bantuan Anda.

Pilihan lainnya adalah dengan menemukan sintaks templating yang menggunakan bahasa yang didukung pada klien dan server, yaitu javascript di server baik dengan menggunakan node.js atau Anda dapat menggunakan js interpreter dan json melalui sesuatu seperti therubyracer.

Kemudian Anda dapat menggunakan sesuatu seperti haml.js yang jauh lebih bersih daripada contoh yang diberikan sejauh ini dan berfungsi dengan baik.

Dalam satu kalimat: Logic-less berarti mesin template itu sendiri tidak terlalu rumit dan oleh karena itu memiliki footprint yang lebih kecil dan lebih sedikit cara untuk berperilaku tidak terduga.

Meskipun pertanyaannya sudah lama dan sudah terjawab, saya ingin menambahkan 2 ¢ saya (yang mungkin terdengar seperti kata-kata kasar, tetapi sebenarnya tidak, ini tentang batasan dan kapan mereka menjadi tidak dapat diterima).

Tujuan dari templat adalah untuk merender sesuatu, bukan untuk menjalankan logika bisnis. Sekarang ada garis tipis antara tidak dapat melakukan apa yang perlu Anda lakukan dalam template dan memiliki "logika bisnis" di dalamnya. Meskipun saya sangat positif terhadap Kumis dan mencoba menggunakannya, saya akhirnya tidak dapat melakukan apa yang saya butuhkan dalam kasus yang cukup sederhana.

"Memijat" data (menggunakan kata-kata dalam jawaban yang diterima) bisa menjadi masalah nyata - bahkan jalur sederhana tidak didukung (sesuatu yang ditangani Handlebars.js). Jika saya memiliki data tampilan dan saya perlu menyesuaikannya setiap kali saya ingin merender sesuatu karena mesin template saya terlalu membatasi, maka ini pada akhirnya tidak membantu. Dan itu mengalahkan bagian dari kemandirian platform yang diklaim kumis untuk dirinya sendiri; Saya harus menduplikasi logika pemijatan di mana-mana.

Yang mengatakan, setelah beberapa frustrasi dan setelah mencoba mesin template lain kami akhirnya membuat sendiri (... lagi ...), yang menggunakan sintaks yang terinspirasi oleh template .NET Razor. Ini diurai dan dikompilasi di server dan menghasilkan fungsi JS mandiri yang sederhana (sebenarnya sebagai modul RequireJS) yang dapat dipanggil untuk "mengeksekusi" template, mengembalikan string sebagai hasilnya. Sampel yang diberikan oleh brad akan terlihat seperti ini ketika menggunakan mesin kami (yang menurut saya jauh lebih unggul dalam hal ini dibandingkan dengan Moustache dan Underscore):

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

Batasan bebas logika lainnya menghantam kami saat memanggil sebagian dengan Kumis. Meskipun parsial didukung oleh Mustache, tidak ada kemungkinan untuk menyesuaikan data yang akan diteruskan terlebih dahulu. Jadi, alih-alih dapat membuat template modular dan menggunakan kembali blok-blok kecil, saya akan membuat template dengan kode berulang di dalamnya.

Kami menyelesaikannya dengan menerapkan bahasa kueri yang terinspirasi oleh XPath, yang kami sebut JPath. Pada dasarnya, alih-alih menggunakan / untuk melakukan traverse ke turunan, kami menggunakan titik, dan tidak hanya string, angka, dan literal boolean yang didukung, tetapi juga objek dan larik (seperti JSON). Bahasa ini bebas efek samping (yang merupakan keharusan untuk membuat template) tetapi memungkinkan "memijat" data sesuai kebutuhan dengan membuat objek literal baru.

Misalkan kita ingin merender tabel "data grid" dengan header yang dapat disesuaikan dan link ke tindakan pada baris, dan kemudian secara dinamis menambahkan baris menggunakan jQuery. Oleh karena itu, baris harus sebagian jika saya tidak ingin menduplikasi kode. Dan di situlah masalah dimulai jika beberapa informasi tambahan seperti kolom apa yang akan dirender adalah bagian dari model tampilan, dan sama untuk tindakan tersebut di setiap baris. Berikut adalah beberapa kode kerja yang sebenarnya menggunakan template dan mesin kueri kami:

Template tabel:

<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>

Template baris:

<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>

Panggilan dari kode JS:

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

Itu tidak memiliki logika bisnis di dalamnya, namun dapat digunakan kembali dan dikonfigurasi, dan juga bebas efek samping.

Berikut adalah 3 cara merender daftar, dengan jumlah karakter. Semua kecuali yang pertama dan terpendek ada dalam bahasa template tanpa logika ..

CoffeeScript (dengan DSL pembuat Kopi Reaktif ) - 37 karakter

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

Knockout - 100 karakter

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

Setang / Kumis - 66 karakter

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

Garis bawah - 87 karakter

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

Janji dari templat tanpa logika, saya kira, bahwa orang-orang dengan kumpulan keterampilan yang lebih luas akan dapat mengelola templat tanpa logika tanpa mengambil risiko sendiri. Namun, apa yang Anda lihat pada contoh di atas adalah ketika Anda menambahkan bahasa logika minimal ke markup berbasis string, hasilnya lebih kompleks, bukan kurang. Juga, Anda terlihat seperti sedang menggunakan PHP jadul.

Jelas saya tidak keberatan untuk menjaga "logika bisnis" (komputasi ekstensif) dari template. Tapi saya pikir dengan memberi mereka bahasa pseudo untuk logika tampilan alih-alih bahasa kelas satu, harganya dibayar. Tidak hanya lebih banyak mengetik, tetapi campuran keji dari pengalihan konteks yang perlu dibaca seseorang.

Kesimpulannya, saya gagal untuk melihat logika template tanpa logika, jadi menurut saya keuntungan mereka nihil bagi saya, tetapi saya menghormati banyak komunitas yang melihatnya secara berbeda :)

Keuntungan utama menggunakan template tanpa logika adalah:

• Terapkan pemisahan model-view dengan ketat , lihat makalah ini untuk detailnya (sangat disarankan)
• Sangat mudah dipahami dan digunakan , karena tidak diperlukan logika pemrograman (dan pengetahuan!) Dan sintaksnya minimal
• (Mustache tertentu) sangat portabel dan tidak bergantung pada bahasa, dapat digunakan tanpa modifikasi di hampir semua lingkungan pemrograman

Saya setuju dengan Brad: underscoregayanya lebih mudah dimengerti. Tetapi saya harus mengakui bahwa gula sintaksis mungkin tidak menyenangkan semua orang. Jika _.eachagak membingungkan, Anda dapat menggunakan forloop tradisional .

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

Akan selalu menyenangkan jika Anda dapat kembali ke konstruksi standar seperti foratau if. Cukup gunakan <% if() %>atau <% for() %>saat Mustachemenggunakan sedikit neologisme untuk if-then-else(dan membingungkan jika Anda tidak membaca dokumentasi):

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

Mesin template sangat bagus ketika Anda bisa mendapatkan template bersarang dengan mudah ( underscoregaya):

<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);

Pada dasarnya Anda meneruskan tmpl batin Anda sebagai properti konteks Anda. Dan sebut saja sesuai. Manis :)

Ngomong-ngomong, jika satu-satunya hal yang Anda minati adalah mesin templat, gunakan penerapan templat mandiri. Hal ini hanya 900 karakter ketika minified (4 baris panjang):

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