XSLT คุ้มไหม [ปิด]

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

ฉันยังคงทำงานอยู่จนถึงทุกวันนี้ ( ตอนนี้ฉันควรจะทำมันตอนนี้แทนที่จะเล่น SO ) และฉันได้เห็นสิ่งต่างๆมากขึ้นซึ่งทำให้ฉันคิดว่าการตัดสินใจทิ้ง XSLT คือ เป็นสิ่งที่ดี

ฉันรู้ว่า XSLT มีสถานที่ในการที่จะเป็นมาตรฐานได้รับการยอมรับและว่าถ้าทุกคนเขียนล่ามของตัวเอง 90% ของพวกเขาจะจบลงในTheDailyWTF แต่เนื่องจากเป็นภาษารูปแบบการทำงานแทนที่จะเป็นรูปแบบขั้นตอนที่โปรแกรมเมอร์ส่วนใหญ่คุ้นเคยสำหรับคนที่เริ่มต้นโครงการเช่นของฉันคุณจะแนะนำให้พวกเขาไปตามเส้นทางที่ฉันทำหรือใช้ XSLT ?

ข้อดีของ XSLT:

• โดเมนเฉพาะสำหรับ XML ดังนั้นตัวอย่างเช่นไม่จำเป็นต้องอ้างถึง XML ตัวอักษรในเอาต์พุต
• รองรับ XPath / XQuery ซึ่งเป็นวิธีที่ดีในการสืบค้น DOM ในลักษณะเดียวกับที่นิพจน์ทั่วไปเป็นวิธีที่ดีในการสืบค้นสตริง
• ภาษาที่ใช้งานได้

ข้อเสียของ XSLT:

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

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

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

มิฉะนั้นฉันจะบอกว่าหากภาษาโปรแกรมที่คุณชื่นชอบมีการใช้งาน DOM ที่ดีซึ่งรองรับ XPath และช่วยให้คุณสร้างเอกสารได้อย่างมีประโยชน์การใช้ XSLT ก็มีประโยชน์เล็กน้อย การเชื่อมโยงกับ libxml2 และ gdome2 ควรทำอย่างดีและไม่มีความละอายในการยึดติดกับภาษาที่ใช้งานทั่วไปที่คุณรู้จักดี

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

ปฏิเสธมาก!

ฉันใช้ XSLT มาหลายปีแล้วและรักมันอย่างแท้จริง สิ่งสำคัญที่คุณต้องตระหนักคือไม่ใช่ภาษาโปรแกรม แต่เป็นภาษาแม่แบบ (และด้วยเหตุนี้ฉันพบว่ามันเหนือกว่า asp.net / spit อย่างสุดจะพรรณนาได้)

XML เป็นรูปแบบข้อมูลโดยพฤตินัยของการพัฒนาเว็บในปัจจุบันไม่ว่าจะเป็นไฟล์กำหนดค่าข้อมูลดิบหรือในหน่วยความจำ reprsentation XSLT และ XPath ให้คุณมหาศาลวิธีที่มีประสิทธิภาพและมีประสิทธิภาพมากในการแปลงข้อมูลที่เป็นรูปแบบการออกใด ๆ ที่คุณอาจจะชอบทันทีให้คุณว่าทุกแง่มุม MVC การแยกการนำเสนอจากข้อมูล

จากนั้นก็มีความสามารถของยูทิลิตี้: การล้างเนมสเปซการรับรู้นิยามสคีมาที่แตกต่างกันการรวมเอกสาร

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

กรณีการใช้งานในโลกแห่งความจริง: ฉันเพิ่งเขียนแอปที่จัดการเอกสาร XML ในหน่วยความจำทั่วทั้งระบบและแปลงเป็น JSON, HTML หรือ XML ตามที่ผู้ใช้ปลายทางร้องขอ ฉันมีคำขอค่อนข้างสุ่มเพื่อให้เป็นข้อมูล Excel อดีตเพื่อนร่วมงานเคยทำสิ่งที่คล้ายกันโดยใช้โปรแกรม แต่ต้องใช้โมดูลของไฟล์คลาสสองสามไฟล์และเซิร์ฟเวอร์นั้นได้ติดตั้ง MS Office! ปรากฎว่า Excel มี XSD: ฟังก์ชันใหม่ที่มีผลกระทบจากรหัสพื้นฐานขั้นต่ำใน 3 ชั่วโมง

