Mengapa saya menggunakan mesin templating? jsp include dan jstl vs tiles, freemarker, velocity, sitemesh

95

Saya akan memilih cara mengatur tampilan saya (dengan spring-mvc, tapi itu seharusnya tidak terlalu menjadi masalah)

Ada 6 opsi sejauh yang saya lihat (meskipun tidak saling eksklusif):

  • Ubin
  • Sitemesh
  • Freemarker
  • Kecepatan
  • <jsp:include>
  • <%@ include file="..">

Ubin dan Sitemesh dapat dikelompokkan; begitu pula Freemarker dan Velocity . Yang mana dalam setiap kelompok yang akan digunakan bukanlah masalah diskusi ini, ada cukup banyak pertanyaan dan diskusi tentang itu.

Ini adalah bacaan yang menarik , tetapi tidak bisa meyakinkan saya untuk menggunakan ubin.

Pertanyaan saya adalah - apa yang diberikan framework ini yang tidak dapat dilakukan dengan benar <@ include file=".."> dan JSTL. Poin utama (beberapa diambil dari artikel):

  1. Menyertakan bagian halaman, seperti header dan footer - tidak ada perbedaan antara:

    <%@ include file="header.jsp" %>

    dan

    <tiles:insert page="header.jsp" />

  2. Menentukan parameter di header - seperti judul, meta tag, dll. Ini sangat penting, terutama dari sudut pandang SEO. Dengan opsi template, Anda dapat dengan mudah menentukan placeholder yang harus ditentukan oleh setiap halaman. Tapi jadi Anda bisa di jsp dengan JSTL , menggunakan <c:set>(di halaman termasuk) dan <c:out>(di halaman yang disertakan)

  3. Reorganisasi tata letak - jika Anda ingin memindahkan runut tautan ke atas menu, atau kotak masuk di atas panel samping lain. Jika penyertaan halaman (dengan jsp) tidak diatur dengan baik, Anda mungkin perlu mengubah setiap halaman dalam kasus seperti itu. Tetapi jika tata letak Anda tidak terlalu rumit, dan Anda meletakkan hal-hal umum di header / footer, tidak ada yang perlu dikhawatirkan.

  4. Kopling antara komponen umum dan konten spesifik - Saya tidak menemukan masalah dengan ini. Jika Anda ingin menggunakan kembali beberapa fragmen, pindahkan ke halaman yang tidak menyertakan header / footer apa pun, dan sertakan di mana pun diperlukan.

  5. Efisiensi - <%@ include file="file.jsp" %>lebih efisien dari apa pun, karena dikompilasi sekali. Semua opsi lainnya diurai / dijalankan berkali-kali.

  6. Kompleksitas - semua solusi non-jsp memerlukan file xml tambahan, penyertaan tambahan, konfigurasi pra-prosesor, dll. Ini adalah kurva pembelajaran dan memperkenalkan lebih banyak titik potensi kegagalan. Selain itu, itu membuat dukungan dan perubahan lebih membosankan - Anda harus memeriksa sejumlah file / konfigurasi untuk memahami apa yang terjadi.

  7. Placeholder - apakah velocity / freemarker memberikan lebih dari JSTL? Di JSTL Anda meletakkan placeholder, dan menggunakan model (ditempatkan dalam permintaan atau cakupan sesi, oleh pengontrol) untuk mengisi placeholder ini.

Jadi, yakinkan saya bahwa saya harus menggunakan salah satu kerangka kerja di atas daripada / selain JSP biasa.

java  jsp  velocity  tiles  freemarker 
— Bozho
sumber
Saya tidak yakin persis bagaimana saya akan membandingkannya, karena saya telah menggunakan template tata letak Stripes untuk sementara waktu dan saya merasa itu jauh lebih bagus daripada JSP biasa. Saya menggunakan beberapa panggilan jsp: include tetapi itu umumnya kasus yang cukup khusus. Mekanisme templat tata letak adalah alat yang sangat nyaman dan kuat.
— Pointy
2
ya, saya pernah mendengar bahwa semua ini "nyaman dan kuat", tetapi saya belum melihatnya. Apa yang saya lihat adalah kerumitan yang tidak dibutuhkan dan tumpukan file konfigurasi. (Saya tidak berbicara tentang garis-garis secara khusus, tetapi secara umum)
— Bozho
1
— matt b
Saya percaya jsp: include cukup efisien - itu dikompilasi ke panggilan metode dari servlet termasuk ke yang disertakan. Ini menghasilkan kode yang kurang dihasilkan daripada @include, yang bahkan dapat meningkatkan kinerja karena efek cache.
— Tom Anderson
Pengembang StringTemplate membuat argumen terbaik yang pernah saya lihat, yang sangat mirip dengan aturan paling sedikit daya
— Paul Sweatte

