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


116

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?


3
keuntungan dari html yang dihasilkan server: kemampuan pencarian mesin pencari, sembunyikan tampilan berdasarkan otorisasi. jika tidak, kami telah meninggalkannya untuk ajax ui murni.
Neil McGuigan

5
Saya juga telah meninggalkan JSF untuk mendukung AngularJS + backend RESTful. (Apel dan jeruk, tapi Angular sangat bagus sehingga saya tidak membutuhkan banyak manfaat JSF)
arg20

JSF adalah kerangka kerja MVC berbasis komponen yang dibangun di atas Servlet API, dan menyediakan komponen melalui taglib yang dapat digunakan di JSP atau teknologi tampilan berbasis Java lainnya seperti Facelet.
Divyesh Kanzariya

Jawaban:


154

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:


15
Lakukan lebih banyak dengan lebih sedikit kode? Tetapi dengan lebih banyak xml ... sungguh tradeoff ... selain itu, ini merampas fleksibilitas Anda
Danubian Sailor

33
Di JSF 2.0+, xml tidak diperlukan.
Cagatay Civici

5
Kami memiliki Anotasi di JSF 2.0
VdeX

1
Tampaknya tidak ada penggambaran yang jelas antara lapisan bisnis / pengontrol dan tampilan, dengan JSF, karena sebagian besar tampilan dihasilkan di server. Saya memahami bahwa semuanya dikompilasi di server sebelum dikirim ke browser, tetapi saya lebih suka objek Java saya mengembalikan data yang ditampilkan oleh tampilan, daripada mengirim logika / data rendering.
Rick

1
setuju JSF adalah hal sisi server dengan kontrol yang kuat atas HTML.
Plain_Dude_Sleeping_Alone

28

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.


Jadi, apakah saya cukup nyaman dengan JQuery JS dll. Saya tidak perlu berkonsentrasi pada JSF?
sushil bharwani

2
Itu semua tergantung pada masalah yang Anda coba selesaikan dan dengan tim apa Anda menyelesaikannya.
Andrew White

1
Saya setuju dengan tim, tetapi saya tertarik untuk mempelajari masalah berbeda apa yang bisa diselesaikan JSF dan js jQuery dll tidak bisa. Hanya berusaha membangun motivasi untuk belajar JSF.
sushil bharwani

1
Tidak ada, ini hanya memberikan cara berbeda untuk menyelesaikan masalah yang sama.
Andrew White

8
Bahkan jika Anda benar-benar nyaman dengan JQuery, JSF masih sangat berguna. Ini menyediakan cara mudah untuk menghubungkan kode sisi server ke representasi sisi klien. Beberapa 'komponen komposit' Facelet hanyalah pembungkus yang agak tipis di sekitar HTML dan JS (termasuk JQuery). Mereka mudah dibuat dan secara umum membuat koneksi sisi klien-server menjadi lebih mudah.
Arjan Tijms

23

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


7
PrimeFaces didasarkan pada jQuery sehingga Anda memiliki banyak fleksibilitas di sisi klien, juga komponen PrimeFaces menyediakan banyak kaitan di sisi klien dan server sebagai callback acara untuk Anda sesuaikan. API Javascript dapat diganti dan CSS juga untuk tampilan yang disesuaikan. : label dapat dikonfigurasi secara global di web.xml untuk karakter yang lebih ramah jQuery.
Cagatay Civici

1
Sepakat. Aturan umumnya adalah: Tidak menggunakan kerangka kerja memerlukan pemrograman javascript tingkat lanjut dan akan sulit dipelihara tetapi memungkinkan daya dan kompleksitas yang jauh lebih besar, sementara ketergantungan pada kerangka kerja akan lebih mudah untuk dibangun dan dipelihara, tetapi akan membatasi potensi kapasitas aplikasi.
KTys

10

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.


9

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.


14
JSF diarahkan pada aplikasi berbasis formulir. jQuery bagus (sih, banyak pustaka komponen JSF populer seperti PrimeFaces, RichFaces dan IceFaces bahkan menggunakannya di bawah sampul), tetapi jQuery tidak menyederhanakan pemrosesan pengiriman formulir di sisi server dengan cara apa pun. Menggunakan JSP / Servlet biasa hanya akan menghasilkan kode boilerplate yang buruk. Sekali lagi, JSF tidak hanya HTML / CSS / JS, tetapi juga JSP / Servlet.
BalusC

2
Saya pikir jika Anda membaca lebih lanjut tentang JSF secara umum dan siklus hidup halaman JSF secara khusus, Anda mungkin berubah pikiran. Kemudian lagi, Anda mungkin tidak.
Ahmed Anwar

5

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.


3

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.


2

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.

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.