โดยส่วนตัวแล้วฉันคิดว่ามันเป็นหนึ่งในสิ่งที่สะอาดที่สุดที่ฉันเคยพบในอาชีพการงานของฉันและฉันเชื่อว่าปัญหาที่ชัดเจนทั้งหมด (การดีบักการจัดการสตริงโครงสร้างการเขียนโปรแกรม) ล้วนแล้วแต่เป็นความเข้าใจที่ผิดพลาดเกี่ยวกับเครื่องมือ

เห็นได้ชัดว่าฉันเชื่ออย่างยิ่งว่ามัน "คุ้มค่า"

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

คำตอบหลายข้อสรุปได้ว่า "ไม่ดีสำหรับการสร้างเว็บไซต์" หรือ "ไม่มีอะไรเหมือนกับภาษา X" ผู้เชี่ยวชาญด้านเทคโนโลยีจำนวนมากผ่านอาชีพของตนโดยไม่ได้สัมผัสกับภาษาที่ใช้งานได้ / ประกาศ เมื่อฉันกำลังสอนคนที่มีประสบการณ์ Java / VB / C / etc คือคนที่มีปัญหากับภาษา (ตัวแปรคือตัวแปรในแง่ของพีชคณิตไม่ใช่การเขียนโปรแกรมขั้นตอน) มีหลายคนตอบที่นี่ - ฉันไม่เคยใช้ Java มาก่อน แต่ฉันจะไม่รำคาญที่จะวิจารณ์ภาษาเพราะอย่างนั้น

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

นักเรียนธนาคารที่ฉันเห็นใช้กล่อง DataPower โดยทั่วไป นี่คืออุปกรณ์ XML และใช้นั่งระหว่างบริการ 'พูด' ภาษา XML ที่แตกต่างกัน การแปลงจากภาษา XML หนึ่งไปเป็นอีกภาษาหนึ่งนั้นแทบจะไม่สำคัญใน XSLT และจำนวนนักเรียนที่เข้าร่วมหลักสูตรของฉันก็เพิ่มขึ้น

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

มีคนข้างบนให้ความเห็นว่าสคริปต์มักจะต่ำกว่า 60 บรรทัดหรือดูเทอะทะ หากมันดูเทอะทะโอกาสที่ coder ไม่ได้รับความคิดจริงๆ - XSLT เป็นความคิดที่แตกต่างจากภาษาอื่น ๆ หากคุณไม่เข้าใจมันจะไม่ได้ผล

ไม่ใช่ภาษาที่กำลังจะตายอย่างแน่นอน (จำนวนงานที่ฉันได้รับบอกฉันอย่างนั้น) ตอนนี้มัน 'ติดขัด' เล็กน้อยจนกว่า Microsoft จะเสร็จสิ้นการใช้งาน XSLT 2 (ช้ามาก) แต่ก็ยังคงอยู่ที่นั่นและดูเหมือนว่าจะแข็งแกร่งจากมุมมองของฉัน

เราใช้ XSLT อย่างกว้างขวางสำหรับสิ่งต่างๆเช่นเอกสารและการตั้งค่าการกำหนดค่าที่ซับซ้อนบางอย่างที่ผู้ใช้สามารถให้บริการ

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

<ReleaseNotes>
    <FixedBugs>
        <Bug id="123" component="Admin">Error when clicking the Foo button</Bug>
        <Bug id="125" component="Core">Crash at startup when configuration is missing</Bug>
        <Bug id="127" component="Admin">Error when clicking the Bar button</Bug>
    </FixedBugs>
</ReleaseNotes>

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

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

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

