Apa keuntungan dari template tanpa logika (seperti kumis)?

101

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?

Morgan Cheng
sumber

Jawaban:

107

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

Miguel Ping
sumber
30
Jadi, mengapa hal yang baik bahwa kode pengontrol HARUS memijat data dengan tepat dalam bentuk yang diperlukan untuk menyajikan data dengan cara tertentu? Mengapa hal yang baik bahwa mengubah presentasi sering kali memerlukan perubahan kode pengontrol? Ini sepertinya hal yang buruk bagi saya. Saya pikir salah satu tujuan dari bahasa template adalah untuk memisahkan logika pengontrol dari logika presentasi. Template bodoh yang tidak dapat membuat keputusan apa pun memaksa logika presentasi kembali ke kode pengontrol. Dalam organisasi di mana orang yang berbeda mengerjakan presentasi, mereka tidak dapat melakukan pekerjaan mereka sendiri.
jfriend00
8
Anda tidak boleh menyiapkan data untuk tampilan di pengontrol Anda. Pengontrol untuk mengontrol aliran aplikasi. Sebaliknya, yang harus Anda lakukan adalah membuat kelas penyaji yang mengubah model Anda menjadi model tampilan yang kemudian digunakan oleh tampilan tersebut. Model tampilan adalah model untuk UI yang terpisah dari model yang merupakan bagian dari logika bisnis. Saya sarankan Anda untuk menonton pembicaraan "Arsitektur Bersih dan Desain" oleh Robert "Paman Bob" Martin: youtu.be/asLUTiJJqdE
ragol
1
Ini memaksa beberapa logika presentasi ke dalam pengontrol, tetapi ini membantu mutliple berbagai lapisan presentasi. Jika Anda ingin data serupa disajikan sebagai JSON, HTML, atau XML, Anda tidak boleh memutar data 100% di template HTML. Itu akan membuat JSON dan XML memiliki logika tampilan memutar mereka sendiri. Anda memusatkan 80% logika tampilan di pengontrol, dan menyematkan 20% lainnya di lambda dan filter.
chugadie
65

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.

brad
sumber
135
Saya terkejut Anda merasa bahwa template garis bawah lebih sederhana .. terlihat jauh lebih sulit dibaca oleh saya. Hanya pendapat :-)
Ben Clayton
9
@ ben-clayton Saya setuju bahwa sintaks pertama lebih cantik dan mungkin lebih mudah dibaca. Namun, kerumitan itulah yang saya kendalikan ketika saya mengatakan "sederhana".
brad
1
Terkadang menggunakan pernyataan terner sesuai di template tidak peduli logika apa yang Anda miliki. Atau bagaimana jika saya ingin menampilkan jumlah item dalam array? Saya tidak tahu bagaimana saya bisa menggunakan kumis, sepertinya tidak ada yang seperti itu.
Paul Shapiro
5
@PaulShapiro Anda akan menghasilkan jumlah item dalam larik di luar template, dan menyimpannya dalam variabel terpisah.
Seun Osewa
4
@brad, template garis bawah memperkenalkan lubang XSS: namedan itemsdapat berisi JavaScript.
Matius
28

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?

pje
sumber
17
Ya, jika Anda hanya mengevaluasi kebenaran suatu objek, tetapi mencoba melakukan sesuatu yang lebih rumit tidak mungkin ( if x > 0 && x < 10) ... Jadi, meskipun mungkin untuk menggunakan Mustache dengan atau tanpa logika, itu terserah Anda. Bagaimanapun, itu hanyalah alat.
Tom Ashworth
5
Anda melihat ini dengan cara yang salah. Hanya karena Anda dapat melakukan beberapa hal dalam bahasa yang tidak persis seperti paradigma umumnya, tidak berarti bahasa tersebut tidak termasuk dalam paradigma itu. Anda dapat menulis kode imperatif di Java atau Haskell, namun Anda tidak akan mengatakan itu membuat Java bukan bahasa OO atau Haskell bukan bahasa fungsional. Lihatlah bahasa apa yang memungkinkan Anda melakukannya dengan mudah dan apa yang mengarahkan Anda untuk melihat jenis bahasa apa itu.
cjs
@ CurtJ.Sampson analogi Anda akan masuk akal jika Java menjual dirinya sendiri sebagai "tanpa fungsional" atau jika Haskell menjual dirinya sebagai "tanpa berorientasi objek". Jawaban ini menunjukkan bahwa "tanpa logika" adalah istilah yang salah.
Corey
1
Saya pikir Anda setuju dengan saya bahwa ketika kita menyebut sebuah bahasa "fungsional" yang kita maksud, "cenderung ke arah fungsional." Ketidaksepakatan tampaknya adalah bahwa saya mendefinisikan "X-kurang" sebagai "cenderung menjauh dari X" sedangkan Anda mendefinisikannya sebagai "sama sekali tidak dapat melakukan X."
cjs
13

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.

Jeremy
sumber
6
Penjelasannya agak rumit, karena bagian-bagiannya bekerja seperti conditional dan loop, hanya saja yang sangat terbatas. Kemampuan untuk merujuk ke callable dalam hash juga memungkinkan Anda mengubah bagian menjadi bahasa pemrograman yang belum sempurna. Namun, setidaknya itu membuat sulit untuk mengambil rute itu, daripada mendorongnya.
Tom Anderson
1
Tentu, tetapi sistem templat tanpa blok untuk kondisi dan iterasi akan relatif tidak berguna. Template itu sendiri tidak menentukan untuk apa blok itu, atau bagaimana penanganannya.
Jeremy
12

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.

