เหตุใดฉันจึงต้องใช้เครื่องมือสร้างเทมเพลต jsp include และ jstl vs tiles, freemarker, velocity, sitemesh

ฉันกำลังจะเลือกวิธีจัดระเบียบมุมมองของฉัน (ด้วย spring-mvc แต่ไม่น่าจะสำคัญเท่าไหร่)

มี 6 ตัวเลือกเท่าที่ฉันเห็น (แม้ว่าจะไม่สามารถใช้ร่วมกันได้):

• กระเบื้อง
• Sitemesh
• Freemarker
• ความเร็ว
• <jsp:include>
• <%@ include file="..">

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

นี่เป็นการอ่านที่น่าสนใจแต่ไม่สามารถโน้มน้าวให้ฉันใช้กระเบื้องได้

คำถามของฉันคือ - กรอบเหล่านี้ให้อะไรที่ไม่สามารถทำได้อย่างถูกต้อง <@ include file="..">และ JSTL ประเด็นหลัก (บางส่วนนำมาจากบทความ):

1. การรวมบางส่วนของหน้าเช่นส่วนหัวและส่วนท้าย - ไม่มีความแตกต่างระหว่าง:

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

   และ

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

2. การกำหนดพารามิเตอร์ในส่วนหัวเช่นชื่อเรื่องเมตาแท็ก ฯลฯ สิ่งนี้สำคัญมากโดยเฉพาะจากมุมมองของ SEO ด้วยตัวเลือกเทมเพลตคุณสามารถกำหนดตัวยึดตำแหน่งที่แต่ละเพจควรกำหนดได้ แต่คุณสามารถใน jsp ด้วยJSTLโดยใช้<c:set>(ในหน้ารวม) และ<c:out>(ในหน้าที่รวม)

3. การจัดโครงสร้างใหม่ - หากคุณต้องการย้ายเบรดครัมบ์เหนือเมนูหรือกล่องล็อกอินเหนือแผงด้านข้างอื่น หากการรวมหน้า (ด้วย jsp) ไม่ได้รับการจัดระเบียบอย่างดีคุณอาจต้องเปลี่ยนทุกๆหน้าในกรณีเช่นนี้ แต่ถ้าเค้าโครงของคุณไม่ซับซ้อนเกินไปและคุณใส่สิ่งที่พบบ่อยไว้ในส่วนหัว / ส่วนท้ายก็ไม่มีอะไรต้องกังวล

4. การเชื่อมต่อระหว่างส่วนประกอบทั่วไปกับเนื้อหาเฉพาะ - ฉันไม่พบปัญหากับสิ่งนี้ หากคุณต้องการใช้ซ้ำบางส่วนให้ย้ายไปยังหน้าที่ไม่มีส่วนหัว / ส่วนท้ายและรวมไว้ที่ใดก็ได้ที่จำเป็น

5. ประสิทธิภาพ - <%@ include file="file.jsp" %>มีประสิทธิภาพมากกว่าสิ่งอื่นใดเพราะรวบรวมครั้งเดียว ตัวเลือกอื่น ๆ ทั้งหมดจะถูกแยกวิเคราะห์ / ดำเนินการหลายครั้ง

6. ความซับซ้อน - โซลูชันที่ไม่ใช่ jsp ทั้งหมดต้องการไฟล์ xml เพิ่มเติมการรวมเพิ่มเติมการกำหนดค่าตัวประมวลผลล่วงหน้า ฯลฯ ซึ่งเป็นทั้งเส้นโค้งการเรียนรู้และแนะนำจุดที่อาจเกิดความล้มเหลวเพิ่มเติม นอกจากนี้ยังทำให้การสนับสนุนและการเปลี่ยนแปลงน่าเบื่อมากขึ้น - คุณต้องตรวจสอบไฟล์ / การกำหนดค่าต่างๆเพื่อให้เข้าใจว่าเกิดอะไรขึ้น