XSLT เป็นตัวอย่างของภาษา โปรแกรมที่เปิดเผย

ตัวอย่างอื่น ๆ ของภาษาโปรแกรมที่เปิดเผย ได้แก่ นิพจน์ทั่วไป Prolog และ SQL สิ่งเหล่านี้มีความชัดเจนและกะทัดรัดและโดยปกติแล้วได้รับการออกแบบมาเป็นอย่างดีและมีประสิทธิภาพสำหรับงานที่ออกแบบมา

อย่างไรก็ตามนักพัฒนาซอฟต์แวร์โดยทั่วไปเกลียดภาษาดังกล่าวเนื่องจากภาษาเหล่านี้แตกต่างจาก OO หลักหรือภาษาขั้นตอนมากจนยากที่จะเรียนรู้และแก้ไขข้อบกพร่อง ลักษณะที่กะทัดรัดของพวกเขาโดยทั่วไปทำให้ง่ายต่อการสร้างความเสียหายจำนวนมากโดยไม่ได้ตั้งใจ

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

ฉันจำโฆษณาทั้งหมดรอบ XSLT ได้เมื่อมีการเปิดตัวมาตรฐานใหม่ ความตื่นเต้นทั้งหมดเกี่ยวกับความสามารถในการสร้าง HTML UI ทั้งหมดด้วยการแปลงแบบ 'ง่าย'

มาดูกันว่ามันใช้งานยากใกล้จะเป็นไปไม่ได้ที่จะแก้ปัญหามักจะช้าเหลือทน ผลลัพธ์สุดท้ายมักจะแปลกใหม่และน้อยกว่าอุดมคติ

ฉันจะกัดขาตัวเองได้เร็วกว่าใช้ XSLT ในขณะที่มีวิธีที่ดีกว่าในการทำสิ่งต่างๆ ยังคงมีสถานที่ที่ดีสำหรับงานแปลงร่างง่ายๆ

ฉันใช้ XSLT (และ XQuery) อย่างกว้างขวางสำหรับสิ่งต่าง ๆ - เพื่อสร้างโค้ด C ++ เป็นส่วนหนึ่งของกระบวนการสร้างเพื่อสร้างเอกสารจากความคิดเห็นของเอกสารและภายในแอปพลิเคชันที่ต้องทำงานกับ XML โดยทั่วไปและ XHTML โดยเฉพาะอย่างยิ่ง . โดยเฉพาะอย่างยิ่งตัวสร้างโค้ดนั้นเกินกว่า 10,000 บรรทัดของโค้ด XSLT 2.0 ที่กระจายไปรอบ ๆ ไฟล์ที่แยกจากกันประมาณหนึ่งโหล (มันทำหลายสิ่งหลายอย่าง - ส่วนหัวสำหรับไคลเอนต์, การรีสตาร์ทพร็อกซี / สตับ, COM wrappers,. NET wrappers, ORM - เพื่อตั้งชื่อ จำนวนน้อย). ฉันได้รับมรดกจากผู้ชายอีกคนหนึ่งที่ไม่เข้าใจภาษาดีจริงๆและบิตที่เก่ากว่านั้นก็ค่อนข้างยุ่งเหยิง อย่างไรก็ตามสิ่งใหม่ ๆ ที่เราเขียนนั้นส่วนใหญ่ยังคงมีเหตุผลและอ่านได้และฉันจำไม่ได้ว่ามีปัญหาใด ๆ เกี่ยวกับการบรรลุเป้าหมายนั้น แน่นอนว่ามันไม่ยากไปกว่าการทำ C ++

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

สรุปได้ว่าเป็นเครื่องมือที่มีประโยชน์อย่างเหลือเชื่อที่มีอยู่ในกล่องเครื่องมือ แต่เป็นเครื่องมือที่เชี่ยวชาญมากดังนั้นจึงใช้ได้ดีตราบเท่าที่คุณใช้อย่างถูกต้องและตามวัตถุประสงค์ ฉันหวังว่าจะมีการใช้งาน. NET ของ XSLT 2.0 ที่เหมาะสม

