Apa kebutuhan JSF, ketika UI dapat dicapai dengan pustaka JavaScript seperti jQuery dan AngularJS

Saya membaca tentang JSF yang merupakan kerangka kerja UI dan menyediakan beberapa komponen UI. Tetapi bagaimana lebih baik atau berbeda dari jumlah komponen yang tersedia dari jQueryUI, AngularJS, ExtJS, atau bahkan HTML biasa, CSS dan JavaScript.

Mengapa seseorang harus mempelajari JSF?

JSF menjadi JSP / Servlet / HTML / CSS / JS biasa seperti jQuery ke JS biasa: lakukan lebih banyak dengan lebih sedikit kode. Untuk mengambil PrimeFaces ( berbasis jQuery + jQuery UI) sebagai contoh, telusuri etalase untuk melihat contoh kode lengkap. BootsFaces ( berbasis jQuery + Bootstrap UI) juga memiliki etalase dengan contoh kode lengkap. Jika Anda mempelajari contoh tersebut dengan cermat, Anda akan melihat bahwa pada dasarnya Anda memerlukan kelas Javabean sederhana sebagai model dan file XHTML sebagai tampilan.

Perhatikan bahwa Anda tidak boleh melihat JSF sebagai pengganti HTML / CSS / JS saja, Anda juga harus mempertimbangkan bagian sisi server (khususnya: JSP / Servlet). JSF menghilangkan kebutuhan semua boilerplate untuk mengumpulkan parameter permintaan HTTP, mengonversi / memvalidasinya, memperbarui nilai model, mengeksekusi metode Java yang tepat untuk melakukan hal-hal bisnis dan menghasilkan kode boilerplate HTML / CSS / JS. Dengan JSF Anda pada dasarnya berakhir dengan halaman XHTML sebagai definisi tampilan dan kelas Javabean sebagai definisi model. Ini sangat mempercepat perkembangan.

Seperti pada setiap kerangka kerja MVC web berbasis komponen, Anda memiliki kontrol yang lebih sedikit di JSF atas HTML / CSS / JS yang dirender. Menambahkan kode JS kustom tidak semudah itu karena Anda juga harus mempertimbangkan status tampilan JSF di sisi server (misalnya, mengaktifkan tombol yang dinonaktifkan di sisi JS tidak akan mengaktifkan tombol di sisi JSF, yang pada gilirannya menjadi a keuntungan keamanan yang sangat besar). Jika itu adalah showstopper utama, maka cari kerangka kerja MVC web berbasis aksi seperti Spring MVC . Anda hanya akan memperhitungkan bahwa Anda harus menulis semua kode HTML / CSS / JS (dan pencegahan terhadap XSS, CSRF, dan manipulasi DOM!) Sendiri . Juga jika Anda kembali dari Facelet ke JSP, Anda juga akan kehilangan kemampuan pembuatan template tingkat lanjut.

Di sisi lain, jika Anda memiliki situs web berbasis JSP / Servlet / HTML / CSS / JS / jQuery yang besar dan Anda ingin mengubah kode boilerplate JSP / Servlet / HTML / CSS / JS / jQuery yang berulang menjadi komponen yang dapat digunakan kembali, maka salah satu solusinya adalah JSF. Template kustom, tagfile, dan komponen dapat membantu dalam hal ini. Dalam perspektif itu, JSF berdiri di atas JSP / Servlet / HTML / CSS / JS / jQuery (dan itu juga mengapa sangat penting untuk memahami dasar-dasar tersebut sebelum masuk ke JSF).

Anda dapat menemukan proyek berbasis JSF kickoff dunia nyata di sini: Java EE Kickoff App . Anda akan melihat bahwa itu berisi di samping JSF sebagai HTML5 , CSS3 dan jQuery yang baik .

Lihat juga:

• Perbedaan antara Request MVC dan Component MVC
• Perbedaan antara JSP, Servlet dan JSF
• Apa kelemahan utama JSF 2.0?
• Apakah mungkin menggunakan JSF + Facelet dengan HTML 4/5?
• Kapan menggunakan <ui: include>, file tag, komponen komposit, dan / atau komponen kustom?

JSF dibuat untuk membuatnya sehingga toko-toko java tidak perlu mempelajari hal-hal seperti jQuery dan membangun JS kompleks, tetapi berfokus pada tumpukan Java murni. Di dunia di mana waktu adalah uang dan banyak tempat yang sudah berfokus pada pengembangan Java, berkurangnya satu bahasa / bagian dalam tumpukan membuat pelatihan dan pemeliharaan lebih cepat dan dengan demikian lebih murah.

Saya akan menambahkan bahwa JavaScript mudah menjadi mimpi buruk pemeliharaan pada tim besar, terutama jika beberapa pengembang dalam proyek ini tidak terlalu paham web.