Jawaban:

17

Beberapa argumen untuk Velocity (saya belum pernah menggunakan Freemarker):

  • Berpotensi menggunakan kembali template di luar konteks web, seperti dalam mengirim email
  • Sintaks bahasa template Velocity jauh lebih sederhana daripada JSP EL atau pustaka tag
  • Pemisahan ketat logika tampilan dari jenis logika lainnya - tidak ada opsi yang memungkinkan untuk drop-down untuk menggunakan tag scriptlet dan melakukan hal-hal buruk di template Anda.

Placeholder - apakah kecepatan / freemaker memberikan lebih dari JSTL? Di JSTL Anda meletakkan placeholder, dan menggunakan model (ditempatkan dalam permintaan atau cakupan sesi, oleh pengontrol) untuk mengisi placeholder ini.

Ya, referensi benar-benar inti dari VTL:

<b>Hello $username!</b>

atau

#if($listFromModel.size() > 1)
    You have many entries!
#end

Efisiensi - <%@ include file="file.jsp" %>lebih efisien dari apa pun, karena dikompilasi sekali. Semua opsi lain diurai / dijalankan berkali-kali.

Tidak begitu yakin saya setuju dengan atau memahami hal ini. Velocity memiliki opsi untuk menyimpan template, yang berarti pohon sintaksis abstrak tempat mereka diurai akan di-cache daripada dibaca dari disk setiap saat. Either way (dan saya tidak memiliki angka pasti untuk ini), Velocity selalu terasa cepat bagi saya.

Reorganisasi tata letak - jika Anda ingin memindahkan runut tautan ke atas menu, atau kotak masuk di atas panel samping lain. Jika penyertaan halaman (dengan jsp) tidak diatur dengan baik, Anda mungkin perlu mengubah setiap halaman dalam kasus seperti itu. Tetapi jika tata letak Anda tidak terlalu rumit, dan Anda meletakkan hal-hal umum di header / footer, tidak ada yang perlu dikhawatirkan.

Perbedaannya adalah, dengan pendekatan JSP, bukankah Anda akan mengatur ulang tata letak ini di setiap file JSP yang menggunakan header / footer yang sama? Tiles dan SiteMesh memungkinkan Anda untuk menentukan halaman tata letak dasar (JSP, Velocity template, dll - keduanya adalah kerangka kerja JSP pada intinya) di mana Anda dapat menentukan apa pun yang Anda inginkan dan kemudian mendelegasikannya ke fragmen / template "konten" untuk konten utama . Ini berarti hanya akan ada satu file untuk memindahkan header.

— matt b
sumber
3
contoh kecepatan yang Anda berikan dapat dengan mudah dilakukan dengan JSTL. dengan titik efisiensi yang saya maksud adalah bahwa jsps dikompilasi ke servlet, dan tidak ada yang diurai. Tapi template caching juga merupakan solusi yang bagus, ya. Adapun reorganisasi - tidak, saya biasanya membentuk termasuk dengan cara saya hanya perlu mengubah termasuk, bukan "termasuk". Mungkin dalam kasus yang lebih rumit hal ini tidak mungkin dilakukan.
— Bozho
2
Selain menggunakan kembali template di luar konteks web, Velocity memungkinkan Anda dengan mudah mengambil halaman web yang diberikan sebelum ditampilkan kepada klien. Ini berguna ketika Anda ingin membuat situs Anda dibuat sebagai file HTML. Dengan JSP - tidak ada solusi yang mudah. Ini adalah alasan utama kami beralih ke Velocity dari JSP. Tentang kecepatan - Saya melakukan beberapa pembandingan dan Velocity merender halaman persis 2 kali lebih cepat daripada JSP. Jadi kecepatan bukanlah masalah. Sekarang setelah menghabiskan beberapa tahun dengan Velocity saya tidak akan pernah kembali ke JSP lagi. Ini jauh lebih sederhana, lebih ringan dan lebih bersih.
— serg
@ serg555 apakah Anda memiliki benchmark tersebut yang dipasang di mana saja? Saya ingin melihat lebih banyak data tentang ini. Saya juga tertarik untuk melihat bagaimana Anda melakukan benchmark. Saya pikir ini akan menjadi info yang bagus untuk orang lain yang memikirkan pertanyaan yang sama "Velocity vs JSP vs mesin lain".
— matt b
Saya tidak memiliki hasil yang diposting. Baru saja saya mengonversi beberapa halaman dari situs kami dan mengukur waktu rendering sebelum dan sesudah. Tidak ada yang terlalu ilmiah :)
— serg
@ serg555 apa platform / servlet container / versi jsp?
— Bozho
12