ฉันใช้ XSLT (เพราะไม่มีทางเลือกอื่นที่ดีกว่า) แต่ไม่ใช่เพื่อการนำเสนอเพียงเพื่อการเปลี่ยนแปลง:

1. ฉันเขียนการแปลง XSLT สั้น ๆ เพื่อทำการแก้ไขจำนวนมากในไฟล์ maven pom.xml ของเรา

2. ฉันได้เขียนไปป์ไลน์ของการแปลงเพื่อสร้าง XML Schemas จาก XMI (UML Diagram) มันใช้งานได้ระยะหนึ่ง แต่ในที่สุดมันก็ซับซ้อนเกินไปและเราต้องเอามันออกไปด้านหลังโรงนา

3. ฉันใช้การแปลงเพื่อ refactor XML Schemas

4. ฉันได้แก้ไขข้อ จำกัด บางอย่างใน XSLT โดยใช้เพื่อสร้าง XSLT เพื่อทำงานจริง (เคยพยายามเขียน XSLT ที่สร้างเอาต์พุตโดยใช้เนมสเปซที่ไม่รู้จักจนกว่าจะรันไทม์?)

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

ที่กล่าวว่าฉันกำลังตรวจสอบโดยใช้Clojure (เสียงกระเพื่อม) เพื่อทำการแปลง XML แต่ฉันยังไม่ได้รับข้อมูลมากพอที่จะรู้ว่าแนวทางนั้นจะทำให้ฉันได้รับประโยชน์หรือไม่

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

XSLT เป็นตัวเลือกที่สมบูรณ์แบบสำหรับการแปลจากรูปแบบเก่า -> รูปแบบใหม่ ภายในสองสัปดาห์ฉันมีการแปลงที่ใช้งานได้จากเก่าเป็นใหม่สำหรับหลายร้อยหน้าของเรา ฉันยังสามารถใช้มันเพื่อดึงข้อมูลมากมายในเค้าโครงของหน้า UI ของเรา ฉันสร้างรายการของส่วนประกอบที่ถูกฝังไว้ซึ่งค่อนข้างง่ายซึ่งฉันใช้ XSLT เพื่อเขียนลงในข้อกำหนดสคีมาของเรา

นอกจากนี้ยังมาจากพื้นหลัง C ++ จึงเป็นภาษาที่สนุกและน่าสนใจมาก

ฉันคิดว่าเป็นเครื่องมือในการแปล XML จากรูปแบบหนึ่งไปยังอีกรูปแบบหนึ่งมันยอดเยี่ยมมาก แต่ก็ไม่ได้เป็นวิธีเดียวที่จะกำหนดขั้นตอนวิธีการที่ใช้ XML เป็นอินพุทและเอาท์พุทบางสิ่งบางอย่าง หากอัลกอริทึมของคุณมีความซับซ้อนเพียงพอข้อเท็จจริงที่ว่าอินพุตเป็น XML จะไม่เกี่ยวข้องกับเครื่องมือที่คุณเลือกนั่นคือม้วนของคุณเองใน C ++ / Python / อะไรก็ตาม

เฉพาะตัวอย่างของคุณฉันคิดว่าแนวคิดที่ดีที่สุดคือการสร้างการแปลง XML-> XML ของคุณเองซึ่งเป็นไปตามตรรกะทางธุรกิจของคุณ จากนั้นเขียนตัวแปล XSLT ที่เพิ่งรู้เกี่ยวกับการจัดรูปแบบและไม่มีอะไรฉลาด นั่นอาจเป็นจุดศูนย์กลางที่ดี แต่ทั้งหมดขึ้นอยู่กับสิ่งที่คุณกำลังทำ การมีตัวแปล XSLT บนเอาต์พุตทำให้ง่ายต่อการสร้างรูปแบบเอาต์พุตอื่น - พิมพ์ได้สำหรับโทรศัพท์มือถือและอื่น ๆ

