ความต้องการของ JSF คืออะไรเมื่อ UI สามารถทำได้ด้วยไลบรารี JavaScript เช่น jQuery และ AngularJS

ฉันอ่านเกี่ยวกับ JSF ซึ่งเป็นกรอบงาน UI และมีส่วนประกอบ UI บางอย่าง แต่จะดีกว่าหรือแตกต่างอย่างไรจากจำนวนส่วนประกอบที่มีให้เลือกตั้งแต่ jQueryUI, AngularJS, ExtJS หรือแม้แต่ HTML ธรรมดา, CSS และ JavaScript

ทำไมคนถึงควรเรียน JSF

JSF เป็น JSP / Servlet / HTML / CSS / JS ธรรมดาก็เหมือนกับ jQuery เป็น JS ธรรมดา: ทำได้มากขึ้นโดยใช้โค้ดน้อยลง หากต้องการใช้PrimeFaces (ใช้ jQuery + jQuery UI เป็นตัวอย่าง) ให้เรียกดูตู้โชว์เพื่อดูตัวอย่างโค้ดทั้งหมด BootsFaces (ตาม jQuery + Bootstrap UI) ยังมีตู้โชว์พร้อมตัวอย่างโค้ดที่สมบูรณ์ หากคุณศึกษาตัวอย่างเหล่านั้นอย่างละเอียดคุณจะเห็นว่าโดยพื้นฐานแล้วคุณต้องมีคลาส Javabean แบบธรรมดาเป็นโมเดลและมีไฟล์ XHTML เป็นมุมมอง

โปรดทราบว่าคุณไม่ควรมองว่า JSF แทนที่ HTML / CSS / JS เพียงอย่างเดียวคุณควรคำนึงถึงส่วนของฝั่งเซิร์ฟเวอร์ด้วย (โดยเฉพาะ: JSP / Servlet) JSF ขจัดความต้องการของสำเร็จรูปทั้งหมดในการรวบรวมพารามิเตอร์คำขอ HTTP การแปลง / ตรวจสอบความถูกต้องอัปเดตค่าโมเดลเรียกใช้เมธอด Java ที่เหมาะสมเพื่อทำธุรกิจและสร้างโค้ดสำเร็จรูป HTML / CSS / JS ด้วย JSF โดยทั่วไปคุณจะจบลงด้วยหน้า XHTML เป็นนิยามมุมมองและคลาส Javabean เป็นนิยามโมเดล สิ่งนี้ช่วยเร่งการพัฒนาอย่างมาก

เช่นเดียวกับเฟรมเวิร์ก MVC บนเว็บที่ใช้ส่วนประกอบทั้งหมดคุณมีการควบคุมแบบละเอียดน้อยกว่า JSF ในการแสดงผล HTML / CSS / JS การเพิ่มโค้ด JS ที่กำหนดเองนั้นไม่ใช่เรื่องง่ายเพราะคุณต้องคำนึงถึงสถานะมุมมอง JSF ในฝั่งเซิร์ฟเวอร์ด้วย (เช่นการเปิดใช้งานปุ่มปิดใช้งานในด้าน JS จะไม่เปิดใช้งานปุ่มในด้าน JSF ซึ่งจะเป็น ข้อได้เปรียบด้านความปลอดภัยอย่างมาก) ถ้าเป็นอย่างไรก็ตาม showstopper ใหญ่แล้วแทนที่จะมองหาการดำเนินการตามเว็บกรอบ MVC เหมือนฤดูใบไม้ผลิ MVC คุณจะคำนึงถึงว่าคุณต้องเขียนทุกสิ่งที่ HTML / CSS / รหัส JS (และป้องกัน XSS, CSRF และ DOM จัดการ!) ด้วยตัวคุณเอง นอกจากนี้หากคุณถอยจาก Facelets มาเป็น JSP คุณจะพลาดความสามารถในการทำเทมเพลตขั้นสูงเช่นกัน

ในทางกลับกันหากคุณมีเว็บไซต์ที่ใช้ JSP / Servlet / HTML / CSS / JS / jQuery ขนาดใหญ่และคุณต้องการ refactor โค้ด JSP / Servlet / HTML / CSS / JS / jQuery ที่ซ้ำ ๆ กันเป็นส่วนประกอบที่ใช้ซ้ำได้ หนึ่งในวิธีแก้ปัญหาคือ JSF เทมเพลตที่กำหนดเองไฟล์แท็กและส่วนประกอบสามารถช่วยได้ ในมุมมองนั้น JSF ยืนอยู่เหนือ JSP / Servlet / HTML / CSS / JS / jQuery (และนั่นเป็นเหตุผลว่าทำไมจึงเป็นเรื่องสำคัญที่จะต้องเข้าใจพื้นฐานเหล่านั้นก่อนที่จะดำน้ำใน JSF)

คุณสามารถค้นหาโครงการเขี่ยโลกแห่งความจริง JSF ตามที่นี่: Java EE Kickoff App คุณจะเห็นว่ามีอยู่ข้างๆJSFเป็นHTML5 , CSS3และjQuery ที่ดี

