Kemarin saya melihat presentasi di Java Server Faces 2.0 yang terlihat sangat mengesankan, meskipun saat ini saya adalah pengembang ASP.NET MVC / jQuery yang bahagia. Yang paling saya sukai tentang JSF adalah sejumlah besar komponen UI AJAX-Enabled yang tampaknya membuat pengembangan lebih cepat daripada dengan ASP.NET MVC, terutama di situs-situs berat AJAX. Pengujian integrasi terlihat sangat bagus juga.
Karena presentasi hanya menekankan keunggulan JSF, saya ingin mendengar tentang pihak lain juga.
Jadi pertanyaan saya adalah:
- Apa kerugian utama dari Java Server Faces 2.0?
- Apa yang membuat pengembang JSF mempertimbangkan untuk menggunakan ASP.NET MVC daripada JSF?
asp.net-mvc
jsf
jsf-2
Adrian Grigore
sumber
sumber
Jawaban:
Kerugian JSF 2.0? Jujur, terlepas dari kurva pembelajaran yang relatif curam ketika Anda tidak memiliki latar belakang pengetahuan yang kuat tentang Pengembangan Web dasar (HTML / CSS / JS, sisi server versus sisi klien, dll) dan Java Servlet API dasar (permintaan / respons / sesi , penerusan / pengalihan, dll), tidak ada kerugian serius yang terlintas dalam pikiran. JSF dalam rilisnya saat ini masih perlu menyingkirkan citra negatif yang diperolehnya sejak usia dini, di mana ada beberapa kelemahan serius.
JSF 1.0 (Maret 2004)
Ini adalah rilis awal. Itu berantakan dengan bug di kedua inti dan bidang kinerja yang Anda tidak ingin tahu. Aplikasi web Anda tidak selalu berfungsi seperti yang Anda harapkan secara intuitif. Anda sebagai pengembang akan lari menangis.
JSF 1.1 (Mei 2004)
Ini adalah rilis bugfix. Performa itu masih belum banyak membaik. Ada juga satu kelemahan utama: Anda tidak bisa inline HTML di halaman JSF dengan sempurna. Semua plain vanilla HTML get diberikan sebelum pohon komponen JSF. Anda perlu membungkus semua vanilla polos dalam
<f:verbatim>
tag sehingga mereka bisa dimasukkan dalam pohon komponen JSF. Meskipun ini sesuai spesifikasi, ini telah menerima banyak kritik. Lihat juga ao JSF / Facelets: mengapa bukan ide yang baik untuk mencampur JSF / Facelets dengan tag HTML?JSF 1.2 (Mei 2006)
Ini adalah rilis pertama dari tim pengembangan JSF baru yang dipimpin oleh Ryan Lubke. Tim baru melakukan banyak pekerjaan hebat. Ada juga perubahan dalam spesifikasi. Perubahan besar adalah peningkatan penanganan tampilan. Ini tidak hanya sepenuhnya JSF terpisah dari JSP, sehingga orang dapat menggunakan teknologi tampilan yang berbeda dari JSP, tetapi juga memungkinkan pengembang untuk inline plain vanilla HTML di halaman JSF tanpa harus repot dengan
<f:verbatim>
tag. Fokus utama lain dari tim baru adalah meningkatkan kinerja. Selama masa pakai Implementasi Referensi JSF Sun 1.2 (yang diberi nama kode Mojarra sejak build 1.2_08, sekitar 2008), secara praktis setiap build dikirimkan dengan peningkatan kinerja (utama) di samping perbaikan bug biasa (minor).Satu-satunya kelemahan serius dari JSF 1.x (termasuk 1.2) adalah tidak adanya ruang lingkup di antara ruang lingkup permintaan dan sesi , yang disebut ruang lingkup percakapan . Hal ini memaksa pengembang untuk repot dengan elemen input tersembunyi, permintaan DB yang tidak perlu dan / atau menyalahgunakan ruang lingkup sesi setiap kali seseorang ingin menyimpan data model awal dalam permintaan berikutnya untuk berhasil memproses validasi, konversi, perubahan model, dan undangan tindakan di lebih banyak aplikasi web yang kompleks. Rasa sakit dapat dilunakkan dengan mengadopsi perpustakaan pihak ke-3 yang menyimpan data yang diperlukan dalam permintaan berikutnya seperti komponen MyFaces Tomahawk
<t:saveState>
, cakupan percakapan JBoss Seam dan MyFaces Orchestra kerangka percakapan.Kerugian lain untuk puritan HTML / CSS adalah bahwa JSF menggunakan titik dua
:
sebagai karakter pemisah ID untuk memastikan keunikan elemen HTMLid
dalam output HTML yang dihasilkan, terutama ketika suatu komponen digunakan kembali lebih dari satu kali dalam tampilan (templating, iterating komponen, dll) . Karena ini adalah karakter ilegal dalam pengidentifikasi CSS, Anda harus menggunakannya\
untuk keluar dari titik dua dalam penyeleksi CSS, menghasilkan penyeleksi yang jelek dan aneh seperti#formId\:fieldId {}
atau bahkan#formId\3A fieldId {}
. Lihat juga Bagaimana cara menggunakan ID elemen HTML yang dihasilkan JSF dengan titik dua ":" di pemilih CSS? Namun, jika Anda bukan purist, baca juga secara default, JSF menghasilkan id yang tidak dapat digunakan, yang tidak kompatibel dengan css bagian dari standar web .Juga, JSF 1.x tidak mengirim dengan fasilitas Ajax di luar kotak. Bukan kelemahan teknis, tetapi karena hype Web 2.0 selama periode itu, itu menjadi kelemahan fungsional. Exadel lebih awal memperkenalkan Ajax4jsf, yang dikembangkan secara menyeluruh selama bertahun-tahun dan menjadi bagian inti dari pustaka komponen JBoss RichFaces . Pustaka komponen lain juga dikirimkan dengan kekuatan Ajax, yang terkenal adalah ICEfaces .
Sekitar setengah dari masa pakai JSF 1.2, sebuah teknologi tampilan berbasis XML baru diperkenalkan: Facelets . Ini menawarkan keuntungan besar di atas JSP, terutama di bidang templating.
JSF 2.0 (Juni 2009)
Ini adalah rilis besar kedua, dengan Ajax sebagai kata kunci. Ada banyak perubahan teknis dan fungsional. JSP digantikan oleh Facelet karena teknologi tampilan default dan Facelet diperluas dengan kemampuan untuk membuat komponen khusus menggunakan XML murni ( komponen komposit yang disebut ). Lihat juga Mengapa Facelets lebih disukai daripada JSP sebagai bahasa definisi tampilan dari JSF2.0 dan seterusnya?
Kekuatan Ajax diperkenalkan dalam rasa
<f:ajax>
komponen yang memiliki banyak kesamaan dengan Ajax4jsf. Anotasi dan peningkatan konvensi-konfigurasi diperkenalkan untuk membunuhfaces-config.xml
file verbose sebanyak mungkin. Selain itu, karakter pemisah ID penampung kontainer default:
menjadi dapat dikonfigurasi, sehingga pembuat HTML / CSS dapat bernafas lega. Yang perlu Anda lakukan adalah untuk mendefinisikannya sebagaiinit-param
diweb.xml
dengan namajavax.faces.SEPARATOR_CHAR
dan memastikan bahwa Anda tidak menggunakan karakter diri Anda di mana saja di klien ID, seperti-
.Terakhir tetapi tidak kalah pentingnya, ruang lingkup baru diperkenalkan, ruang lingkup tampilan . Ini menghilangkan kelemahan utama JSF 1.x lainnya seperti yang dijelaskan sebelumnya. Anda cukup mendeklarasikan kacang
@ViewScoped
untuk mengaktifkan cakupan percakapan tanpa mengganggu semua cara untuk mempertahankan data dalam permintaan (percakapan) selanjutnya. Sebuah@ViewScoped
kacang akan hidup selama Anda kemudian mengirimkan dan navigasi ke pandangan yang sama (independen dari membuka tab browser / jendela!), Baik serentak atau asynchronous (Ajax). Lihat juga Perbedaan antara ruang lingkup Tampilan dan Permintaan dalam kacang yang dikelola dan Bagaimana memilih ruang lingkup kacang yang tepat?Meskipun praktis semua kelemahan JSF 1.x dihilangkan, ada bug spesifik JSF 2.0 yang mungkin menjadi penghenti. The
@ViewScoped
gagal dalam penangan tag karena masalah ayam-telur dalam tabungan negara parsial. Ini diperbaiki di JSF 2.2 dan di-backport di Mojarra 2.1.18. Juga melewati atribut khusus seperti HTML5data-xxx
tidak didukung. Ini diperbaiki di JSF 2.2 oleh fitur elemen / atribut passthrough baru. Lebih lanjut implementasi JSF, Mojarra memiliki masalah tersendiri . Relatif banyak dari mereka terkait dengan perilaku kadang<ui:repeat>
- kadang tidak intuitif , implementasi tabungan negara parsial dan lingkup flash yang diimplementasikan dengan buruk . Sebagian besar dari mereka diperbaiki dalam versi Mojarra 2.2.x.Sekitar waktu JSF 2.0, PrimeFaces diperkenalkan, berdasarkan jQuery dan jQuery UI. Itu menjadi perpustakaan komponen JSF paling populer.
JSF 2.2 (Mei 2013)
Dengan diperkenalkannya JSF 2.2, HTML5 digunakan sebagai kata kunci walaupun secara teknis ini hanya didukung di semua versi JSF yang lebih lama. Lihat juga dukungan JavaServer Faces 2.2 dan HTML5, mengapa XHTML masih digunakan . Fitur JSF 2.2 baru yang paling penting adalah dukungan untuk atribut komponen kustom, dengan ini membuka dunia kemungkinan, seperti grup tombol radio yang dapat disesuaikan .
Terlepas dari implementasi bug spesifik dan beberapa "hal-hal kecil yang mengganggu" seperti ketidakmampuan untuk menyuntikkan EJB di validator / converter (sudah diperbaiki di JSF 2.3), tidak ada kelemahan utama dalam spesifikasi JSF 2.2.
MVC berbasis komponen vs MVC berbasis permintaan
Beberapa mungkin memilih bahwa kelemahan utama JSF adalah memungkinkan sangat sedikit kendali atas HTML / CSS / JS yang dihasilkan. Itu bukan milik JSF, itu hanya karena itu adalah kerangka kerja MVC berbasis komponen , bukan kerangka kerja MVC berdasarkan permintaan (tindakan) . Jika tingkat tinggi mengendalikan HTML / CSS / JS adalah persyaratan utama Anda ketika mempertimbangkan kerangka kerja MVC, maka Anda seharusnya sudah tidak melihat kerangka kerja MVC berbasis komponen, tetapi pada kerangka kerja MVC berbasis permintaan seperti Spring MVC . Anda hanya perlu mempertimbangkan bahwa Anda harus menulis sendiri semua HTML / CSS / JS boilerplate. Lihat juga Perbedaan antara Permintaan MVC dan Komponen MVC .
Lihat juga:
sumber
click and go to component or include
, tidak ada grafik ketergantungan komponen / tag dan tidak ada menu untuk tag pihak ketiga atau sendiri. Saya menghabiskan banyak waktu melakukan pencarian di seluruh proyek hanya untuk memahami di mana komponen atau fungsi x digunakan.Setelah 5 tahun bekerja dengan JSF, saya pikir saya dapat menambahkan 2 sen.
Dua kelemahan utama JSF :
IMHO menyembunyikan Permintaan / Tanggapan HTTP dari pengembang adalah kesalahan besar. Dari pengalaman saya, setiap kerangka kerja berbasis komponen menambah abstraksi ke pengembangan Web, dan abstraksi itu menghasilkan overhead yang tidak perlu dan kompleksitas yang lebih tinggi.
Dan kekurangan kecil yang muncul di benak saya:
<ui:remove>
membutuhkan konten yang benar secara sintaksis yang diuraikan.isRendered()
bagian dalamprocessXxx()
sebelum melanjutkan.Jangan salah sangka. Sebagai kerangka kerja komponen JSF dalam versi 2 benar-benar bagus, tetapi masih berbasis komponen, dan akan selalu ...
Silakan lihat rendahnya popularitas Tapestry, Wicket dan rendahnya antusiasme para pengembang JSF yang berpengalaman (yang bahkan lebih bermakna). Dan untuk kontrasnya, lihatlah kesuksesan Rails, Grails, Django, Play! Kerangka kerja - mereka semua berbasis tindakan dan tidak mencoba untuk menyembunyikan permintaan / tanggapan sejati programmer dan sifat stateless dari web.
Bagi saya itu adalah kelemahan utama JSF. IMHO JSF dapat cocok dengan beberapa jenis aplikasi (intranet, bentuk-intensif), tetapi untuk aplikasi web kehidupan nyata itu bukan cara yang baik untuk pergi.
Semoga ini membantu seseorang dengan pilihannya yang berkaitan dengan front-end.
sumber
real-life web application
? JSF juga menyembunyikan sifat permintaan / tanggapan, itu mungkin benar, tetapi programmer bertanggung jawab untuk mengetahui apa yang sebenarnya terjadi di balik selimut. Jika Anda tidak tahu cara kerja HTTP, pelajari sebelum JSF atau kerangka kerja lainnya.Beberapa kekurangan yang muncul di pikiran:
Singkatnya: Waktu Anda akan menghemat dengan JSF, dari menghindari untuk menulis kode JSP / servlet / beanplate, Anda akan menghabiskannya x10 untuk membuatnya skala dan melakukan apa yang Anda inginkan.
sumber
Bagi saya, kelemahan terbesar dari JSF 2.0 adalah kurva belajar tidak hanya dari JSF, tetapi komponen perpustakaan yang harus Anda gunakan untuk membuatnya melakukan pekerjaan yang bermanfaat. Pertimbangkan banyaknya spesifikasi dan standar yang telah Anda tangani untuk benar-benar mahir:
Sekarang, setelah Anda selesai dengan itu Anda bisa melanjutkan dengan spesifikasi kepemilikan, yaitu pustaka komponen dan pustaka penyedia Anda akan mengambil sepanjang jalan:
Dan jangan lupa wadahnya! Dan semua file konfigurasi itu:
Jadi - INI MUDAH MEMBUATNYA? Tentu, JSF 2.0 adalah "mudah" selama yang Anda inginkan adalah halaman web paling dasar dengan interaksi paling sederhana.
Sederhananya, JSF 2.0 adalah mishmash yang paling rumit dan rumit dari teknologi yang direkatkan seperti yang ada di dunia perangkat lunak saat ini. Dan saya tidak bisa memikirkan apa pun yang saya ingin gunakan.
sumber
Jadi singkatnya kekurangan saya adalah: Kompleksitas, Kemajuan pembangunan tidak terlalu lancar, buggy, tidak fleksibel.
Tentu ada keuntungan juga, tapi bukan itu yang Anda tanyakan. Pokoknya itu pengalaman saya dengan kerangka kerja orang lain mungkin memiliki pendapat yang berbeda, jadi cara terbaik adalah hanya mencobanya sebentar untuk melihat apakah itu untuk Anda (hanya sesuatu yang lebih kompleks - bukan contoh naif - JSF benar-benar bersinar di sana :) IMHO kasus penggunaan terbaik untuk JSF adalah aplikasi bisnis, seperti CRMs dll ...
sumber
"JSF akan menampilkan View-layer HTML dan JavaScript yang tidak dapat Anda kontrol atau ubah tanpa masuk ke kode Controller."
Sebenarnya JSF memberi Anda fleksibilitas, Anda dapat menggunakan komponen standar / pihak ketiga atau membuat sendiri yang Anda miliki kontrol penuh atas apa yang diberikan. Ini hanya satu xhtml yang Anda butuhkan untuk membuat komponen khusus Anda dengan JSF 2.0.
sumber
Saya bukan ahli Java Server Faces sama sekali. Tapi IMHO kelemahan utama adalah sisi server. Saya bosan mempelajari dan menggunakan kerangka lapisan presentasi web sisi server seperti Formulir Web ASP.NET, ASP.NET MVC, Java Server Faces, Struts, kerangka kerja php, dan kerangka kerja ruby on rails. Saya mengucapkan selamat tinggal pada mereka semua, dan saya menyapa Angular dan TypeScript. Lapisan presentasi saya berjalan di browser. Saya tidak masalah jika dilayani oleh Windows IIS yang menjalankan php atau ASP.NET, atau jika dilayani oleh server web Apache yang berjalan di Linux. Saya hanya perlu belajar satu kerangka kerja yang berfungsi di mana-mana.
Hanya dua sen saya.
sumber
Kami mengembangkan proyek sampel dengan JSF (Itu adalah penelitian tiga minggu sehingga kami mungkin kehilangan beberapa hal!)
Kami mencoba menggunakan jsf inti, jika komponen diperlukan kami menggunakan PrimeFaces.
Proyek itu adalah situs web dengan navigasi. Setiap halaman harus dimuat melalui ajax ketika menu diklik.
Situs ini memiliki dua usecases:
Kami menemukan bahwa:
ajaxComplete
dan kami menemukan bahwa PF 4 telah mengimplementasikan acara ajax sendiri. Kami memiliki beberapa komponen jQuery dan kami perlu mengubah kode mereka.Jika Anda mengubah sampel di atas menjadi proyek non Ajax (atau setidaknya lebih sedikit proyek ajax), Anda tidak akan menghadapi banyak masalah di atas.
Kami meringkas penelitian kami sebagai:
Tentu saja kami menemukan banyak fitur bagus di JSF yang mungkin sangat membantu dalam beberapa proyek, jadi pertimbangkan kebutuhan proyek Anda.
Silakan merujuk ke dokumen teknis JSF untuk meninjau keunggulan JSF, dan menurut saya keuntungan terbesar JSF, adalah dukungan SELESAI DAN BESAR dari @BalusC ;-)
sumber
Bagi saya kekurangan terbesar JSF adalah dukungan yang buruk untuk halaman yang dihasilkan secara program (dinamis).
Jika Anda ingin membuat halaman Anda (membuat model komponen halaman) secara dinamis dari kode java. Misalnya jika Anda bekerja pada konstruktor halaman web WYSIWYG. Dokumentasi yang memadai dari use case ini tidak tersedia secara umum. Ada banyak titik di mana Anda harus bereksperimen dan pengembangannya berjalan lambat. Banyak hal yang tidak sesuai dengan harapan Anda. Tapi secara umum itu mungkin meretasnya entah bagaimana.
Untung itu bukan masalah dalam filosofi atau arsitektur JSF. Itu tidak cukup diuraikan (sejauh yang saya tahu).
JSF 2 membawa Komponen Komposit yang seharusnya memudahkan pengembangan komponen, tetapi dukungan mereka untuk konstruksi dinamis (terprogram) sangat buruk. Jika Anda mengatasi proses rumit rumit dan hampir tidak berdokumen dari konstruksi Komponen Komposit dinamis, Anda akan menemukan bahwa Jika Anda bersarang beberapa komponen Komposit sedikit lebih dalam, mereka berhenti bekerja, melempar beberapa pengecualian.
Tapi sepertinya komunitas JSF menyadari kekurangan ini. Mereka sedang mengerjakan ini seperti yang Anda lihat dari kedua bug ini
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599
Situasi harus lebih baik dengan JSF 2.2 setidaknya jika kita berbicara tentang spesifikasi.
sumber
Mengomentari beberapa bulan terakhir pengalaman Primefaces / JSF saya:
Janji JSF untuk menghindari penulisan javascript berubah menjadi penulisan javascript lebih banyak daripada yang kita miliki jika tidak menggunakan Primefaces - dan javascript untuk memperbaiki apa yang dipatahkan Primefaces.
Ini adalah time sink - kecuali jika Anda lagi menggunakan barang-barang "dari rak". Juga sangat jelek (Primefaces) ketika harus bekerja dengan Selenium. Itu semua bisa dilakukan - tapi sekali lagi - hanya ada begitu banyak waktu.
Hindari ini jika Anda bekerja dengan tim UX / desain dan perlu untuk beralih dengan cepat di UI - Anda dapat menghemat waktu dengan mempelajari jquery / menulis HTML langsung - atau melihat reaksi / sudut.
sumber
<input type="checkbox" name="versionsTab" value="version1">
HTLM : Kotak centang Primefaces:<div class="ui-chkbox ui-widget"> <div class="ui-helper-hidden-accessible"> <input type="checkbox" name="datasetForm:tabView:versionsTable_checkbox"> </div> <div class="ui-chkbox-box ui-widget ui-corner-all ui-state-default"> <span class="ui-chkbox-icon ui-c"></span> </div> </div>
Selenium tidak dapat menemukan kotak centang sebenarnya yang telah disembunyikan. misal saya bisa menemukannya dengan penyeleksi / coding / dll tetapi tim QA yang tidak teknis tidak bisaJSF memiliki banyak kelebihan, pertanyaan yang tidak menguntungkan biar saya tambahkan beberapa poin.
Pada skenario praktis penerapan proyek web dengan kerangka waktu Anda perlu mengawasi faktor-faktor berikut.
Apakah Anda memiliki bandwidth untuk mengakomodasi kurva pembelajaran awal?
Apakah Anda memiliki keahlian yang cukup dalam tim Anda yang dapat meninjau
hal-hal yang dihasilkan oleh JSF oleh pengembang?
Jika jawaban Anda adalah 'Tidak' untuk pertanyaan, Anda mungkin berakhir pada basis kode tidak dapat dipertahankan.
sumber
JSF hanya memiliki satu kelemahan: sebelum memulai pengembangan "JSF" Anda harus memahami dengan jelas pengembangan web, inti java dan arsitektur front-end.
Saat ini kerangka kerja JavaScript "baru" hanya mencoba menyalin / menempelkan model berbasis komponen "JSF".
sumber
Di antara semua kerangka kerja "arus utama" seperti Spring MVC, Wicket, Tapestry, dll., JSF Java EE dengan komponen kompositnya adalah lapisan presentasi dan teknologi berorientasi komponen yang paling rumit yang disediakan. Ini sedikit rumit dan tidak lengkap dibandingkan dengan solusi yang disediakan oleh HybridJava.
sumber