ใช่ฉันใช้มันมาก ด้วยการใช้ไฟล์ xslt ที่แตกต่างกันฉันสามารถใช้ซอร์ส XML เดียวกันเพื่อสร้างไฟล์ HTML หลายภาษา (X) หลายไฟล์ (นำเสนอข้อมูลเดียวกันในรูปแบบต่างๆ) ฟีด RSS ฟีด Atom ไฟล์ตัวอธิบาย RDF และส่วนของแผนผังเว็บไซต์ .

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

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

ใช่มันเป็นความเจ็บปวดในขณะที่คุณกำลังเรียนรู้ แต่ความเจ็บปวดส่วนใหญ่เกิดจากความคุ้นเคย ความเจ็บปวดจะลดน้อยลงเมื่อคุณเรียนรู้ภาษา

W3schools มีบทความสองบทความที่มีคุณค่าเป็นพิเศษ: http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

ฉันพบว่า XSLT ค่อนข้างยากที่จะทำงานด้วย

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

ทางเลือกกลับกลายเป็นหายนะ XSLT ปรากฎว่าเป็นความเจ็บปวดในการเขียน ดังนั้นหน้าทั้งหมดของเราจึงยากที่จะเขียนและดูแลรักษา เราจะทำได้ดีกว่ามากหากใช้ JSP (นี่คือใน Java) หรือวิธีการที่คล้ายกันบางอย่างที่ใช้มาร์กอัป (วงเล็บมุม) สำหรับรูปแบบเอาต์พุต (HTML) และมาร์กอัปประเภทอื่น (เช่น <% ... %>) สำหรับข้อมูลเมตา สิ่งที่สับสนที่สุดเกี่ยวกับ XSLT คือมันถูกเขียนด้วย XML และแปลจาก XML เป็น XML ... มันค่อนข้างยากที่จะเก็บเอกสาร XML ทั้ง 3 แบบไว้ในใจ

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

อย่างไรก็ตามหากสิ่งที่คุณมีนั้นง่ายกว่านั้น: คุณมีข้อมูลในรูปแบบ XML เดียวและต้องการทำการแก้ไขแบบง่ายๆไม่ใช่ DSL แบบเต็มหน้าคำอธิบาย แต่มีการปรับเปลี่ยนที่เรียบง่ายตรงไปตรงมา XSLT เป็นเครื่องมือที่ยอดเยี่ยมสำหรับจุดประสงค์นั้น ลักษณะที่เปิดเผย (ไม่ใช่ขั้นตอน) เป็นข้อดีสำหรับจุดประสงค์นั้น

- ไมเคิลแชมไซด์

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

ฉันใช้ XSLT อย่างกว้างขวางสำหรับฟรอนต์เอนด์สไตล์ MVC ที่กำหนดเอง โมเดลถูก "serialized" เป็น xml (ไม่ใช่ผ่าน xml serializaiton) จากนั้นแปลงเป็น html ผ่าน xslt ข้อได้เปรียบเหนือ ASP.NET คือการผสานรวมอย่างเป็นธรรมชาติกับ XPath และข้อกำหนดเกี่ยวกับการขึ้นรูปที่เข้มงวดมากขึ้น (การให้เหตุผลเกี่ยวกับโครงสร้างเอกสารใน xslt นั้นง่ายกว่าในภาษาอื่น ๆ )

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

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

ฉันใช้ XML, XSD และ XSLT ในโปรเจ็กต์การรวมระหว่างระบบ DB ที่ไม่เหมือนกันในช่วงปี 2004 ฉันต้องเรียนรู้ XSD และ XSLT ตั้งแต่เริ่มต้น แต่มันก็ไม่ยาก สิ่งที่ยอดเยี่ยมเกี่ยวกับเครื่องมือเหล่านี้คือมันช่วยให้ฉันสามารถเขียนโค้ด C ++ ที่เป็นอิสระจากข้อมูลโดยอาศัย XSD และ XSLT เพื่อตรวจสอบ / ตรวจสอบและแปลงเอกสาร XML เปลี่ยนรูปแบบข้อมูลเปลี่ยนเอกสาร XSD และ XSLT ไม่ใช่รหัส C ++ ที่ใช้ไลบรารี Xerces