Pilihan antara jsp:includedan Tiles / Sitemesh / etc adalah pilihan antara kesederhanaan dan kekuatan yang dihadapi developer sepanjang waktu. Tentu, jika Anda hanya memiliki sedikit file atau tidak berharap tata letak Anda sering berubah, maka gunakan saja jstldan jsp:include.

Namun aplikasi memiliki cara untuk tumbuh secara bertahap, dan mungkin sulit untuk membenarkan "hentikan pengembangan baru dan ubin retrofit (atau beberapa solusi lain) sehingga kami dapat memperbaiki masalah di masa mendatang dengan lebih mudah" , yang diperlukan jika Anda tidak menggunakan solusi kompleks di awal.

Jika Anda yakin aplikasi Anda akan selalu sederhana, atau Anda dapat menetapkan beberapa tolok ukur kompleksitas aplikasi, setelah itu Anda akan mengintegrasikan salah satu solusi yang lebih kompleks, maka saya sarankan untuk tidak menggunakan tiles / etc. Jika tidak, gunakan dari awal.

— ditambatkan
sumber
5

Saya tidak akan meyakinkan Anda untuk menggunakan teknologi lain. Untuk semua yang saya tahu setiap orang harus tetap berpegang pada JSP jika itu berhasil untuk mereka.

Saya bekerja terutama dengan Spring MVC dan saya menemukan JSP 2+ dalam kombinasi dengan SiteMesh sangat cocok.

SiteMesh 2/3

Menyediakan dekorator untuk diterapkan pada tampilan sebagian besar seperti warisan bekerja di mesin template lainnya. Fitur seperti itu tidak terpikirkan untuk bekerja tanpanya saat ini.

JSP 2+

Orang-orang yang mengklaim bahwa JSP akan menyulitkan untuk menghindari kode Java di template adalah palsu. Anda tidak boleh melakukannya dan dengan versi ini tidak perlu melakukannya. Versi 2 mendukung metode panggilan menggunakan EL yang merupakan keuntungan besar dibandingkan dengan versi sebelumnya.

Dengan tag JSTL, kode Anda akan tetap terlihat seperti HTML sehingga tidak terlalu canggung. Spring mengemas banyak dukungan untuk JSP melalui taglib yang sangat kuat.

Taglib juga mudah diperluas sehingga Anda sangat mudah menyesuaikan lingkungan Anda sendiri.

— Bart
sumber
Saya tidak melihat manfaat untuk SiteMesh. Tag Jsp menawarkan fungsionalitas dekorasi yang sama dengan SiteMesh tetapi dengan fleksibilitas yang lebih besar, penyiapan yang tidak terlalu rapuh, dan saya juga akan berspekulasi efisiensi yang lebih besar karena tidak ada penguraian pasca-proses yang terlibat.
— Magnus
2

Salah satu argumen terbaik untuk facelet (tidak ada dalam daftar Anda, tetapi saya hanya akan menyebutkannya) yang menentang penggunaan JSP adalah kompilasi tersebut terintegrasi dengan interpreter daripada didelegasikan ke compiler JSP. Ini berarti bahwa salah satu hal paling menjengkelkan yang saya miliki dengan JSF 1.1 - harus mengubah atribut id pada tag JSF di sekitarnya saat menyimpan perubahan agar mesin runtime menemukan perubahan - hilang, memberikan save- dalam editor, muat ulang siklus dalam browser kembali, bersama dengan pesan kesalahan yang jauh lebih baik.