Dengan Javascript dan kerangka kerja seperti jQuery, Anda memiliki fleksibilitas penuh dan kontrol penuh. Dengan ext dll Anda kehilangan banyak kendali dan harus beradaptasi dengan kerangka kerja. Dengan JSF Anda benar-benar kehilangan kendali dan harus sepenuhnya beradaptasi dengan kerangka kerja. Anda dipanggil dalam siklus hidup, dll. Dan akhirnya Anda tidak memiliki kendali kapan pun panggilan ke server dapat dilakukan dan di mana tidak. Jika Anda akan melakukan sesuatu yang dianggap 'istimewa', Anda berada dalam posisi yang sangat sulit. Dan di dunia JSF bahkan hal-hal mendasar seperti pengurutan tabel multikolom atau bidang di mana Anda dapat mengetik hanya sekumpulan karakter terbatas (seperti bidang angka) dianggap 'khusus'.

Namun, semakin banyak fleksibilitas yang Anda miliki, semakin banyak kesalahan atau praktik buruk yang dapat Anda lakukan. Fleksibilitas tinggi hanya berfungsi dengan pemrogram yang sangat cerdas, yang lain akan mengubah proyek menjadi mimpi buruk yang tak terkendali.

Namun, dengan JSF dan fleksibilitasnya yang terbatas, selalu hanya ada sedikit (atau bahkan hanya satu) cara yang benar untuk melakukan sesuatu. Anda sangat terbatas, Anda tidak dapat membuat pintasan, Anda harus menulis lebih banyak XML, dll. - tetapi ketika beradaptasi dengan standar, ada kontrol yang lebih baik pada kode yang akan dihasilkan oleh pemrogram yang tidak berpengalaman atau berketerampilan rendah. Akibatnya, perusahaan besar menyukai JSF karena 'lebih aman' bagi mereka.

Ketika saya pindah dari GWT ke JSF, saya terkejut, betapa banyak hal, yang menurut saya wajar, dianggap sangat tidak biasa dan betapa hal-hal sederhana begitu sulit dicapai. Terlebih lagi, bahkan membuat perubahan terkecil, seperti menambahkan tanda ':' setelah label, yang dalam aplikasi yang didukung GWT / jQuery akan mengubah satu label penghasil fungsi, memerlukan perubahan lusinan file dengan properti yang dilokalkan, yang bahkan tidak dipertimbangkan oleh ada yang aneh kecuali aku ...

Manfaat menggunakan JSF tidak hanya dalam menghasilkan xhtml + css + js. Terkadang JSF memberlakukan batasan pada markup yang dapat Anda buat, seperti kerangka kerja berbasis komponen apa pun. Tapi JSF tidak hanya untuk itu, gaya hidupnya sangat membantu. Setelah memvalidasi input, ia dapat memperbarui model dan menyinkronkan kacang sisi server Anda tanpa usaha apa pun. Anda hanya mengatakan "apa pun yang diketik pengguna di sini, periksa apakah itu angka, jika ya maka simpan di properti YY di objek XX" dan JSF akan melakukan semua itu.

Jadi ya, Anda masih bisa menggunakan JQuery, JS, dll. Tetapi JSF memberikan banyak manfaat saat menulis kode sisi server dan menyelamatkan Anda dari banyak pelat boiler.

Saya sangat tidak setuju bahwa jsf menambahkan apapun. Itu hanya menambah biaya overhead. Melakukan hal-hal ui di server adalah hal paling konyol yang pernah saya dengar. Dan javascript di tim besar berfungsi dengan baik - ini disebut kode penggunaan ulang.

Cukup bungkus jquery dalam beberapa tag jsp, itu saja yang Anda butuhkan dan Anda selesai, dan jangan menanggung masalah skalabilitas dan belenggu dengan.jsf dan richfaces.

Setelah bekerja dengan JSF, Spring MVC, Struts, Grails, JQuery, dan ExtJS, pendapat saya adalah bahwa Grails + ExtJS adalah salah satu kombinasi yang kuat.

Saya akan memilih Grails daripada JSF setiap hari. Saya suka kelengkapan ExtJS sebagai kerangka kerja dan pustaka sisi klien, tetapi ia hadir dengan kurva pembelajaran yang lebih curam daripada JQuery.

Berikut adalah perbedaan terbesar antara jQuery & JSF:

• tidak ada arsitektur MVC
• tidak ada kontrol negara (menyimpan tanggal dalam sesi atau percakapan, pembersihan otomatis, dll.)
• tidak ada pustaka validasi (default)
• tidak ada perpustakaan template
• tidak ada navigasi / perutean lanjutan
• sisi klien

jQuery tidak pernah dimaksudkan untuk digunakan sebagai webframework tumpukan penuh. Itu lebih ditujukan untuk mengganti kode JS tingkat rendah sehingga penulisan JS menjadi lebih mudah dan lebih kuat dalam beberapa baris kode.

Dan karenanya sebagian besar harus digunakan untuk menambahkan perilaku pada elemen HTML.

Setelah menggunakan kerangka kerja ExtJS untuk aplikasi web besar, saya tahu betapa mudahnya menggunakannya. ExtJS (Schena) paling cocok untuk interaksi database (Oracle 11g) dalam arsitektur MVC. Tampilan ditujukan untuk interaksi visual / pengguna. Kontroler menentukan 'pemrosesan' dan pemicu yang perlu digunakan dari paket PLSQL (API untuk CRUD, kueri pemilihan SQL, dll.). Model dan file penyimpanan digunakan untuk 'memetakan' item data ke Viewer / input.

ExtJS tidak cocok untuk antarmuka web non-database intensif - di mana Angular JS mungkin lebih cocok.