Hal ini dapat dilakukan oleh pembantu.
Lihat ini: http://kan.so/packages/details/handbars-helpers
Ada pembantu ifequal yang memungkinkan membandingkan dua nilai.
Solusi serupa dapat digunakan untuk kebutuhan Anda.

Saya takut akan hal itu.
Saya tahu hal seperti itu dapat dilakukan dengan helper... Tapi, maksud saya, membandingkan hal-hal yang sangat mendasar, harus dalam paket default.

Jika itu dimasukkan ke dalam paket, itu akan menjadi penolong.

@thany http://doginthehat.com.au/2012/02/comparison-block-helper-for-handbars-templates/

@andriijas cukup benar, itu memang akan menjadi penolong ;) Atau tidak, karena blok if sangat mendasar.
Terima kasih untuk tautannya. Ini membantu, tetapi saya ingin menulis "pembantu" yang menimpa if asli, untuk menjadikannya _proper_ if. Saya yakin itu mungkin. Setiap mesin templat yang menghargai diri sendiri membutuhkan pemformatan bersyarat yang tepat. Setang seharusnya tidak terkecuali.

Anda perlu melupakan fakta bahwa semua yang ada di setang yang menerapkan logika bisnis ke template adalah pembantu.

Semua bawaan masing-masing, jika dll didefinisikan melalui registerHelper. Memeriksa:
https://github.com/wycats/handbars.js/blob/master/lib/handbars/base.js

Jadi tidak ada yang "buruk" dengan menggunakan pembantu. Handlebars kurang lebih hanya kompiler template kumis dan untuk mendapatkan logika bisnis tambahan mereka menggunakan helper. jika berpikir Anda hanya memiliki pengalaman buruk tentang penggunaan kata "pembantu" mungkin dari Rails atau sesuatu.

Saya tidak pernah mengatakan ada yang salah dengan "pembantu". Hanya saja pernyataan if yang tepat tidak seharusnya menjadi ekstensi dalam pandangan saya. Helper (sekali lagi, menurut saya) adalah sesuatu yang spesifik untuk CMS atau sesuatu. Pembantu adalah sesuatu yang melakukan operasi atau kondisi khusus. Sesuatu yang tidak untuk semua orang. Artinya, jika itu didefinisikan di luar perpustakaan inti. Sedikit seperti plugin jQuery mungkin: hal-hal yang paling dasar sudah ada di dalamnya, hal-hal yang membantu Anda memulai. Tapi hal-hal yang tidak untuk semua orang didefinisikan di luar perpustakaan inti (yaitu di plugin). Dalam istilah jQuery, fungsi filter sederhana tidak akan menjadi plugin.

Pernyataan if (dalam pandangan saya) tidak berlaku untuk paradigma plugin ini. Ini dasar, ini adalah salah satu prinsip paling dasar dari pemrograman dan mesin template...

Sebuah tindak lanjut cepat kemudian. Inilah yang saya dapatkan sejauh ini:

Handlebars.registerHelper("when", function(lvalue, operation, rvalue, options) {
  console.log(arguments);
});