7. ตัวยึดตำแหน่ง - velocity / freemarker ให้อะไรมากกว่า JSTL หรือไม่? ใน JSTL คุณใส่ตัวยึดตำแหน่งและใช้โมเดล (วางไว้ในขอบเขตคำขอหรือเซสชันโดยคอนโทรลเลอร์) เพื่อเติมตัวยึดตำแหน่งเหล่านี้

ดังนั้นโน้มน้าวใจฉันว่าฉันควรใช้กรอบใด ๆ ข้างต้นแทน / นอกเหนือจาก JSP ธรรมดา

ข้อโต้แย้งบางประการสำหรับ Velocity (ฉันไม่ได้ใช้ Freemarker):

• เป็นไปได้ที่จะใช้เทมเพลตซ้ำนอกบริบทของเว็บเช่นในการส่งอีเมล
• ไวยากรณ์ภาษาแม่แบบ Velocity คือไกลง่ายกว่า JSP EL หรือไลบรารีแท็ก
• การแยกตรรกะมุมมองอย่างเข้มงวดจากตรรกะประเภทอื่น ๆ - ไม่มีตัวเลือกที่เป็นไปได้ในการเลื่อนลงไปใช้แท็กสคริปต์เล็ตและทำสิ่งที่น่ารังเกียจในเทมเพลตของคุณ

ตัวยึดตำแหน่ง - ความเร็ว / ตัวสร้างอิสระให้อะไรมากกว่า JSTL หรือไม่? ใน JSTL คุณใส่ตัวยึดตำแหน่งและใช้โมเดล (วางไว้ในขอบเขตคำขอหรือเซสชันโดยคอนโทรลเลอร์) เพื่อเติมตัวยึดตำแหน่งเหล่านี้

ใช่การอ้างอิงเป็นหัวใจหลักของ VTL:

<b>Hello $username!</b>

หรือ

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

ประสิทธิภาพ - <%@ include file="file.jsp" %>มีประสิทธิภาพมากกว่าสิ่งอื่นใดเพราะรวบรวมครั้งเดียว ตัวเลือกอื่น ๆ ทั้งหมดจะถูกแยกวิเคราะห์ / ดำเนินการหลายครั้ง

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

การจัดโครงสร้างใหม่ - หากคุณต้องการย้ายเบรดครัมบ์เหนือเมนูหรือกล่องล็อกอินเหนือแผงด้านข้างอื่น หากการรวมหน้า (ด้วย jsp) ไม่ได้รับการจัดระเบียบอย่างดีคุณอาจต้องเปลี่ยนทุกๆหน้าในกรณีเช่นนี้ แต่ถ้าเค้าโครงของคุณไม่ซับซ้อนเกินไปและคุณใส่สิ่งที่พบบ่อยไว้ในส่วนหัว / ส่วนท้ายก็ไม่มีอะไรต้องกังวล

ความแตกต่างคือด้วยวิธีการ JSP คุณจะไม่จัดเรียงเลย์เอาต์นี้ใหม่ในทุกไฟล์ JSP ที่ใช้ส่วนหัว / ส่วนท้ายเดียวกันหรือไม่? Tiles และ SiteMesh ช่วยให้คุณสามารถระบุเพจเค้าโครงพื้นฐาน (JSP เทมเพลต Velocity และอื่น ๆ - ทั้งสองเป็นเฟรมเวิร์ก JSP ในหัวใจของพวกเขา) ซึ่งคุณสามารถระบุสิ่งที่คุณต้องการจากนั้นเพียงแค่มอบหมายให้กับแฟรกเมนต์ / เทมเพลต "เนื้อหา" สำหรับเนื้อหาหลัก . ซึ่งหมายความว่าจะมีเพียงไฟล์เดียวที่จะย้ายส่วนหัวเข้ามา