สำหรับความสนใจ: XSD หลักคือ 150KB และขนาดเฉลี่ยของ XSLT คือ <5KB IIRC

ข้อดีอีกอย่างคือ XSD เป็นเอกสารข้อมูลจำเพาะที่ XSLT ยึดตาม ทั้งสองทำงานสอดประสานกัน และข้อมูลจำเพาะหายากในการพัฒนาซอฟต์แวร์ในปัจจุบัน

แม้ว่าฉันจะไม่มีปัญหามากเกินไปในการเรียนรู้ลักษณะที่เปิดเผย XSD และ XSLT แต่ฉันพบว่าโปรแกรมเมอร์ C / C ++ คนอื่นมีปัญหาอย่างมากในการปรับตัวให้เข้ากับวิธีการประกาศ เมื่อพวกเขาเห็นว่ามันเป็นขั้นตอนอาพวกเขาก็พึมพำตอนนี้ฉันเข้าใจแล้ว! และพวกเขาดำเนินการ (เล่นสำนวน?) เพื่อเขียน XSLT ขั้นตอน! สิ่งนี้คือคุณต้องเรียนรู้ XPath และเข้าใจแกนของ XML ทำให้ฉันนึกถึงโปรแกรมเมอร์ C สมัยก่อนที่ปรับมาใช้ OO เมื่อเขียน C ++

ฉันใช้เครื่องมือเหล่านี้เนื่องจากช่วยให้ฉันสามารถเขียนฐานรหัส C ++ ขนาดเล็กที่แยกออกจากทั้งหมดยกเว้นพื้นฐานที่สุดของการปรับเปลี่ยนโครงสร้างข้อมูลและสิ่งเหล่านี้คือการเปลี่ยนแปลงโครงสร้าง DB แม้ว่าฉันจะชอบภาษา C ++ มากกว่าภาษาอื่นฉันก็จะใช้สิ่งที่ฉันคิดว่ามีประโยชน์เพื่อเป็นประโยชน์ต่อการดำเนินงานในระยะยาวของโครงการซอฟต์แวร์

ฉันเคยคิดว่า XSLT เป็นความคิดที่ดี ฉันหมายความว่ามันเป็นความคิดที่ดี

ที่มันล้มเหลวคือการดำเนินการ

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

ตกลงคุณสามารถ 'เครื่องมือ' ได้ - ฉันคิดว่านั่นเป็นส่วนหนึ่งของการออกแบบ - แต่นั่นเป็นความล้มเหลวครั้งที่สอง: เครื่องมือ XSLT ทั้งหมดในตลาดนั้นค่อนข้างง่าย ... อึ!

ข้อกำหนด XSLTกำหนด XSLT เป็น "ภาษาสำหรับการเปลี่ยนเอกสาร XML ลงในเอกสาร XML อื่น ๆ" หากคุณกำลังพยายามทำสิ่งใดก็ตาม แต่การประมวลผลข้อมูลขั้นพื้นฐานที่สุดภายใน XSLT อาจมีวิธีแก้ปัญหาที่ดีกว่า

นอกจากนี้ควรสังเกตว่าความสามารถในการประมวลผลข้อมูลของ XSLT สามารถขยายได้ใน. NET โดยใช้ฟังก์ชันส่วนขยายที่กำหนดเอง:

• เอกสาร MSDN
• CSharpFriends: บทช่วยสอน

ฉันดูแลระบบเอกสารออนไลน์สำหรับ บริษัท ของฉัน ผู้เขียนสร้างเอกสารใน SGML (xml เช่นภาษา) จากนั้น SGML จะรวมกับ XSLT และเปลี่ยนเป็น HTML

สิ่งนี้ช่วยให้เราทำการเปลี่ยนแปลงเค้าโครงเอกสารได้อย่างง่ายดายโดยไม่ต้องเข้ารหัสใด ๆ เป็นเพียงเรื่องของการเปลี่ยน XSLT