Menggunakan ini di template saya seperti {{#when riskfactor eq 0}}...{{/when}} Saya mendapatkan array [6, undefined, 0, function()] di konsol saya. Yang terakhir saya dapatkan. Itulah yang perlu saya panggil untuk memproses konten ketika-blok ini. Tiga yang pertama... yah, tidak begitu banyak. Angka "6" sebenarnya adalah nilai dari "faktor risiko". Oke, aku bisa pergi dengan itu. Yang tidak terdefinisi berada di luar jangkauan saya. Saya pikir Handlebars mencoba mengevaluasinya pada objek input, tetapi itu tidak akan berhasil. Saya ingin mendapatkan hal-hal yang sebenarnya _dalam_ template, karena nilai seperti ini tidak ada hubungannya dengan objek saya.

Saya mengharapkan sesuatu seperti ["riskfactor", "eq", "0", function()] . Hanya dengan begitu fungsi saya dapat melanjutkan dan memprosesnya. Bagaimana saya akan melakukannya dengan "tidak terdefinisi"?

Saya pikir filosofi Handlebars (dan template "kurang logika" lainnya) adalah bahwa konteks yang datang untuk template harus sudah diproses sepenuhnya. Jika struktur data internal aplikasi Anda tidak sepenuhnya selaras dengan apa yang sesuai untuk sebuah template (yang akan terjadi hampir setiap saat), maka Anda harus memasukkan langkah sebelum merender template yang membangun konteks template dari data internal aplikasi Anda struktur.

Saya percaya itulah maksud ketika orang berbicara tentang "memisahkan logika dari presentasi." Pikirkan Handlebars sebagai komponen tampilan dari sistem MVC. Model Anda sudah ada; yang harus Anda tulis sekarang adalah pengontrolnya (dalam hal ini, ini adalah kumpulan ikatan satu arah dari model ke tampilan).

Untuk menjawab pertanyaan terbaru Anda, Anda ingin menggunakan ini:

 {{#when "riskfactor" "eq" 0}}...{{/when}}

Ekspresi setang adalah nama variabel atau string. Jika itu adalah nama variabel, Anda akan mendapatkan nilai variabel saat mencari dalam konteks saat ini, bukan namanya.

Ini di luar bidang Handlebars seperti yang ditunjukkan beberapa orang.

Tidak.
Sistem template APAPUN dapat melakukan perbandingan if-else-block sederhana, dan Handlebars tidak bisa. Itu membuat Handlebars sangat tidak lengkap, pembuatnya tidak kompeten (yang tidak mungkin terjadi), atau sistem dengan perspektif kabur dari tugas sistem templating.

JANGAN gunakan MESIN TEMPLATE LOGICLESS LALU. KTHXBAI!

Mengerti. mie.

@thany , @andriijas mungkin agak kasar, tapi dia benar. Setang dimaksudkan untuk menjadi kurang logika. Anda pasti bisa membuat sepeda dengan motor, tetapi banyak perusahaan yang senang hanya membuat sepeda tanpa motor. Demikian juga, Anda dapat membuat sistem templat dengan lebih banyak logika, tetapi itu bukan sesuatu yang coba dilakukan Handlebars. Maaf bukan itu yang anda cari.

Saya harus memihak @thany di if helper. Kita harus bisa mewariskan predikat apapun ke dalamnya. Tidak dapat benar-benar membatasi utilitasnya. Saya memahami filosofi di balik templat tanpa logika tetapi implementasi dogmatis tidak benar-benar pragmatis (dan dengan demikian keberadaan pembantu, kan?). Saya akan mengatakan ini lebih seperti perusahaan sepeda yang menambahkan rasio roda gigi variabel, yang akan sangat masuk akal.

BTW, jika Anda ingin mengamuk terhadap mesin dan melakukan ini, Anda dapat membuat pembantu yang mengambil predikat sebagai string dan kemudian mengevaluasinya (dan menjadikannya dua kali sesat :smiling_imp:):

Handlebars.registerHelper('when', function (predicate, options) {
    var declarations = '';
    for (var field in this) declarations += field + ' = this.' + field + ',';
    if (eval(declarations + predicate)) { return options.fn(this); }
});

{{#when 'admin || superUser'}}
    crazy go nuts
{{/when}}

@thany melihatnya dari perspektif praktik terbaik, Back-end Anda harus menyajikan data dengan semua logika yang sudah ditemukan Front-end (templat) hanya harus merendernya ... jika Anda mendapatkan representasi JSON yang baik dari objek backend Anda dari 95 % kasus dapat dipenuhi dengan persyaratan bawaan http://handbarsjs.com/#conditionals

Serius, tidak SEMUA (atau bahkan 95%) keputusan yang dibuat berorientasi pada backend. Misalnya, untuk menentukan nama kelas mana yang akan dirender, sangat masuk akal untuk membuat keputusan itu di template. Sesuatu seperti itu 100% terikat pada frontend/templat. Backend tidak peduli nama kelas mana yang diberikan. Atau bagaimana dengan kata tunggal/jamak? Itu hal lain yang tidak bisa dilakukan dengan if-block.

Backend menurut saya bertanggung jawab untuk menyediakan data, dan data HANYA, ketika bekerja dengan template kaya seperti ini. Jika backend perlu memberikan variabel siap pakai pengurai templat untuk setiap situasi yang mungkin dapat diputuskan oleh templat (mempertimbangkan beberapa fleksibilitas di sini), mereka akan sangat rumit hanya dari jumlah variabel yang banyak, apalagi backend yang membuat mereka.

Anda juga dapat menempatkan HTML di backend jika setiap keputusan yang dibutuhkan template, memerlukan modifikasi lain di backend. Itu hanya menghilangkan sebagian besar tujuan template. Keputusan yang terkait dengan backend berada pada level yang sama sekali berbeda. Blok if belum tentu logika. Itu hanya memutuskan apa/bagaimana untuk membuat.

Saya tidak percaya masalah ini membutuhkan diskusi yang begitu panjang, apakah blok if yang tepat benar-benar terlalu banyak untuk diminta? :(

Saya tidak akan menentang atau menentang penerapan pembantu perbandingan dasar, tetapi ini adalah kasus yang sangat nyata di mana saya rasa saya tidak dapat merender template tanpa menggunakan pembantu atau mengubah struktur data:

    <select name="datatype">
      <option{{#ifeq type 'foo'}} selected="selected"{{/ifeq}}>foo</option>
      <option{{#ifeq type 'bar'}} selected="selected"{{/ifeq}}>bar</option>
      <option{{#ifeq type 'vaz'}} selected="selected"{{/ifeq}}>baz</option>
    </select>

Tetapi sekali lagi, pembantu yang saya tulis adalah tiga baris kode:

    Handlebars.registerHelper('ifeq', function (a, b, options) {
      if (a == b) { return options.fn(this); }
    });

saya setuju dengan @thany , saya juga tidak percaya bahwa ini adalah sesuatu yang harus berada di luar template/tampilan.

mengapa tepatnya template tidak memiliki logika di dalamnya? dan bagaimana setang memberikan pemisahan logika dan presentasi? masih ada pernyataan if bukan? apakah Anda mengatakan bahwa pernyataan if yang hanya menguji keberadaan dan/atau "kepalsuan" sama sekali tidak berbeda dengan pernyataan if yang memeriksa (dalam)kesetaraan atau kondisi lainnya?

satu-satunya perbedaan — nyata — adalah bahwa tidak seperti perpustakaan templat lainnya, setang memiliki implementasi logika yang sangat buruk/tidak lengkap dengan kedok "kurang logika". maaf, tapi itu sama sekali tidak masuk akal. jika Anda ingin menghapus logika, Anda harus menghapus pernyataan if sama sekali. Anda tidak akan melakukannya, karena pada akhirnya template membutuhkan logika untuk alasan yang sama mengapa setang masih memiliki pernyataan if .

jadi, pernyataan "memisahkan logika dari presentasi." salah, bukan hanya karena alasan di atas, juga karena Anda tidak menghapus "logika" dari template, Anda hanya memindahkannya ke bagian lain dari template — yaitu helper — dan mungkin Anda akan mendapatkan penggunaan kembali kode — yang akan menjadi hal yang baik - dan mungkin tidak, dalam hal ini Anda mungkin mendapatkan sejumlah pembantu yang melakukan hal yang hampir/persis sama dengan pembantu lainnya, karena perbedaan kecil yang akan lebih baik dengan memberikan implementasi yang benar dari if . bagaimana ini keputusan desain yang baik?

saya masih berjuang untuk memahami mengapa, jika "logika" tertentu secara inheren terikat pada pandangan tertentu dan tidak penting, signifikan dan/atau digunakan untuk apa pun selain pandangan itu sendiri, apa masalahnya sebenarnya. itu hanya terdengar seperti mvc ekstremisme/berlebihan bagi saya.

@andriijas jika saya bisa menggunakan perpustakaan templat yang berbeda, saya akan melakukannya, sayangnya keputusannya ada di tangan saya. seperti setiap dan semua rekomendasi untuk menggunakan perpustakaan template yang memungkinkan "logika" sayangnya akan jatuh di telinga tuli.

Adakah yang benar-benar melihat bagaimana saat ini jika diterapkan? (ada juga kecuali yang bagus)

Sekarang setelah Anda melihat bagaimana if saat ini diterapkan, mungkin lebih masuk akal bagi Anda mengapa setang memiliki standar yang sederhana dan elegan yang memuaskan kebanyakan orang.

Lihat di sini betapa mudahnya untuk memperpanjang

https://github.com/elving/swag

https://github.com/elving/swag/blob/master/src/swag.comparisons.coffee

Terimalah bahwa semua proyek open source Anda tidak menyediakan semua yang Anda butuhkan untuk memasak bacon Anda, hanya fondasinya.

@andriijas ya, unless hanya if dengan hasil terbalik. saya tidak melihat bagaimana ini mengkompensasi apa pun. terima kasih untuk tautan repo pembantu, saya sudah menulis pembantu, sekali lagi, saya tidak melihat bagaimana ini mengkompensasi apa pun.

Setang sedikit di atas 10kb (minzip) dan barang curian sedikit di bawah 3kb (minzip). Jadi Anda menambahkan perpustakaan template 10kb ke basis kode Anda dan Anda memerlukan 3kb lagi hanya untuk dapat menambahkan logika ke template Anda. logika yang Anda dan beberapa orang lain katakan seharusnya tidak Anda miliki di templat Anda?

ini tidak menjawab pertanyaan saya dan sebenarnya itu hanya berfungsi untuk membuktikan poin bahwa tidak masuk akal untuk melarang tes bersyarat selain keberadaan/kepalsuan di blok pernyataan if .

@andriijas Saya melihat /lib/handbars/base.js#L97 , tapi saya tidak begitu yakin apa yang Anda maksud. Sepertinya ada beberapa bentuk penggunaan alternatif, tetapi dokumentasi tidak menentukan ini. Maukah Anda menjelaskan?

@constantology beberapa orang mungkin membutuhkan 3kb lagi, Anda dan orang lain di utas ini misalnya. Sisanya dari 3500 yang membintangi repo ini di github kemungkinan tidak akan mengeluh, karena mereka telah menyelesaikan kebutuhan logika mereka dengan menambahkan pembantu atau melakukannya sebelum merender template.

@piksel apa yang Anda lihat adalah fakta bahwa built in if hanyalah pembantu seperti "addon" apa pun yang tampaknya bermasalah dengan banyak orang, berpikir bahwa pembantu lebih lambat atau semacamnya.

Tidak ada yang salah dengan menggunakan pembantu dalam proyek Anda. Dalam satu proyek saya menggunakan beberapa pembantu barang curian, disalin ke file view_helper saya sendiri sehingga bahkan kurang dari 3k.

Dalam satu proyek tulang punggung saya memiliki metode getTemplateData pada pandangan saya, di mana saya meringkas logika kompleks menjadi hal-hal yang lebih mudah yang membuat templat lebih bersih dan lebih mudah diikuti, ah dan juga, lebih mudah untuk menguji unit javascript biasa daripada templat setang.

@andriijas yang masih belum menjawab pertanyaan saya...

pada titik ini saya hanya akan mengulangi apa yang telah saya katakan, jadi jika Anda merasa benar-benar dapat memberikan jawaban yang masuk akal untuk salah satu atau semua pertanyaan yang telah saya ajukan, maka saya akan sangat senang mendengar apa yang Anda harus mengatakan. :)

ps jumlah orang yang membintangi repo dan/atau menggunakan perpustakaan tidak selalu merupakan indikasi seberapa bagus perpustakaan. ada lebih banyak pengguna windows daripada gabungan mac/linux dan — tergantung pada situs statistik browser mana yang Anda lihat — masih ada lebih banyak orang yang menggunakan gabungan internet explorer 6, 7 dan 8 daripada browser yang lebih modern. itu tidak membuat windows menjadi sistem operasi yang lebih baik daripada osx atau linux dan itu tidak membuat versi internet explorer yang lebih lama lebih baik daripada, standar modern, browser yang sesuai.

Seluruh diskusi ini tidak masuk akal bagi saya. Pembantu if ada di sana, ITU LOGIKA. Jadi seluruh argumen tanpa logika adalah benar-benar manusia jerami. Ini seperti jika mobil memiliki jendela yang hanya akan menggulung dan orang-orang mengeluh dan ingin jendela itu juga digulung. Dan pabrikan mengatakan mereka tidak akan mengubahnya karena mobil-mobil ini mengikuti filosofi ketat untuk tidak memiliki jendela yang dikontrol secara mekanis... Entah Anda mendukungnya atau tidak. Implementasi setengah-setengah tidak boleh dibenarkan dengan argumen manusia jerami.

Saya sangat setuju dan mengerti tidak memiliki logika bisnis dalam template. Tetapi kecuali Anda melakukan templat yang sangat sepele, Anda akan memiliki beberapa logika tampilan di sana. Handlebars jelas mengenali ini karena helper if ada. Mengatasi if helper yang lumpuh dengan menambahkan banyak logika tampilan dalam kode Anda bukanlah jawaban seperti yang ditunjukkan

@mikeobrien ya, saya sudah menyebutkannya di komentar sebelumnya . itu adalah salah satu dari banyak pertanyaan yang belum terjawab.

Saya sangat setuju dan mengerti tidak memiliki logika bisnis dalam template. Tetapi kecuali Anda melakukan templat yang sangat sepele, Anda akan memiliki beberapa logika tampilan di sana.

baik menempatkan. :^)

@constantology doh, maaf, kurasa aku seharusnya membaca komentar sebelumnya dengan lebih baik. :/

Saya setuju dengan @constantology

FWIW Saya menemukan Handlebars sebagai perpustakaan template yang sangat elegan dan ditulis dengan baik.

Saya memahami konsep blok dan helper dengan baik, namun, saya tidak berpikir bahwa membuat helper untuk melakukan sesuatu yang kecil — yang dapat ditangani lebih elegan dengan mendukungnya di perpustakaan inti — berarti pemisahan yang jelas antara logika dan presentasi. CSS menambahkan dukungan untuk pernyataan bersyarat dan beberapa di antaranya sudah dapat dicapai dengan kueri media, jadi logika dalam bahasa presentasi murni belum tentu merupakan masalah besar, jika hanya "melihat logika" seperti yang dikatakan @mikeobrien .

Saya merasa bahwa satu batasan ini — kurangnya pemeriksaan bersyarat di blok if / unless — membuat sangat sulit untuk membuat template yang elegan dan terenkapsulasi.

Juga, saya juga setuju dengan memiliki metode untuk memproses data sebelum menguraikannya melalui templat, namun, hanya untuk perubahan sederhana, bukan untuk memformat ulang seluruh struktur data untuk membengkokkannya ke kehendak perpustakaan mana pun. Mengapa?

1. ini berpotensi memengaruhi keseluruhan kinerja penguraian jika Anda perlu mengambil struktur data yang kompleks dan membuat sesuatu yang lebih datar.
2. berdasarkan 1 , itu berpotensi , membuat kode tampilan Anda lebih rapuh — dan lebih sulit untuk difaktorkan kembali — jika perubahan dilakukan pada skema asli.
3. itu juga bisa membuat pengikatan data dua arah lebih rumit karena Anda tidak lagi memetakan struktur data asli ke tampilan, sehingga meningkatkan jumlah kode yang mungkin Anda perlukan untuk melacak perubahan.

Itu hanya di luar kepala saya, saya belum melakukan penelitian terukur untuk mendukung semua itu, tetapi ini adalah bahan untuk dipikirkan. :^)

untuk pertanyaan awal, a if helper dengan perbandingan akan menjadi hal yang salah. ini adalah skenario umum dan pembantu seperti:
{{#ifzero count}}Tidak ada hasil{{/ifzero}}
{{#ifsingular count}}1 hasil{{/ifsingular}}
{{#ifplural count}}{{count}} hasil{{/ifplural}}
akan lebih membantu dan akan menerjemahkan apa yang benar-benar ingin dia lakukan. sintaks if saat ini berguna untuk (tidak) menampilkan nilai kosong. skenario yang sangat umum juga. jika seseorang benar-benar membutuhkan if dengan perbandingan, kemungkinan besar itu adalah logika bisnis dan dia tidak boleh melakukannya di templat.

Itu akan melakukannya memang.
Namun, saya masih berpikir itu bukan mesin untuk memaksa pengembang ke sudut tertentu, apakah itu _pada prinsipnya_ sudut yang baik, atau tidak. Saya pikir itu harus terserah kepada pengembang yang merupakan logika bisnis, dan mana yang merupakan logika template.

Artinya, kecuali batasan tidak bisa melakukan perbandingan adalah murni batasan teknis yang entah bagaimana membuatnya menjadi paradigma. Itu hanya berarti fungsi seperti itu tidak akan pernah bisa ditambahkan jika diperlukan. Saya harap bukan itu yang terjadi.

Menguji thany. Pengujian. Anda tidak ingin membuat perbandingan dalam template karena Anda tidak dapat menguji logika ini dengan mudah. Jauh lebih mudah untuk membuat nilai boolean sederhana melalui formatter data untuk template Anda, dan mengujinya, daripada menghubungkan ke sesuatu seperti Selenium dan mengujinya di sana.

Ini bukan hanya teori, ini bukan hanya 'prinsip'. Mungkin akan menjadi omong kosong utang teknis dunia nyata untuk menempatkan bahkan perbandingan dalam template, dan untuk tidak menguji logika ini. Jangan menulis atau menggunakan pembantu ini. Saya belum menggunakan helper untuk setang. Namun jika Anda memang menggunakan pembantu, Anda bisa memata-matai dan menguji untuk memastikan hal itu berjalan, jadi itu lebih baik daripada perbandingan yang dibangun ke dalam template.

Ada banyak sistem template bebas logika yang tidak menawarkan perbandingan. Misalnya dalam bahasa yang diketik dengan kuat seperti go, apa artinya kesetaraan? Tidak ada perbandingan dalam template Go. Ada implementasi kumis dan stang di berbagai bahasa dan semuanya sama.

Menghapus logika seperti perbandingan dari template tidak membuat hidup Anda lebih sulit, itu membuatnya lebih mudah. Utang teknis bukanlah lelucon, dapat merusak produk dan bahkan perusahaan.

Ayo.
Perbandingan tidak terlalu sulit. Ini bukan ilmu roket (atau operasi otak).

Dalam template mikro yang sangat sederhana, Anda tidak memerlukan logika, tetapi jika menjadi lebih rumit, Anda akan memerlukan logika dalam template. Ada yang namanya "logika bisnis" dan juga "logika template". Menentukan apa yang harus dilakukan ketika hanya ada satu item dari sesuatu, atau dua, atau sepuluh. Halaman, misalnya. Jangka pembagi garis. Teks sederhana "di bawah 50%" & "lebih dari 50%", dan saya bisa melanjutkan.

Fakta bahwa mesin template lain juga tidak memiliki logika di dalamnya, tidak berarti Anda harus mengikuti mereka secara membabi buta. Mereka juga salah, menurut saya.

Faktanya adalah, pada titik tertentu, Anda akan memiliki semacam logika yang tidak Anda butuhkan atau inginkan dalam logika bisnis, hanya karena itu bukan logika bisnis. Saya tidak dapat berkomunikasi dengan sesama pengembang yang memiliki nilai boolean, untuk setiap jenis perbandingan yang mungkin dibutuhkan oleh template saat ini atau di masa mendatang.

"dapat merusak produk dan bahkan perusahaan"? Dengan serius?
Fungsionalitas yang tidak tepat juga bisa.

Apa yang salah dengan itu mengirimkan apa yang dibutuhkan kebanyakan orang dan Anda menambahkan pembantu
untuk apa yang Anda butuhkan? Semua orang menang. Tidak terlalu sulit, tidak seperti roket
Sains.

Jika itu ilmu roket: https://github.com/elving/swag

Pada hari Sabtu, 18 Mei 2013, thany menulis:

Ayo.
Perbandingan tidak terlalu sulit. Ini bukan ilmu roket (atau operasi otak).

Dalam templat mikro yang sangat sederhana, Anda tidak memerlukan logika, tetapi jika ada
lebih rumit, Anda akan membutuhkan logika dalam template. Ada seperti itu
hal sebagai "logika bisnis" serta "logika template". Menentukan apa yang harus
lakukan ketika hanya ada satu item dari sesuatu, atau dua, atau sepuluh. Halaman, untuk
contoh. Jangka pembagi garis. Teks sederhana "di bawah 50%" & "lebih dari 50%", dan saya bisa melanjutkan.

Fakta bahwa mesin template lain juga tidak memiliki logika di dalamnya,
tidak berarti Anda harus mengikuti mereka secara membabi buta. Mereka juga salah, di my
pendapat.

Faktanya adalah, pada titik tertentu, Anda akan memiliki semacam logika yang baru saja Anda
tidak perlu atau ingin dalam logika bisnis, hanya karena itu bukan bisnis
logika. Saya tidak dapat berkomunikasi dengan sesama pengembang karena nilai boolean
di, untuk setiap jenis perbandingan yang dapat dibayangkan bahwa saat ini atau di masa depan
template yang pernah dibutuhkan.

"dapat merusak produk dan bahkan perusahaan"? Dengan serius?
Fungsionalitas yang tidak tepat juga bisa.

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/wycats/handbars.js/issues/206#issuecomment -18104713
.

Kebanyakan orang _tidak_ menggunakannya mungkin karena masalah yang dijelaskan di sini: tidak ada logika. Jadi tentu saja kebanyakan orang yang aktif menggunakannya akan kurang lebih puas dengannya.

@thany saya merasa Anda dan saya setuju dengan Anda.

Saya pikir orang-orang di belakang setang tidak mau menyerah pada yang satu ini, tapi hei, apa yang akan saya katakan kepada Anda adalah berita yang luar biasa:
Anda dapat _fork _ proyek, menambahkan tambalan dan menggunakan garpu Anda sendiri.
Karena keajaiban git, seharusnya cukup mudah untuk mengikuti versi baru hanya dengan git pull ing.

Dan tunggu, itu akan lebih baik.

Jika ini merupakan kebutuhan besar dan secara keseluruhan lebih baik, mungkin orang akan mulai menggunakan garpu Anda atau bahkan lebih baik lagi, orang-orang di belakang setang akan menggabungkan garpu Anda kembali ke Origin/master :dancer:

semoga bermanfaat ;D

Jika saya akan memberikan diri saya waktu, tentu!

Saya sangat setuju dengan @constantology. Gila punya template tanpa logika. Dan jika Anda ingin memiliki template tanpa logika mengapa Anda meletakkan di sana pernyataan: "jika" yang mewakili logika sebagai bahaya warna merah ... Tidak masuk akal. Saya pikir logika perbandingan dasar diperlukan sebagai garam dalam sup. @mikeobrien : "Implementasi setengah-setengah tidak boleh dibenarkan dengan argumen pria jerami." :+1:

Ada sesuatu yang bisa dikatakan untuk template tanpa logika. Padahal, saya merasa masalahnya adalah semua orang di sini membingungkan logika bisnis dengan logika tampilan. Logika bisnis tidak memiliki tempat di template. Periode. Lihat logika, bagaimanapun, adalah masalah lain sama sekali. Saya pikir Handlebars menyadari hal ini, itulah sebabnya mereka menambahkan if/else di tempat pertama, mereka hanya sedikit bingung di sepanjang jalan.

Saya perlu tahu apakah array data saya memiliki satu atau beberapa item, dan berdasarkan itu saya ingin menggabungkannya dengan koma, atau menambahkan jamak ke kata. Dengan blok if saat ini, saya tidak bisa melakukan ini.

Inilah sebabnya saya membuat permintaan tarik ini: https://github.com/wycats/handbars.js/pull/566 dan jsfiddle yang menyertai: http://jsfiddle.net/YsteK/

Permintaan tarik ini menyediakan pembantu baru: ifTest, yang mengambil ekspresi javascript yang mengevaluasi seperti javascript yang diberikan konteksnya. Menikmati.

Sejujurnya ini adalah fungsi dasar yang membuat saya merasa bahwa jika Anda ingin tetap berpegang pada pola pikir ini karena tidak memiliki logika yang dibangun ke dalam kerangka kerja (yang tampaknya sama sekali tidak logis bagi saya!), Anda perlu mempertimbangkan kembali penggunaan istilah logis seperti "jika" .

Saya mendapati diri saya menambahkan ini ke banyak proyek saya hanya karena sangat membantu ketika membandingkan hal-hal seperti "0" dan "1" dengan nilai boolean lainnya:

Handlebars.registerHelper('ifCond', function(v1, v2, opsi) {
jika(v1 === v2) {
kembali options.fn(ini);
}
kembali opsi.inverse(ini);
});

Saya pikir benar-benar adil untuk membuat fungsi "jika" yang ada berfungsi seperti itu, tetapi bantulah bahasa Inggris dan pilih kata lain (atau buat itu melakukan apa yang orang harapkan). Rasanya seperti penyimpangan nyata dari istilah "jika" ketika itu tidak berperilaku seperti pernyataan benar jika dalam konteks lain.

Saya ingin menambahkan suara lain untuk menghapus if seluruhnya, atau mengizinkan if menerima beberapa argumen perbandingan dasar, misalnya eq , ne , gt , dll. Anda akan mendapatkan {{#if arg1 eq arg2}} . Tentu saja, menghapus if seluruhnya akan lebih masuk akal untuk filosofi "tidak ada logika dalam templat" Anda (saat ini lebih seperti "tidak ada logika dalam templat _sebagian besar waktu_ tetapi _kadang-kadang_ tidak apa-apa").

Tanpa pembantu, saya akhirnya melakukan hal-hal seperti ini sepanjang waktu:

<select>
    <option value='ak' {{#if ak_selected}}selected{{/if}}>AK</option>
    <option value='al' {{#if al_selected}}selected{{/if}}>AL</option>
    <option value='ar' {{#if ar_selected}}selected{{/if}}>AR</option>
    <option value='az' {{#if az_selected}}selected{{/if}}>AZ</option>
    <option value='ca' {{#if ca_selected}}selected{{/if}}>CA</option>
    ....
</select>

Yang tampaknya agak konyol untuk menambahkan semua properti tambahan itu ke suatu objek.

webgovernor - Lihat ini: http://jsfiddle.net/YsteK/

Ini adalah pembantu yang mengaktifkan fungsi ini. Dibutuhkan ekspresi javascript yang mengevaluasi seperti javascript akan diberikan konteksnya. Menikmati.

Terima kasih tniswong, itu sangat mirip dengan pembantu saya. Saya memiliki masalah yang terpecahkan, saya hanya ingin menyoroti kemunafikan dari dogma "kurang logika" Handlebars.

Tidak masalah. Aku di sana bersamamu. Saya suka setang, tetapi sangat tidak berguna tanpa penolong ini.

Saya mengirimkan pembantu ini sebagai permintaan tarik tetapi ditolak. Jadi saya mengajukan permintaan tarik lain yang menghapus blok if. Juga ditolak. /mendesah

Ha ha ha. Github membutuhkan tombol upvote.

Itu ditolak? -_-

Ketegaran agama setang yang tidak masuk akal benar-benar membingungkan.

566 dan #568

Dia menyebutkan dia mungkin menambahkannya ke README, tapi saya tidak menahan napas.

+1 untuk ini! Argghhh!

FWIW, repo Swag menyediakan pembantu yang menambahkan perbandingan, penyortiran, dan hal-hal bagus lainnya. Saya tidak membangun apa pun di Handlebars tanpa itu.

Yang mengatakan, saya pribadi setuju dengan membiarkan Handlebars tetap logika-kurang mungkin karena tetap bersih, dapat diperluas dan dipelihara. Jika Anda menginginkan lebih, kontribusikan ke repo seperti _Swag_ untuk hal-hal di luar cakupan proyek. Jika pengelola proyek ini berubah pikiran, yang diperlukan hanyalah permintaan tarik :+1:

@aboutaaron Jika Anda akan membuat pernyataan seperti, "membiarkan Handlebars tetap

1. memberikan bukti bahwa setang tidak mengandung logika. Jika Anda telah membaca utasnya maka Anda akan melihat bahwa telah terbukti bahwa setang berisi logika yang tidak lengkap dalam bentuk pernyataan if yang hanya memeriksa "kebenaran", jika Anda belum membaca utasnya maka saya akan menyarankan Anda melakukannya.
2. memberikan bukti bahwa setang memberikan logika yang tidak lengkap dalam bentuk pernyataan if yang hanya memeriksa "kebenaran", dalam beberapa cara, "menjaganya tetap bersih, dapat diperluas, dan dapat dipelihara".
   Bukankah ini kontradiksi? Jika setang dapat diperpanjang, bukankah itu berarti akan sepele untuk memberikan implementasi lengkap dari pernyataan bersyarat?
   Bagaimana, misalnya, setang yang memberikan pernyataan if membuatnya kurang bersih, dapat diperluas, dan dapat dipelihara daripada pengembang yang menggunakan setang DAN barang curian ?
   Orang dapat berargumen bahwa menggunakan pembantu barang curian akan membuat basis kode kurang bersih, dapat diperluas, dan dapat dipelihara karena Anda perlu menggunakan pembantu yang berbeda untuk setiap operator perbandingan, yaitu gt , gte , is , isnt , lt , lte serta untuk setiap operator logika, yaitu and , or .
   Bagaimana ini membuat kode lebih mudah dibaca daripada melakukan semua ini sama seperti yang dilakukan — di dalam pernyataan if — dalam bahasa lain? Jika ini masalahnya maka saya akan menganggap bahasa pemrograman itu sendiri akan menghilangkan pernyataan bersyarat yang memeriksa apa pun selain "kebenaran"? Saya tidak melihat ini terjadi.

Jika kebetulan Anda akan menggunakan argumen lelah — dan tidak terbukti — dari "menempatkan logika bisnis dalam template", tolong jangan. ini telah dibahas — beberapa kali, oleh beberapa orang —di utas ini. Pada saat yang sama, jika itu adalah sesuatu yang Anda anggap sebagai argumen yang valid, maka itu akan menghilangkan kebutuhan untuk menggunakan perpustakaan barang curian , yang bertentangan dengan pernyataan Anda sebelumnya.

Kesimpulannya, fakta bahwa ada beberapa perpustakaan di luar sana yang berusaha menambahkan kelengkapan pada implementasi if di setang — dengan satu atau lain cara — menunjukkan bahwa ada kebutuhan untuk jenis fungsi ini di dalamnya. inti. Lihatlah bahasa JavaScript itu sendiri, Harmony memperkenalkan banyak fitur yang telah disediakan oleh perpustakaan pihak ketiga, iterator, modul, generator, kelas, proxy, dll; dan DOM API juga telah mengimplementasikan fitur yang disediakan oleh perpustakaan pihak ketiga, querySelector[All], CORS dan bahkan ada implementasi dari DOM Promises di chrome canary.

Tidak ada bukti bahwa "membiarkan Handlebars tetap selogis mungkin karena membuatnya tetap bersih, dapat diperluas, dan dapat dipelihara". Pada saat yang sama, yang lain dan saya telah menunjukkan — dalam komentar sebelumnya dari utas ini — bahwa sedikit dapat membantu, jika setang menyediakan implementasi if itu akan memberi pengembang API terpadu untuk dibuat template mereka lebih mudah dibaca dan dipelihara.

@konstantologi +1 Amin.

Saya baru saja tiba di sini setelah mencoba {{#if something > something_else}} dan menyadari kebenaran dari situasi ini. Namun, saya tergoda untuk setuju dengan setang orang yang satu ini. Saya menggunakan cairan untuk waktu yang lama, dan utas komentar seperti ini pasti mengarah pada penambahan fitur setengah matang seperti matematika dan penggabungan string yang benar-benar termasuk di bagian belakang.

Tujuan dengan pernyataan if "tanpa logika" tampaknya adalah: lakukan bagian logika di bagian belakang, dan sajikan setang dengan "jawaban" sebagai variabel tunggal. Jika jawabannya "ya" lakukan ini, jika tidak lakukan hal yang lain. Saya tidak melihat masalah dengan itu (setelah membaca komentar di atas), dan saya akan memperbaiki kode saya sekarang.

Bekerja pada beberapa aplikasi Ember dan ingin melemparkan pendapat saya. Saya merasa pernyataan #if akan lebih baik jika _(opsional)_ menerima argumen. Saya benar-benar mengerti keinginan untuk meninggalkan sesuatu logic-less , tetapi kadang-kadang bisa sangat membuat frustrasi untuk bekerja.

Bayangkan daftar pertanyaan sederhana yang dipilih atau tidak dipilih. Sungguh, apa perbedaan antara dua blok logika ini?

{{#if isSelected question}}
  <p>This question is selected</p>
{{else}}
  <p>This question is NOT selected</p>
{{/if}}

{{#if question.isSelected}}
  <p>This question is selected</p>
{{else}}
  <p>This question is NOT selected</p>
{{/if}}

Ada perbedaan yang cukup besar dalam bagaimana saya perlu menulis kode yang mendukung dua contoh ini. Akan sangat menyenangkan memiliki fleksibilitas untuk memilih juga. Saya juga tidak benar-benar melihat bagaimana yang pertama mengandung lebih banyak logika daripada yang kedua.

Saya merasakan hal yang sama seperti yang dikatakan utas ini. Kemudian, saya menemukan utas ini.
Oleh karena itu, saya kira saya baru saja memahami filosofi Handlebars.
Kemudian, saya menemukan apa yang saya butuhkan adalah koleksi pembantu seperti Swag.

Sekarang saya tidak punya masalah karena Swag akan membantu saya.
Namun, saya menjadi bingung karena helper if default terlalu sederhana.
Jika Anda mengatakan Hanbar tidak memiliki logika, saya ragu Handlebars membutuhkan pembantu bawaan.
Jika tidak memiliki pembantu bawaan, saya pikir saya dapat memahami filosofi Handlebars dengan lebih mudah.

Saya mungkin tidak memiliki pemahaman yang baik tentang logic-less dan business logic , saya ingin memberi tahu Anda apa yang saya pikirkan.

Saya percaya bahwa Anda tidak dapat menganggap satu jika/kecuali (tanpa persyaratan) sebagai logika, karena hanya -dalam konteks tanpa logika- sarana untuk mewakili data boolean, sebagai "{{foo}}" sintaks adalah sarana untuk mewakili data string.

Jadi saya pikir perilaku berikut harus dihentikan: "Jika tidak logis, mengapa ada pernyataan if? HA-HA, skakmat!!!"

Kemudian ubah ke "{{#exists}}" alih-alih "{{#if}}" karena itu lebih masuk akal.

Pada 5 Oktober 2013, pukul 10:52, cal127 [email protected] menulis:

Saya percaya bahwa Anda tidak dapat menganggap satu jika/kecuali (tanpa persyaratan) sebagai logika, karena hanya -dalam konteks tanpa logika- sarana untuk mewakili data boolean, sebagai "{{foo}}" sintaks adalah sarana untuk mewakili data string.

Jadi saya pikir perilaku berikut harus dihentikan: "Jika tidak logis, mengapa ada pernyataan if? HA-HA, skakmat!!!"

—
Balas email ini secara langsung atau lihat di GitHub.

:thumbsup: untuk mengubah {{#if}} menjadi {{#exists}} atau {{#isTrue}}

Saya setuju bahwa kita dapat menemukan nama yang lebih masuk akal. 'ada' akan melakukannya, dan saran saya akan menjadi 'benar' atau 'aktif'.

Namun meski demikian, nama 'seandainya' masih lebih tepat karena alasan historis. Handlebars' jika implementasi secara sintaksis tidak berbeda dengan implementasi if lainnya, ini sesuai dengan sintaks "if ([predikat]) [do sth]" yang lama.

Yang berbeda adalah [predikat] harus berupa variabel bool kosong, tidak boleh berupa ekspresi. Tapi ini bukan batasan 'jika'. Ini adalah batasan yang lebih umum yang disebabkan oleh kurangnya dukungan untuk ekspresi penerjemah Handlebars. (Itulah yang membuat Handlebars kurang logis, menurut saya)

Yang berarti 'jika' ini tidak berbeda dengan 'jika' lainnya.

Dan mencoba mengganti nama 'jika' mungkin dianggap bid'ah oleh sebagian orang, jangan bilang saya tidak memperingatkan Anda.

Sebut saja {{#truthy}} dan {{#falsey}} karena hanya itu yang dilakukan {{#if}} dan {{#unless}} .

Untuk para pengembang: keluarkan kepala Anda dari pasir. Dengan serius. Anda dapat melihat bahwa ada permintaan untuk pernyataan if yang tepat (dan saya bermaksud menggunakan kata 'permintaan' secara harfiah) jadi pergilah dan terapkan, alih-alih mengeluh tentang ketidakberdayaan. Jika Anda ingin template Anda tidak memiliki logika, singkirkan SEMUA logika, termasuk {{#if}} dan {{#each}} .

HANYA menerapkan pernyataan if yang tepat.
Orang-orang yang sangat percaya pada ketidakberdayaan mereka, harus memilih untuk tidak menggunakannya. Sederhana. Sebagai. Itu.

Aku bahkan sudah melakukan pekerjaan untukmu.

https://github.com/wycats/handbars.js/pull/566
https://Gist.github.com/tniswong/5910264

Pada 5 Oktober 2013, pukul 15:20, thany [email protected] menulis:

Sebut saja {{#truthy}} dan {{#falsey}} karena hanya itu yang {{#if}} dan {{#unless}} lakukan.

Untuk para pengembang: keluarkan kepala Anda dari pasir. Dengan serius. Anda dapat melihat bahwa ada permintaan untuk pernyataan if yang tepat (dan saya bermaksud menggunakan kata 'permintaan' secara harfiah) jadi pergilah dan terapkan, alih-alih mengeluh tentang ketidakberdayaan. Jika Anda ingin template Anda menjadi tidak logis, singkirkan SEMUA logika, termasuk {{#if}} dan {{#each}}.

HANYA menerapkan pernyataan if yang tepat. Orang-orang yang sangat percaya pada ketidakberdayaan mereka, harus memilih untuk tidak menggunakannya. Sederhana. Sebagai. Itu.

—
Balas email ini secara langsung atau lihat di GitHub.

Terima kasih untuk itu, tetapi solusinya harus dalam paket inti. Istilah "ifTest" mungkin hanya karena Handlebars membajak istilah "jika" sebelum Anda dapat menggunakannya.

Hal lain adalah bahwa ifTest Anda mengambil string, dan melakukan evaluasi string itu dalam runtime, sedangkan jika blok if yang tepat akan ada dalam paket inti, itu bisa di templat yang dikompilasi (yang merupakan salah satu dari Handlebars yang kuat poin - salah satu yang saya tidak suka membuang ke laut dengan menggunakan eval() untuk ifs dan elses)

Anda 100% benar. Hanya menggunakan alat yang tersedia bagi saya saat itu.

Terlepas dari itu, itu berhasil.

Pada 5 Oktober 2013, pukul 15:41, thany [email protected] menulis:

Terima kasih untuk itu, tetapi solusinya harus dalam paket inti. Juga, istilah "ifTest" mungkin hanya karena Handlebars membajak istilah "jika" sebelum Anda dapat menggunakannya. Hal lain adalah ifTest Anda mengambil string, dan melakukan evaluasi string itu dalam runtime, sedangkan jika blok if yang tepat ada dalam paket inti, itu bisa di templat yang dikompilasi (yang merupakan salah satu dari Handlebars yang kuat poin - salah satu yang saya tidak suka membuang ke laut dengan menggunakan eval() untuk ifs dan elses)

—
Balas email ini secara langsung atau lihat di GitHub.

Baru saja menemukan utas ini saat mencari perbandingan di Handlebars. Saya pikir Anda harus menghapus / mengganti nama blok {{#if}} dan {{#each}} , atau menerapkan pernyataan if yang tepat. Ini adalah fitur dasar untuk setiap bahasa. Periode. Jika Anda benar-benar menginginkan template tanpa logika, mengapa Anda tidak menggunakan Kumis saja?

Saya mengerti bahwa ada pendapat di antara pengembang bahwa template harus dapat dibaca oleh non-pengembang (yaitu desainer). Tapi A) Saya tidak pernah bekerja dengan desainer di mana ini menjadi masalah, dan B) Saya pikir pendekatannya adalah bahwa solusi generik tersedia bawaan, dan sebagai ekstensi Anda dapat menggunakan pemeriksaan boolean-only, jadi Anda punya sebuah pilihan. Plus, menambahkan pembantu seperti {{#ifValueEqualsA}} dan {{#ifValueEqualsB}} akan memaksa Anda untuk membuat banyak kode boilerplate yang sebenarnya tidak diperlukan. Saya bekerja di proyek seluler yang tidak terlalu besar dan saya sudah memiliki 200 baris kode yang hanya menambahkan perbandingan untuk kebutuhan tertentu. Itu bertentangan (semoga) setiap pola pikir pengembang bahwa segala sesuatunya harus se-generik mungkin.

@ cal127 "Saya percaya bahwa Anda tidak dapat menganggap satu jika/kecuali (tanpa persyaratan) sebagai logika" - Jadi apa masalahnya? Mengapa memeriksa ekspresi lebih logis daripada memeriksa nilai boolean? Ini adalah cek. Periode. Itulah logika yang dilakukan di sini, bukan ekspresi (karena nilai boolean adalah - tebak apa- ekspresi). Tentu saja, dengan asumsi bahwa ekspresi tidak mewakili bisnis-, tetapi logika UI.

Saya minta maaf ide mesin template logika-kurang tampaknya sudah hampir mati ... saya tidak melihat ini masih terjadi di masa depan. Pengembang membutuhkan alat yang membuat segalanya lebih mudah dan lebih cepat tidak lebih rumit.

@thany batu. Saya datang tentang kumis (lang template tanpa logika lain) kemarin dan ini adalah pertanyaan yang muncul di kepala saya beberapa saat kemudian. Bagaimana programmer pernah berpikir ini keren. Ini hanya memperburuk keadaan. Paradigma pemrograman yang saya tahu adalah "pemisahan logika BISNIS dari logika PRESENTASI". Def itu berarti ada logika dalam presentasi (tampilan yang berisi/menyertakan template dalam pola seperti mvc misalnya). Kenapa mereka mencoba untuk meniadakan itu dan menghapus logika dari presentasi.

Skenario: Saya menjalankan loop dalam tampilan dan saya ingin melakukan tindakan setelah x iterasi. Dengan setang saya sekarang harus membuat pembantu dan kemudian menggunakannya dalam lingkaran kan? bagaimana ini membuat hidup saya lebih mudah? Apa yang terjadi jika count==x????? Bagaimana itu lebih baik daripada menggunakan bahasa seperti php itu sendiri untuk templating Anda? Bagaimana itu membantu desain di atas mesin templat logis?

Aku? Tidak ada apa pun yang kurang logika untuk pekerjaan yang berorientasi logika. Maaf!

Saya tidak percaya betapa bodohnya Anda, orang-orang yang percaya pada logika. Itu bukan kenyataan, itu mitos lengkap, kekeliruan, agama palsu. Tidak ada templat lebih dari beberapa baris yang sepenuhnya tidak masuk akal. Hanya saja tidak praktis.

Sekarang, untuk menerapkan keyakinan seperti itu kepada pengguna Anda sepenuhnya adalah keputusan Anda. Tetapi untuk terus mengabaikan permintaan logika adalah bukti kebodohan dan ketidaktahuan. Terutama dalam kasus khusus ini, karena sudah ada sejumlah logika yang mungkin, meskipun sangat kecil.

Sekali lagi, saya sangat mendorong Anda untuk mempertimbangkan kembali. Tidak, tunggu, jangan pertimbangkan lagi. Dengarkan saja dan lakukan hal yang benar. Orang-orang yang tidak menginginkan logika konyol itu dalam template mereka, dapat melanjutkan dan melanjutkan cara jahat mereka dan melompati semua jenis rintangan agar tidak menggunakan logika.

Memperluas blok if untuk melakukan perbandingan yang tepat tidak menghilangkan penggunaannya saat ini. Itu tidak akan membuat masalah bagi mereka yang belum melihat cahaya logis, orang-orang itu dapat terus membuat kode seperti semula.

Ini bukan tentang keren; Anda sendiri menggunakan pemisahan logika dari presentasi sebagai argumen kemudian mengabaikannya untuk meminta hidup Anda disederhanakan. Anda bisa menambahkan salah satu pustaka templat setang standar ke proyek Anda atau menulis milik Anda sendiri.

Anda atau tidak ada orang lain yang telah membahas salah satu dari banyak argumen menentang ini di salah satu dari banyak utas. Agar argumen-argumen itu jelas di utas ini:
1) Anda akan mengganggu ekosistem yang ada; yang akan menyebabkan konflik dan pengerjaan ulang untuk tim yang ingin memperbarui tetapi memiliki IF sendiri selama ~2 tahun.
2) Ada perpustakaan pembantu yang akan menambahkan jika Anda perlu, bersama dengan semua pembantu lain yang akan Anda minta selanjutnya.
3) Segera setelah disetujui untuk menambahkan 'jika' ini, argumen baru akan menjadi implementasinya. Nama. Sintaksis. Argumen. Anda mungkin berjanji untuk bahagia dengan jika itu muncul, tetapi yang lain tidak. Akan segera ada utas baru di sini dengan alasan itu harus bekerja dengan cara lain.
4) 'jika' yang ada persis seperti yang seharusnya ada untuk -rendering-. "Tampilkan X jika Y ada". Ini bukan tentang logika bisnis; yang harus terjadi dalam model Anda (saya sarankan Backbone, maka Anda dapat memiliki apa pun yang Anda inginkan, untuk menjadi metode isXXX() pada model Anda).

Karena kita saling menanyakan sesuatu, tolong jangan lanjutkan ini jika Anda tidak memiliki argumen teknis yang cukup bagus untuk membuat perubahan besar. Menjadi frustrasi itu konyol - Tambahkan 'JIKA' yang Anda inginkan dan selesai.

1) Tidak, Anda tidak akan melakukannya. Jika Anda tidak melakukan apa-apa, template akan tetap berfungsi. Tentu saja semuanya harus kompatibel ke belakang. Dan bahkan jika tidak, maka jangan tingkatkan.
2) Pernyataan if adalah elementer. Apa yang Anda katakan seperti roda pada mobil sekarang opsional.
3) Sintaks dari pernyataan if tidak begitu penting. Setiap bahasa pemrograman memiliki satu, dan masing-masing dari mereka melakukan hal yang persis sama. Jadi pilih satu dan itu akan baik-baik saja. Lebih penting lagi, memiliki pernyataan if APAPUN yang tepat lebih baik daripada yang kita miliki sekarang.
4) Salah, cari ke atas untuk "logika template".

Adapun sikap terakhir Anda, argumen _telah_ dibuat, dan itu masuk akal. Ini telah diperdebatkan berulang kali, tetapi itu benar-benar tampak seperti sebuah agama. Tidak bisa dipecahkan, namun begitu rapuh.

George Frick-

1) Apa bedanya dengan memutakhirkan kerangka kerja atau pustaka APAPUN lain yang pernah ada?
2) Anda benar. Padahal, menambahkan fitur dasar ini secara manual seharusnya tidak diperlukan untuk sesuatu yang begitu mendasar dan perlu.
3) Itulah gunanya Permintaan Tarik.
4) Anda benar-benar melewatkan intinya. Tidak ada seorang pun di utas ini yang memperdebatkan logika bisnis di lapisan tampilan. Kami berdebat untuk logika tampilan BERMANFAAT di lapisan tampilan. Kata "if" yang diberikan bukanlah true if, sehingga membingungkan bagi siapa saja yang pernah menggunakan bahasa pemrograman. Ini lebih dari "ada".

Jika Anda berpikir menambahkan ini akan menyebabkan orang menggunakan logika bisnis dalam templat, Anda mungkin benar karena Anda tidak dapat memperbaiki kebodohan. Hanya karena seseorang BISA melakukan sesuatu yang buruk tidak berarti Anda harus mencegah orang lain melakukan sesuatu yang baik (dan perlu) dalam prosesnya.

Pada 22 November 2013, pukul 15.55, George Frick [email protected] menulis:

Ini bukan tentang keren; Anda sendiri menggunakan pemisahan logika dari presentasi sebagai argumen kemudian mengabaikannya untuk meminta hidup Anda disederhanakan. Anda bisa menambahkan salah satu pustaka templat setang standar ke proyek Anda atau menulis milik Anda sendiri.

Anda atau tidak ada orang lain yang telah membahas salah satu dari banyak argumen menentang ini di salah satu dari banyak utas. Hanya saja agar argumennya jelas di utas ini:
1) Anda akan mengganggu ekosistem yang ada; yang akan menyebabkan konflik dan pengerjaan ulang untuk tim yang ingin memperbarui tetapi memiliki IF sendiri selama ~2 tahun.
2) Ada perpustakaan pembantu yang akan menambahkan jika Anda perlu, bersama dengan semua pembantu lain yang akan Anda minta selanjutnya.
3) Segera setelah disetujui untuk menambahkan 'jika' ini, argumen baru akan menjadi implementasinya. Nama. Sintaksis. Argumen. Anda mungkin berjanji untuk bahagia dengan jika itu muncul, tetapi yang lain tidak. Akan segera ada utas baru di sini dengan alasan itu harus bekerja dengan cara lain.
4) 'jika' yang ada persis seperti yang seharusnya ada untuk -rendering-. "Tampilkan X jika Y ada". Ini bukan tentang logika bisnis; yang harus terjadi dalam model Anda (saya sarankan Backbone, maka Anda dapat memiliki apa pun yang Anda inginkan, untuk menjadi metode isXXX() pada model Anda).

Karena kita saling menanyakan sesuatu, tolong jangan lanjutkan ini jika Anda tidak memiliki argumen teknis yang cukup bagus untuk membuat perubahan besar. Menjadi frustrasi itu konyol - Tambahkan 'JIKA' yang Anda inginkan dan selesai.

—
Balas email ini secara langsung atau lihat di GitHub.

@thany
Ada perbedaan antara menyangkal argumen dan menolaknya. "SALAH" sama dengan "NUH UH!".
Cobalah untuk tidak terlalu pribadi tentang hal itu.

@tniswong
1) Tidak, hal yang sama berlaku dalam kerangka kerja apa pun.
2) Jika Anda menerapkan ini secara umum, Node harus menyertakan semua komponennya. Bahwa mereka mendasar atau perlu dapat diperdebatkan tetapi akan mengarah pada gagasan bahwa mengelompokkan mereka semua bersama-sama di luar kerangka standar adalah abstraksi dan pemisahan yang baik. Banyak proyek tidak membutuhkan salah satu dari mereka, dan yang lain membutuhkan versi khusus. Jadi, Anda dapat memasang satu set standar, menulis sendiri, atau tidak menggunakannya. Tidak ada (lagi) alasan teknis yang masuk akal untuk semua helper ini untuk digulirkan secara default.
3) Pernyataan Anda sama sekali tidak meniadakan poin aslinya, pada kenyataannya - Anda membantunya. 20 permintaan tarik untuk memperbaiki Jika. Saya berani bertaruh tim pengembang akan senang melewatinya.
4) Tepat, itu adalah 'ada'. Render ini jika ada.
Ketika Anda tidak dapat menulis tentang 'siapa pun yang pernah', dibutuhkan satu contoh penghitung. _mengangkat tangan_.

Dari catatan di atas, menurut saya, salah satu dari berikut ini diperlukan:

1. Ganti nama if menjadi exists dan berhenti memanggil setang "kurang logika" (karena bukan)
2. Tambahkan dukungan untuk if untuk berperilaku sebagai pernyataan if .
3. Hapus if seluruhnya.

Saya akan senang dengan salah satu dari opsi itu.

Jangan lupa {{#kecuali}}

Pada 22 November 2013, pukul 16.40, Aaron M [email protected] menulis:

Dari catatan di atas, menurut saya, salah satu dari berikut ini diperlukan:

Ganti nama jika ada dan berhenti memanggil setang "kurang logika" (karena tidak)
Tambahkan dukungan untuk if untuk berperilaku sebagai pernyataan if.
Hapus jika seluruhnya.
Saya akan senang dengan salah satu dari opsi itu.

—
Balas email ini secara langsung atau lihat di GitHub.

Saya pikir apa yang sebenarnya diringkas dengan baik oleh Aaron.

1. Ada kemunafikan yang perlu diatasi dengan mengklaim tidak logis DAN menyediakan jika/kecuali.
2. Kata "jika" yang diberikan adalah keliru.

Perbaiki keduanya, dan argumen ini hilang.

Pada 22 November 2013, pukul 16.43, Todd Niswonger [email protected] menulis:

Jangan lupa {{#kecuali}}

Pada 22 November 2013, pukul 16.40, Aaron M [email protected] menulis:

Dari catatan di atas, menurut saya, salah satu dari berikut ini diperlukan:

Ganti nama jika ada dan berhenti memanggil setang "kurang logika" (karena tidak)
Tambahkan dukungan untuk if untuk berperilaku sebagai pernyataan if.
Hapus jika seluruhnya.
Saya akan senang dengan salah satu dari opsi itu.

—
Balas email ini secara langsung atau lihat di GitHub.

@georgefrick
Saya menolak argumennya hanya karena telah dibantah jutaan kali sebelumnya. Kita sudah membahas ini terlalu lama, dan ini harus berakhir. Pernyataan if harus ditambahkan, tidak ada yang dirugikan, dan semua orang akan senang. Tidak menginginkannya sama dengan tidak menginginkan AC di SEMUA rumah. Saya akan menjadi hakim atas apa yang saya inginkan di rumah saya. Jika itu milik Anda dan Anda tidak menginginkannya, biarkan saja. Sederhana seperti itu.

@webgovernor
Tidak ada penggantian nama yang perlu dilakukan. Pernyataan if yang tepat dapat dibuat sepenuhnya kompatibel dengan pernyataan saat ini. Saat ini hanya "jika boolean maka ...", dan pernyataan if berfitur lengkap akan melakukan hal itu, hanya hal boolean itu sekarang dapat berupa ekspresi apa pun daripada hanya satu variabel.

@tniswong
Betapa bagusnya mereka, bukan? Untuk menambahkan tag ekstra yang kotor karena blok if saat mereka menerapkannya terlalu disederhanakan sehingga bahkan tidak dapat meniadakan ekspresi. Tetapi di Handlebars di masa depan, tag kecuali mungkin hanya menjadi alias untuk "jika tidak". Agak seperti do..while versus while..do dalam pemrograman, di mana keduanya ada terutama untuk keterbacaan dan bukan _benar-benar_ untuk alasan teknis apa pun.

Saya juga menginginkan perbandingan dasar di Handlebars. Saya memahami filosofi tanpa logika. Saya juga percaya dukungan perbandingan dasar akan lebih intuitif dan memungkinkan pengguna untuk bekerja lebih efisien. Jika pengguna secara massal memindahkan logika perbandingan dasar ke helper, filosofi ini tidak membantu mereka atau menghalangi perilaku suboptimal yang dirasakan—itu hanya menciptakan lebih banyak pekerjaan.

@jeremiahlee Tidak yakin apakah Anda setuju atau tidak setuju dengan saya di sana, saya dapat membaca komentar Anda dengan cara apa pun :)

Either way, saya telah bekerja dengan Handlebars di masa lalu, dan saya telah meminta mereka untuk menerapkan blok if yang tepat. Hal ini mengakibatkan banjir komentar tentang filosofi palsu bahwa logika harus tetap ada dalam model. Tidak ada pengembang Handlebars yang ingin berpikir sebanyak satu milimeter di luar dunia kecil mereka sendiri (ada kata kasar untuk itu, tapi saya akan melewatkannya). Lihat saja utas ini sebagai bukti.

Ini memaksa saya untuk menulis pembantu yang disebut "kapan" yang melakukan perbandingan. Masih tidak ada konstruksi if-block yang tepat, tetapi cukup dekat untuk saya saat itu. Itu memang menciptakan banyak pekerjaan yang tidak perlu bagi saya.

@thany : Saya setuju bahwa Handlebars harus memiliki perbandingan dasar dari dua nilai bawaan. Template tanpa logika juga tidak boleh kurang empati.

Saya juga akan memilih @thany 's dan argumen lainnya. Pernyataan if else terlalu mendasar.
Kelas bersyarat dan kotak select dengan option s yang telah dipilih sebelumnya harus dapat dilakukan dengan paket setang default.

Dengan pembantu bersarang ini tidak lagi menjadi masalah, misalnya

{{#if (greater-than array.length 3)}}
  ...
{{/if}}

contoh yang bagus @mmun :+1:

Agak aneh, dan saya tidak melihat kombinator boolean... Tapi yang terpenting, itu tidak mengubah sudut pandang keseluruhan pengelola proyek ini, yang tampaknya menjadi "NO LOGIC!!11!! 1!1" jenis tampilan.