ตัวเลือกระหว่างjsp:includeและTiles / Sitemesh / etcคือทางเลือกระหว่างความเรียบง่ายและพลังที่นักพัฒนาเผชิญอยู่ตลอดเวลา แน่นอนว่าถ้าคุณมีเพียงไม่กี่ไฟล์หรือไม่คาดว่ารูปแบบของคุณมีการเปลี่ยนแปลงบ่อยแล้วเพียงแค่ใช้และjstljsp:include

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

หากคุณแน่ใจว่าแอปพลิเคชันของคุณยังคงเรียบง่ายอยู่เสมอหรือคุณสามารถกำหนดเกณฑ์มาตรฐานของความซับซ้อนของแอปพลิเคชันหลังจากนั้นคุณจะรวมหนึ่งในโซลูชันที่ซับซ้อนมากขึ้นฉันขอแนะนำว่าอย่าใช้กระเบื้อง / ฯลฯ มิฉะนั้นให้ใช้ตั้งแต่เริ่มต้น

ฉันจะไม่โน้มน้าวให้คุณใช้เทคโนโลยีอื่น สำหรับสิ่งที่ฉันรู้ว่าทุกคนควรยึดติดกับ JSP ถ้ามันเหมาะกับพวกเขา

ฉันทำงานกับ Spring MVC เป็นหลักและฉันพบว่าJSP 2+ ร่วมกับ SiteMeshเป็นคู่ที่สมบูรณ์แบบ

SiteMesh 2/3

จัดเตรียมมัณฑนากรที่จะนำไปใช้กับมุมมองส่วนใหญ่เหมือนกับงานสืบทอดในเอนจินแม่แบบอื่น ๆ ฟีเจอร์ดังกล่าวไม่สามารถใช้งานได้หากไม่มีในปัจจุบัน

JSP 2+

คนที่อ้างว่า JSP จะทำให้ยากที่จะหลีกเลี่ยงโค้ด Java ในเทมเพลตนั้นเป็นของปลอม คุณไม่ควรทำและในเวอร์ชันนี้ไม่จำเป็นต้องทำเช่นนั้น เวอร์ชัน 2 รองรับวิธีการโทรโดยใช้ EL ซึ่งเป็นข้อได้เปรียบที่ยิ่งใหญ่เมื่อเทียบกับเวอร์ชันก่อนหน้า

ด้วยแท็กJSTLโค้ดของคุณจะยังคงดูเหมือน HTML ดังนั้นจึงไม่น่าอึดอัดใจ Spring รองรับ JSP ผ่าน taglibs ซึ่งมีประสิทธิภาพมาก

แท็กลิบยังขยายได้ง่ายดังนั้นการปรับแต่งสภาพแวดล้อมของคุณเองจึงเป็นเรื่องง่าย

หนึ่งในอาร์กิวเมนต์ที่ดีที่สุดสำหรับ facelets (ไม่ใช่ในรายการของคุณ แต่ฉันจะพูดถึงมัน) ซึ่งตรงข้ามกับการใช้ JSP คือการคอมไพล์จะรวมเข้ากับล่ามแทนที่จะถูกมอบหมายให้กับคอมไพเลอร์ JSP ซึ่งหมายความว่าสิ่งที่น่ารำคาญที่สุดอย่างหนึ่งที่ฉันมีกับ JSF 1.1 - การต้องเปลี่ยน id-attribute บน JSF-tag โดยรอบเมื่อบันทึกการเปลี่ยนแปลงเพื่อให้ runtime engine ค้นพบการเปลี่ยนแปลง - หายไปโดยให้ save- ในตัวแก้ไขโหลดซ้ำในเบราว์เซอร์วนกลับพร้อมกับข้อความแสดงข้อผิดพลาดที่ดีขึ้นมาก

เทคโนโลยีมุมมองที่ดีช่วยขจัดคำสั่ง if / switch / conditional ที่น่ารำคาญที่สุดและน่าเบื่อที่สุด การใช้เทคโนโลยีมุมมองที่ 'ซับซ้อน' ส่งผลให้แอปพลิเคชัน 'เรียบง่าย'