สิ่งนี้ใช้ได้ดีกับเรา ในกรณีของเราเป็นเอกสารอ่านอย่างเดียว ผู้ใช้ไม่ได้โต้ตอบกับเอกสาร

นอกจากนี้เมื่อใช้ XSLT คุณกำลังทำงานใกล้ชิดกับโดเมนปัญหา (HTML) ฉันคิดว่านั่นเป็นความคิดที่ดีเสมอ

สุดท้ายนี้หากระบบปัจจุบันของคุณใช้งานได้ให้ปล่อยทิ้งไว้เฉยๆ ฉันจะไม่แนะนำให้ทิ้งรหัสที่มีอยู่ของคุณ ถ้าฉันเริ่มต้นใหม่ฉันจะใช้ XSLT แต่ในกรณีของคุณฉันจะใช้สิ่งที่คุณมี

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

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

ฉันยังเชื่อว่า XSLT มีประโยชน์ แต่มันเป็นภาษาที่น่าเกลียดและอาจนำไปสู่ความยุ่งเหยิงที่ไม่สามารถอ่านได้และไม่สามารถเข้าถึงได้ ส่วนหนึ่งเป็นเพราะ XML นั้นมนุษย์ไม่สามารถอ่านได้เพียงพอที่จะสร้าง "ภาษา" และส่วนหนึ่งเป็นเพราะ XSLT ติดอยู่ระหว่างการประกาศและขั้นตอน ต้องบอกว่าและฉันคิดว่าการเปรียบเทียบสามารถวาดได้ด้วยนิพจน์ทั่วไปมันมีการใช้เมื่อพูดถึงปัญหาที่กำหนดไว้อย่างดี

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

หากคุณสามารถใช้ XSLT ในรูปแบบที่เปิดเผยได้ (แม้ว่าฉันจะไม่เห็นด้วยว่าเป็นภาษาที่เปิดเผย) ฉันคิดว่ามันมีประโยชน์และแสดงออกได้