ดูสิ่งนี้ด้วย:

• ความแตกต่างระหว่าง Request MVC และ Component MVC
• ความแตกต่างระหว่าง JSP, Servlet และ JSF
• ข้อเสียเปรียบหลักของ JSF 2.0 คืออะไร?
• เป็นไปได้ไหมที่จะใช้ JSF + Facelets กับ HTML 4/5
• เมื่อใดควรใช้ <ui: include> ไฟล์แท็กคอมโพสิตคอมโพสิตและ / หรือคอมโพเนนต์แบบกำหนดเอง

JSF ถูกสร้างขึ้นเพื่อให้ร้านค้า java ไม่ต้องเรียนรู้สิ่งต่างๆเช่น jQuery และสร้าง JS ที่ซับซ้อน แต่มุ่งเน้นไปที่สแต็ก Java ทั้งหมดแทน ในโลกที่เวลาเป็นเงินเป็นทองและมีสถานที่มากมายที่มุ่งเน้นไปที่การพัฒนา Java ภาษา / ชิ้นส่วนน้อยลงหนึ่งภาษาในสแต็กทำให้การฝึกอบรมและการดูแลรักษาเร็วขึ้นและถูกลง

ฉันจะเพิ่มว่า JavaScript เป็นเรื่องง่ายที่จะกลายเป็นฝันร้ายในการบำรุงรักษาสำหรับทีมขนาดใหญ่โดยเฉพาะอย่างยิ่งหากนักพัฒนาบางคนในโครงการไม่เข้าใจเว็บมากนัก

ด้วย Javascript และเฟรมเวิร์กเช่น jQuery คุณจะมีความยืดหยุ่นและการควบคุมเต็มรูปแบบ ด้วย ext's ฯลฯ คุณจะสูญเสียการควบคุมมากและต้องปรับให้เข้ากับกรอบ ด้วย JSF คุณจะสูญเสียการควบคุมโดยสิ้นเชิงและต้องปรับให้เข้ากับกรอบงานทั้งหมด คุณถูกเรียกใช้ในวงจรชีวิต ฯลฯ และในที่สุดคุณก็ไม่สามารถควบคุมได้ว่าจะโทรไปยังเซิร์ฟเวอร์เมื่อใดและไม่สามารถทำได้ หากคุณต้องทำสิ่งที่ถือว่า 'พิเศษ' คุณอยู่ในสถานะที่ยากมาก และในโลก JSF แม้แต่สิ่งพื้นฐานเช่นการจัดเรียงตารางหลายคอลัมน์หรือฟิลด์ที่คุณสามารถพิมพ์ได้เฉพาะชุดอักขระที่ จำกัด (เช่นฟิลด์ตัวเลข) จะถือว่าเป็น 'พิเศษ'

อย่างไรก็ตามยิ่งคุณมีความยืดหยุ่นมากเท่าไหร่คุณก็สามารถทำข้อผิดพลาดหรือแนวทางปฏิบัติที่ไม่ดีได้มากขึ้นเท่านั้น ความยืดหยุ่นสูงใช้งานได้กับโปรแกรมเมอร์ที่ชาญฉลาดเท่านั้นคนอื่น ๆ จะเปลี่ยนโครงการให้กลายเป็นฝันร้ายที่ไม่สามารถจัดการได้

แต่ด้วย JSF และความยืดหยุ่นที่ จำกัด จึงมีวิธีที่ถูกต้องเพียงไม่กี่วิธี (หรือแม้แต่วิธีเดียว) ในการทำบางสิ่ง คุณมีข้อ จำกัด มากคุณไม่สามารถสร้างทางลัดได้คุณต้องเขียน XML เพิ่มเติมเป็นต้น - แต่เมื่อปรับให้เข้ากับมาตรฐานจะมีการควบคุมโค้ดที่ดีกว่าซึ่งโปรแกรมเมอร์ที่ไม่มีประสบการณ์หรือทักษะต่ำจะผลิตได้ ด้วยเหตุนี้ บริษัท ขนาดใหญ่จึงชอบ JSF เพราะปลอดภัยกว่าสำหรับพวกเขา

เมื่อฉันย้ายจาก GWT ไปเป็น JSF ฉันตกใจมากมีกี่สิ่งที่เป็นธรรมชาติสำหรับฉันถือว่าผิดปกติอย่างมากและสิ่งที่เรียบง่ายนั้นยากที่จะบรรลุ ยิ่งไปกว่านั้นแม้จะทำการเปลี่ยนแปลงที่เล็กที่สุดเช่นการเพิ่มเครื่องหมาย ':' หลังจากป้ายกำกับซึ่งในแอปที่ขับเคลื่อนด้วย GWT / jQuery จะเปลี่ยนการสร้างป้ายกำกับฟังก์ชันหนึ่งซึ่งจำเป็นต้องเปลี่ยนไฟล์หลายสิบไฟล์ด้วยคุณสมบัติที่แปลเป็นภาษาท้องถิ่นซึ่งไม่ได้รับการพิจารณาจาก ใครก็ได้ยกเว้นฉันแปลก ...