คุณไม่ได้ให้ข้อมูลเกี่ยวกับแอปพลิเคชันเฉพาะของคุณ ตัวอย่างเช่นฉันไม่ได้ใช้ JSP ด้วยเหตุผลบางประการ:

เป็นการยากที่จะหลีกเลี่ยงการใช้โค้ด Java ในเทมเพลต JSP ดังนั้นแนวคิดการแบ่งมุมมองที่แท้จริงของคุณและด้วยเหตุนี้คุณจะมีปัญหาในการรักษาโค้ดในหลาย ๆ ที่เป็นมุมมองและตัวควบคุม

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

JSP ต้องการการคอมไพล์และหากระบบเป้าหมายไม่มีคอมไพเลอร์ Java การปรับแต่งเล็กน้อยใด ๆ จะต้องใช้ระบบอื่นแล้วปรับใช้ใหม่

เครื่องยนต์ JSP ขั้นต่ำคือประมาณ 500k ของ bytecode บวก JSTL ดังนั้นจึงไม่เหมาะสำหรับระบบฝังตัว

เครื่องมือเทมเพลตสามารถสร้างเนื้อหาประเภทต่างๆในรูปแบบเดียวกันเช่น JSON payload, webpage, e-mail body, CSV และอื่น ๆ

โปรแกรมเมอร์ที่ไม่ใช่ Java อาจมีปัญหาในการทำงานกับเทมเพลต JSP เมื่อผู้ที่ไม่ใช่ผู้เชี่ยวชาญด้านเทคนิคไม่เคยมีปัญหาในการแก้ไขเทมเพลตทั่วไป

ฉันถามคำถามเดียวกันเมื่อนานมาแล้วและจบลงด้วยการเขียนเฟรมเวิร์กของฉัน (ซึ่งใช้เทมเพลตเอนจิ้น) ซึ่งปราศจากข้อเสียทั้งหมดที่ฉันเห็นในโซลูชันอื่น ไม่จำเป็นต้องบอกว่าเป็นรหัสไบต์ประมาณ 100k

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

ส่วนหนึ่งเป็นเรื่องของมาตราส่วน คุณอาจคิดว่าการรวมนั้นมีประสิทธิภาพมากพอ ๆ กับสมมติว่าแผนผังเว็บไซต์และนั่นก็เป็นความจริงอย่างแน่นอนอย่างน้อยก็สำหรับหน้าเว็บจำนวนน้อย (ฉันบอกว่าอาจจะประมาณ 100 หน้า) แต่ถ้าคุณมีหลายพันมันก็เริ่มไม่สามารถจัดการได้ (ดังนั้นสำหรับ eBay จึงไม่จำเป็นสำหรับ Salesforce อาจเป็นได้)

นอกจากนี้ตามที่ได้กล่าวไปแล้ว freemarker และ velocity ไม่ได้เจาะจงเฉพาะ คุณสามารถใช้เพื่ออะไรก็ได้ (เทมเพลตอีเมลเอกสารออฟไลน์ ฯลฯ ) คุณไม่จำเป็นต้องมี Servlet container เพื่อใช้ freemarker หรือ velocity

สุดท้ายข้อ 5 ของคุณเป็นจริงเพียงบางส่วน มีการคอมไพล์ทุกครั้งที่เข้าถึงหากยังไม่ได้รับ ซึ่งหมายความว่าเมื่อใดก็ตามที่คุณเปลี่ยนแปลงบางสิ่งคุณต้องจำไว้ว่าให้ลบไดเร็กทอรี "work" ของคอนเทนเนอร์ servlet ของคุณเพื่อให้คอมไพล์ JSP สิ่งนี้ไม่จำเป็นสำหรับเครื่องมือสร้างเทมเพลต

TL; DR Templaing engine ถูกเขียนขึ้นเพื่อแก้ไขข้อบกพร่องบางประการ (ที่รับรู้หรือจริง) ของ JSP + JSTL คุณควรใช้หรือไม่นั้นขึ้นอยู่กับความต้องการและขนาดของโครงการของคุณ