ฉันเขียนเว็บแอปที่ใช้ภาษา OO (C # ในกรณีของฉัน) เพื่อจัดการชั้นข้อมูล / การประมวลผล แต่ส่งออก XML แทนที่จะเป็น HTML จากนั้นไคลเอ็นต์สามารถใช้เป็นข้อมูล API ได้โดยตรงหรือแสดงเป็น HTML โดย XSLTs เนื่องจาก C # กำลังแสดงผล XML ที่เข้ากันได้กับโครงสร้างกับการใช้งานนี้จึงราบรื่นมากและตรรกะการนำเสนอก็ยังคงเปิดเผย ติดตามและเปลี่ยนแปลงได้ง่ายกว่าการส่งแท็กจาก C #

อย่างไรก็ตามในขณะที่คุณต้องการตรรกะการประมวลผลมากขึ้นในระดับ XSLT มันจะซับซ้อนและละเอียดมากแม้ว่าคุณจะ "ได้รับ" รูปแบบการทำงานก็ตาม

แน่นอนว่าทุกวันนี้ฉันอาจจะเขียนเว็บแอปเหล่านั้นโดยใช้อินเทอร์เฟซ RESTful - และฉันคิดว่า "ภาษา" ข้อมูลเช่น JSON กำลังได้รับแรงฉุดในพื้นที่ที่ XSLT เปลี่ยน XML แต่สำหรับตอนนี้ XSLT ยังคงเป็นเทคโนโลยีที่สำคัญและมีประโยชน์

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

บางทีคุณควรดูภาษามาร์กอัปอื่น ๆ ที่มีอยู่ ฉันเชื่อว่าเจฟฟ์ทำบทความเกี่ยวกับหัวข้อนี้เกี่ยวกับ Stack Overflow

HTML เป็นภาษามาร์กอัปอย่างมีมนุษยธรรมหรือไม่?

ฉันจะดูสิ่งที่เขาเขียน คุณอาจพบแพคเกจซอฟต์แวร์ที่ทำในสิ่งที่คุณต้องการ "นอกกรอบ" หรืออย่างน้อยที่สุดแทนที่จะเขียนเนื้อหาของคุณเองตั้งแต่ต้น

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

ฉันเคยใช้ XSLT มาก่อน กลุ่มของไฟล์ 6 .xslt (refactored จากไฟล์ขนาดใหญ่หนึ่งไฟล์) มีความยาวประมาณ 2750 บรรทัดก่อนที่ฉันจะเขียนใหม่ใน C # ปัจจุบันรหัส C # คือ 4000 บรรทัดที่มีตรรกะมากมาย ฉันไม่อยากคิดด้วยซ้ำว่าจะต้องเขียนอะไรใน XSLT

จุดที่ฉันยอมแพ้คือเมื่อฉันตระหนักว่าไม่มี XPATH 2.0 กำลังส่งผลกระทบต่อความก้าวหน้าของฉันอย่างมาก

เพื่อตอบคำถามสามข้อของคุณ:

1. ฉันเคยใช้ XSLT เมื่อหลายปีก่อน
2. ฉันเชื่อว่า XSLT อาจเป็นทางออกที่เหมาะสมในบางสถานการณ์ (ไม่เคยพูดไม่เคย)
3. ฉันมักจะเห็นด้วยกับการประเมินของคุณว่าส่วนใหญ่มีประโยชน์สำหรับการเปลี่ยนแปลงแบบ 'เรียบง่าย' แต่ฉันคิดว่าตราบใดที่คุณเข้าใจ XSLT เป็นอย่างดีก็ยังมีกรณีที่ต้องทำขึ้นเพื่อใช้สำหรับงานใหญ่ ๆ เช่นการเผยแพร่เว็บไซต์เนื่องจาก XML เปลี่ยนเป็น HTML

ฉันเชื่อว่าสาเหตุที่นักพัฒนาหลายคนไม่ชอบ XSLT เป็นเพราะพวกเขาไม่เข้าใจกระบวนทัศน์ที่แตกต่างกันโดยพื้นฐานที่มันเป็นไป แต่ด้วยความสนใจล่าสุดในการเขียนโปรแกรมเชิงฟังก์ชันเราอาจเห็น XSLT กลับมาอีกครั้ง ...

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

ที่ บริษัท ก่อนหน้านี้เราทำหลายอย่างกับ XML และ XSLT ทั้ง XML และ XSLT ใหญ่

ใช่มีช่วงการเรียนรู้ แต่คุณมีเครื่องมือที่มีประสิทธิภาพในการจัดการ XML และคุณยังสามารถใช้ XSLT บน XSLT (ซึ่งบางครั้งอาจมีประโยชน์)

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

ใครก็ตามที่มีความรู้เกี่ยวกับ XSLT สามารถเปลี่ยนลักษณะของผลิตภัณฑ์สำเร็จรูปได้เนื่องจากไม่ได้รวบรวม

ฉันชอบ XSLT เป็นการส่วนตัวและคุณอาจต้องการให้รูปลักษณ์ของไวยากรณ์ที่เรียบง่ายดู (ไม่มีเทมเพลตที่ชัดเจนเป็นเพียงไฟล์ HTML แบบเก่าปกติที่มีแท็ก XSLT สองสามแท็กเพื่อคายค่าลงในไฟล์) แต่ไม่ใช่สำหรับทุกคน

บางทีคุณอาจแค่ต้องการเสนออินเทอร์เฟซ Wiki หรือ Markdown ให้ผู้เขียนของคุณ มีไลบรารีสำหรับสิ่งนั้นเช่นกันและหาก XSLT ไม่ทำงานสำหรับคุณ XML อาจไม่ทำงานสำหรับพวกเขาเช่นกัน

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

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

XSLT 2.0 มีฟังก์ชันสตริงมากกว่านี้ แต่ฉันคิดว่ามันไม่เหมาะกับภาษาและไม่มีการใช้งาน XSLT 2.0 มากนัก