ประโยชน์ของการใช้ JSF ไม่เพียง แต่สร้าง xhtml + css + js เท่านั้น บางครั้ง JSF กำหนดข้อ จำกัด เกี่ยวกับมาร์กอัปที่คุณสามารถสร้างได้เช่นกรอบงานที่ใช้ส่วนประกอบใด ๆ แต่ JSF ไม่ได้เป็นเพียงแค่นั้นเท่านั้น หลังจากตรวจสอบอินพุตแล้วจะสามารถอัปเดตโมเดลและซิงค์ถั่วฝั่งเซิร์ฟเวอร์ของคุณได้โดยไม่ต้องใช้ความพยายามใด ๆ คุณเพียงแค่พูดว่า "สิ่งที่ผู้ใช้พิมพ์ที่นี่ตรวจสอบว่าเป็นตัวเลขหรือไม่ถ้าใช่ให้เก็บไว้ในคุณสมบัติ YY ในออบเจ็กต์ XX" ​​และ JSF จะดำเนินการทั้งหมด

ใช่คุณยังสามารถใช้ JQuery, JS และอื่น ๆ ได้ แต่ JSF ให้ประโยชน์มากมายในการเขียนโค้ดฝั่งเซิร์ฟเวอร์และช่วยคุณประหยัดจากหม้อไอน้ำจำนวนมาก

ฉันไม่เห็นด้วยอย่างยิ่งที่ jsf เพิ่มอะไรก็ได้ มันเพิ่มค่าใช้จ่ายเท่านั้น การทำ UI บนเซิร์ฟเวอร์เป็นสิ่งที่ไร้สาระที่สุดเท่าที่เคยได้ยินมา และจาวาสคริปต์สำหรับทีมขนาดใหญ่ก็ใช้งานได้ดีซึ่งเรียกว่าการใช้โค้ดซ้ำ

เพียงแค่ห่อ jquery ไว้ในแท็ก jsp นั่นคือทั้งหมดที่คุณต้องการและคุณทำเสร็จแล้วและอย่าอดทนกับปัญหาห่วงและความสามารถในการปรับขนาดด้วย jsf และ richfaces

จากการทำงานร่วมกับ JSF, Spring MVC, Struts, Grails, JQuery และ ExtJS ความเห็นของฉันคือ Grails + ExtJS เป็นส่วนผสมที่ทรงพลังอย่างหนึ่ง

ฉันจะเลือก Grails มากกว่า JSF ทุกวัน ฉันชอบความสมบูรณ์ของ ExtJS ในฐานะเฟรมเวิร์กและไลบรารีฝั่งไคลเอ็นต์ แต่มันมาพร้อมกับเส้นโค้งการเรียนรู้ที่สูงกว่า JQuery

ความแตกต่างที่ใหญ่ที่สุดระหว่าง jQuery และ JSF มีดังนี้

• ไม่มีสถาปัตยกรรม MVC
• ไม่มีการควบคุมสถานะ (จัดเก็บวันที่ในเซสชันหรือการสนทนาล้างข้อมูลอัตโนมัติ ฯลฯ )
• ไม่มีไลบรารีการตรวจสอบความถูกต้อง (ค่าเริ่มต้น)
• ไม่มีไลบรารีเทมเพลต
• ไม่มีการนำทาง / เส้นทางขั้นสูง
• ด้านลูกค้า

jQuery ไม่เคยมีวัตถุประสงค์เพื่อใช้เป็นเว็บเฟรมสแต็กแบบเต็ม มีจุดมุ่งหมายเพื่อแทนที่โค้ด JS ระดับต่ำเพื่อให้การเขียน JS ง่ายขึ้นและมีประสิทธิภาพมากขึ้นโดยใช้โค้ดน้อยลง

และส่วนใหญ่ควรใช้เพื่อเพิ่มพฤติกรรมในองค์ประกอบ HTML

เมื่อใช้เฟรมเวิร์ก ExtJS สำหรับเว็บแอปพลิเคชันขนาดใหญ่ฉันรู้ว่ามันใช้งานง่ายแค่ไหน ExtJS (Schena) เหมาะที่สุดสำหรับการโต้ตอบฐานข้อมูล (Oracle 11g) ในสถาปัตยกรรม MVC มุมมองมีไว้สำหรับการโต้ตอบด้วยภาพ / ผู้ใช้ คอนโทรลเลอร์ระบุ 'การประมวลผล' และทริกเกอร์ที่จำเป็นต้องใช้ในรูปแบบแพ็คเกจ PLSQL (API สำหรับ CRUD, SQL select queries เป็นต้น) โมเดลและไฟล์ที่จัดเก็บถูกใช้เพื่อ 'แมป' รายการข้อมูลกับ Viewer / inputs

ExtJS ไม่เหมาะสำหรับเว็บอินเตอร์เฟสที่ไม่ใช่ฐานข้อมูลแบบเข้มข้น - โดยที่ Angular JS อาจเหมาะสมกว่า