mattmc3
sumber
6
Harus tidak setuju dengan Anda di sana. Logika presentasi untuk template tanpa logika tidak masuk ke dalam model, ia masuk ke dalam tampilan, di tempatnya. Tampilan mengambil data model mentah, dan memijat seperlunya (dengan memberi keterangan pada baris ganjil / genap, dll.) Untuk mempersiapkannya untuk presentasi.
acjay
1
Mengapa tampilan tidak bisa lebih dari templat, dan menyertakan kode untuk memijat data untuk templat?
LeeGee
1
acjohnson55 - Saya setuju dengan Anda tentang ke mana harus pergi (view), tetapi template tanpa logika mencegah banyak hal seperti itu. @LeeGee - Saya pikir ada reaksi balik terhadap terlalu banyak logika dalam tampilan, tetapi banyak hal telah terlalu jauh ke arah lain untuk mencegah bahkan logika khusus presentasi dalam tampilan.
mattmc3
4
Saya tahu saya terlambat ke pesta, tetapi CSS nth-item (odd) harus digunakan untuk mengganti warna baris.
DanRedux
1
Tidak ada yang salah dengan memiliki objek presentasi perantara yang dibuat oleh tampilan dari model dan koleksi, atau data lainnya. Dengan cara ini, tampilan membuat data presentasi yang digabungkan dengan templat untuk membuat tampilan.
wprl
11

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

orang dungu
sumber
2
Bisakah Anda menjelaskannya dengan lebih detail?
Morgan Cheng
29
Luangkan waktu tiga bulan untuk mengerjakan sistem menggunakan bahasa template yang logis, seperti JSP, dengan pemrogram yang tidak bersemangat memisahkan logika dan presentasi. Anda akan menemukan Anda membangun sistem yang pada dasarnya memiliki pemrograman di halaman - aritmatika untuk tata letak tabel, persyaratan untuk informasi harga apa yang akan ditampilkan, dan sebagainya. Bahasa template adalah bahasa pemrograman yang sangat buruk, jadi ini membuat mimpi buruk pengembangan dan pemeliharaan. Sesuatu seperti Kumis tidak membiarkan Anda masuk ke dalam situasi itu sejak awal.
Tom Anderson
Jika logikanya berupa suatu fungsi, maka dapat digunakan oleh sistem micro-templating yang mendukung logika tertanam dan unit-test. Ide terburuk bagi saya tampaknya adalah setang "pembantu" (lihat spin.atomicobject.com/2011/07/14/… "Penggunaan Lanjutan") - ini tampaknya tidak mungkin untuk unit-test karena berada dalam skrip / tag jenis / teks daripada tag skrip lama (/ type / javascript) biasa
Dexygen
8

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

David Balme
sumber
jawaban yang bagus, ini semua tentang praktik pemrograman yang baik .. dan omong-omong, menggunakan kembali template tanpa logika di server dan klien tidaklah KERING karena Anda harus menduplikasi logika di keduanya ..
mateusmaso
5

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.

eagspoo
sumber
Saya sangat setuju. Setelah membaca beberapa kali, saya sampai pada kesimpulan bahwa kemampuan untuk membuat template di JS pada sisi klien dan server memenuhi kebutuhan saya lebih baik daripada sekumpulan bahasa template tertentu
christofr
4

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.

Kernel James
sumber
3

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.

Lucero
sumber
13
Sejujurnya saya tidak mengerti maksud dari jawaban ini, itu tidak menjawab pertanyaan sama sekali. Anda mengatakan ada batasan tanpa benar-benar menjelaskan apa itu atau bagaimana itu terjadi. Akhirnya Anda memulai diskusi tentang sistem Anda sendiri yang tidak tersedia untuk orang lain, pada kenyataannya itu bisa payah dan mungkin berakhir suatu hari di hari ini tetapi kami tidak akan pernah tahu. Buka sumbernya, tautkan ke sana dan biarkan kami memutuskan!
mattmanser
1
@mattmanser, saya menulis tentang batasan yang menyebabkan tidak menggunakan Mustache (dan Handlebars): dukungan yang hilang untuk jalur, predikat, variabel, transformasi data untuk pemanggilan parsial. Itu semua penting bagi kami. Kami mungkin akan membuka kode sumber suatu hari nanti, tetapi karena ini adalah solusi sisi server (atau waktu kompilasi jika Anda mau) yang mengkompilasi templat ke kode JS, itu tidak akan memiliki audiens yang sama besar dengan Mustache. Jika Anda ingin berhubungan, jangan ragu untuk menghubungi saya - saya juga penulis bsn GoldParser di kode Google (di mana Anda dapat menemukan email saya dengan mudah di file readme).
Lucero
Saya suka ide pisau cukur Anda seperti mesin ... apakah ini open source?
Cracker
@Cracker, tidak, ini belum (belum) - "masalah" dengan itu adalah bahwa saat ini template dikompilasi ke kode JS di server yang menjalankan ASP.NET MVC, dan dengan demikian target audiens tidak sebesar dengan mesin template lainnya . Selain itu, ini adalah bagian dari perpustakaan yang lebih besar yang pertama-tama harus kita pisahkan untuk sumber terbuka.
Lucero
1
@Esailija Memungkinkan untuk secara dinamis menetapkan nama properti yang akan diambil dari rowobjek, daripada menggunakan nama statis. Misalnya jika $col.property == 'Something'maka ini akan menghasilkan konten row.Something.
Lucero
2

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

Dean Radcliffe
sumber
@brad, apa pendapat Anda tentang perbandingan ini?
Dean Radcliffe
2

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
rmuller
sumber
jawaban singkat yang bagus!
MrWatson
1

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

roland
sumber