— Thorbjørn Ravn Andersen
sumber
Ya, untuk facelets JSF adalah yang solusi hanya karena integrasi yang erat dengan penerjemah. Tapi di sini bukan ini masalahnya :)
— Bozho
Saya baru saja menyebutkannya jika ada yang memiliki fitur yang sama - itu akan menjadi fitur yang menentukan bagi saya.
— Thorbjørn Ravn Andersen
2

Teknologi tampilan yang baik menghilangkan sebagian besar dan sebagian besar pernyataan anoying if / switch / conditional, simple include tidak. Menggunakan hasil teknologi tampilan 'kompleks' dalam aplikasi 'sederhana'.

— Ibrahim
sumber
1

Anda tidak memberikan informasi tentang aplikasi tertentu Anda. Misalnya saya tidak menggunakan JSP hanya karena beberapa alasan:

Sulit untuk menghindari penggunaan kode Java dalam template JSP sehingga konsep break Anda dari View murni, dan akibatnya Anda akan mengalami kesulitan untuk mempertahankan kode di beberapa tempat sebagai view dan controller.

JSP secara otomatis membuat konteks JSP yang menetapkan sesi. Saya mungkin ingin menghindarinya, namun jika aplikasi Anda selalu menggunakan sesi, itu tidak menjadi masalah bagi Anda

JSP memerlukan kompilasi dan jika sistem target tidak memiliki kompiler Java, perubahan kecil apa pun akan perlu menggunakan sistem lain dan kemudian menerapkan ulang

Mesin JSP minimal sekitar 500k bytecode plus JSTL, jadi tidak cocok untuk sistem tertanam

Mesin template dapat menghasilkan tipe konten yang berbeda dari model yang sama, katakanlah muatan JSON, halaman web, badan email, CSV, dan sebagainya.

Pemrogram non Java mungkin mengalami kesulitan untuk bekerja dengan template JSP, ketika orang non teknis tidak pernah mengalami kesulitan untuk memodifikasi template biasa.

Saya menanyakan pertanyaan yang sama sejak lama dan diakhiri dengan menulis kerangka saya (pasti berbasis mesin template) yang bebas dari semua kekurangan yang saya lihat di solusi lain. Tak perlu dikatakan, ini adalah sekitar 100k kode byte.

— Singagirl
sumber
0

Saya menyadari bahwa ini muncul sebagai jawaban yang cerdas, tetapi kenyataannya adalah, jika Anda tidak melihat keuntungan menggunakan template atas kode dalam proyek Anda saat ini, mungkin karena dalam proyek Anda saat ini, tidak ada satu pun .

Sebagian tentang skala. Anda mungkin berpikir bahwa include sama kuatnya dengan sitemesh, dan itu memang benar, setidaknya untuk sejumlah kecil halaman (saya katakan mungkin sekitar 100), tetapi jika Anda memiliki beberapa ribu, itu mulai menjadi tidak dapat dikelola. (Jadi untuk eBay itu tidak perlu, untuk Salesforce mungkin)

Juga, seperti yang telah disebutkan sebelumnya, freemarker dan velocity tidak spesifik servlet. Anda dapat menggunakannya untuk apa saja (template email, dokumentasi offline, dll.). Anda tidak memerlukan wadah Servlet untuk menggunakan freemarker atau kecepatan.

Terakhir, poin 5 Anda hanya sebagian benar. Itu dikompilasi setiap kali diakses jika belum begitu. Ini berarti bahwa setiap kali Anda mengubah sesuatu, Anda harus ingat untuk menghapus direktori "work" kontainer servlet Anda, sehingga ia mengkompilasi ulang JSP. Ini tidak perlu dengan mesin templating.

TL; DR Mesin Templaing ditulis untuk mengatasi beberapa kekurangan (yang dirasakan atau nyata) dari JSP + JSTL. Apakah Anda harus menggunakannya atau tidak bergantung sepenuhnya pada kebutuhan Anda dan skala proyek Anda.

— Mikkel Løkke
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.