سؤال

منذ فترة، بدأت في مشروع حيث قمت بتصميم مخطط XML-esque html حتى يتمكن المؤلفون من كتابة المحتوى الخاص بهم (مواد الدورة التعليمية) بتنسيق مبسط والذي سيتم بعد ذلك تحويله إلى HTML عبر XSLT.لقد تلاعبت بها (كافحت) لفترة من الوقت ووصلت بها إلى مستوى أساسي للغاية ولكن بعد ذلك كنت منزعجًا جدًا من القيود التي كنت أواجهها (والتي ربما كانت قيودًا على معرفتي) وعندما قرأت مدونة تقترح التخلص منها XSLT واكتب فقط محلل XML الخاص بك إلى أي لغة تختارها، لقد قفزت بفارغ الصبر إلى ذلك وقد نجح الأمر ببراعة.

ولا أزال أعمل عليه حتى يومنا هذا (من المفترض أن أعمل عليها الآن، بدلاً من اللعب على SO)، وأرى المزيد والمزيد من الأشياء التي تجعلني أعتقد أن قرار التخلص من XSLT كان قرارًا جيدًا.

أعلم أن XSLT له مكانه، لأنه معيار مقبول، وأنه إذا كان الجميع يكتبون مترجمين فوريين خاصين بهم، فإن 90٪ منهم سينتهي بهم الأمر إلى TheDailyWTF.ولكن بالنظر إلى أنه أ لغة النمط الوظيفي بدلاً من الأسلوب الإجرائي الذي يعرفه معظم المبرمجين، بالنسبة لشخص يشرع في مشروع مثل مشروعي، هل تنصحهم بالسير على المسار الذي اتبعته، أو التمسك به باستخدام XSLT?

هل كانت مفيدة؟

المحلول

مزايا XSLT:

  • مجال خاص بـ XML، لذلك على سبيل المثال لا حاجة لاقتباس XML الحرفي في المخرجات.
  • يدعم XPath/XQuery، والتي يمكن أن تكون طريقة لطيفة للاستعلام عن DOMs، بنفس الطريقة التي يمكن أن تكون بها التعبيرات العادية طريقة لطيفة للاستعلام عن السلاسل.
  • لغة وظيفية.

عيوب XSLT:

  • يمكن أن يكون مطولًا بشكل فاحش - لا يتعين عليك اقتباس XML الحرفي، مما يعني فعليًا أنه يتعين عليك اقتباس التعليمات البرمجية.وليس بطريقة جميلة.ولكن مرة أخرى، فهو ليس أسوأ بكثير من مباحث أمن الدولة النموذجية الخاصة بك.
  • لا يفعل أشياء معينة يعتبرها معظم المبرمجين أمرا مفروغا منه.على سبيل المثال، يمكن أن يكون التلاعب بالسلسلة عملاً روتينيًا.يمكن أن يؤدي هذا إلى "لحظات مؤسفة" عندما يقوم المبتدئون بتصميم التعليمات البرمجية، ثم يبحثون بشكل محموم في الويب عن تلميحات حول كيفية تنفيذ الوظائف التي افترضوا أنها موجودة ولم يمنحوا أنفسهم الوقت للكتابة.
  • لغة وظيفية.

بالمناسبة، إحدى طرق الحصول على السلوك الإجرائي هي ربط تحويلات متعددة معًا.بعد كل خطوة، يكون لديك DOM جديد تمامًا للعمل عليه والذي يعكس التغييرات في تلك الخطوة.تحتوي بعض معالجات XSL على امتدادات للقيام بذلك بشكل فعال في تحويل واحد، لكنني نسيت التفاصيل.

لذلك، إذا كانت التعليمات البرمجية الخاصة بك في الغالب عبارة عن مخرجات وليس بها الكثير من المنطق، فيمكن أن يكون XSLT طريقة رائعة جدًا للتعبير عنها.إذا كان هناك الكثير من المنطق، ولكن في الغالب من النماذج المضمنة في XSLT (حدد جميع العناصر التي تبدو مثل بلاه، ولكل منها ناتج بلاه)، فمن المحتمل أن تكون بيئة ودية تمامًا.إذا كنت ترغب في التفكير بطريقة XML في جميع الأوقات، فقم بتجربة XSLT 2.

بخلاف ذلك، أود أن أقول إنه إذا كانت لغة البرمجة المفضلة لديك تحتوي على تطبيق DOM جيد يدعم XPath ويسمح لك ببناء المستندات بطريقة مفيدة، فهناك فوائد قليلة لاستخدام XSLT.يجب أن تعمل الارتباطات بـ libxml2 وgdome2 بشكل جيد، وليس هناك عيب في الالتزام باللغات ذات الأغراض العامة التي تعرفها جيدًا.

عادةً ما تكون أدوات تحليل XML المحلية إما غير مكتملة (وفي هذه الحالة ستفشل في يوم ما) أو ليست أصغر بكثير من شيء كان من الممكن أن تحصل عليه من الرف (وفي هذه الحالة ربما تضيع وقتك)، وتعطي لديك أي عدد من الفرص لتقديم مشكلات أمنية خطيرة حول المدخلات الضارة.لا تكتب واحدة إلا إذا كنت تعرف بالضبط ما ستكسبه من خلال القيام بذلك.وهذا لا يعني أنه لا يمكنك كتابة محلل لشيء أبسط من XML كتنسيق الإدخال الخاص بك، إذا لم تكن بحاجة إلى كل ما يقدمه XML.

نصائح أخرى

الكثير من السلبية!

لقد كنت أستخدم XSLT منذ عدة سنوات، وأحبه حقًا.الشيء الرئيسي الذي عليك أن تدركه هو ذلك إنها ليست لغة برمجة، إنها لغة نموذجية (وفي هذا الصدد أجده متفوقًا بشكل لا يوصف على asp.net /spit).

XML هو تنسيق البيانات الفعلي لتطوير الويب اليوم، سواء كان ذلك في ملفات التكوين أو البيانات الأولية أو في تمثيل الذاكرة.يوفر لك 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 سطرًا أو أنها تصبح غير عملية.إذا أصبح الأمر غير عملي، فمن المحتمل أن المبرمج لم يفهم الفكرة حقًا - لغة 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 أمر قبيح، لذلك نقوم بتغذية البيانات من خلال شيء مثل TagSoup (الذي ينشئ أحداث SAX XML مناسبة، مما يتيح لنا بشكل أساسي التعامل مع HTML كما لو كان XML مكتوبًا بشكل صحيح) وبعد ذلك يمكننا تشغيل بعض XSLT ضدها، لتحويل البيانات إلى تنسيق "مستقر معروف" يمكننا العمل معه بالفعل .من خلال فصل هذا التحويل إلى ملف XSLT، فهذا يعني أنه إذا تغير تنسيق HTML، فلن يحتاج التطبيق نفسه إلى الترقية، وبدلاً من ذلك يمكن للمستخدم النهائي فقط تحرير ملف XSLT بنفسه، أو يمكننا إرسال بريد إلكتروني لهم ملف XSLT محدث دون الحاجة إلى ترقية النظام بأكمله.

أود أن أقول أنه بالنسبة لمشاريع الويب، هناك طرق أفضل للتعامل مع جانب العرض من XSLT اليوم، ولكن كتقنية هناك بالتأكيد استخدامات لـ XSLT.إنها ليست أسهل لغة في العالم للاستخدام، لكنها بالتأكيد لم تمت، ومن وجهة نظري لا يزال لديها الكثير من الاستخدامات الجيدة.

XSLT هو مثال على البرمجة التصريحية لغة.

تتضمن الأمثلة الأخرى للغات البرمجة التصريحية التعبيرات العادية، وProlog، وSQL.كل هذه العناصر معبرة للغاية وصغيرة الحجم، وعادةً ما تكون مصممة بشكل جيد جدًا وقوية للمهمة التي تم تصميمها من أجلها.

ومع ذلك، فإن مطوري البرامج عمومًا يكرهون مثل هذه اللغات، لأنها تختلف تمامًا عن اللغات الإجرائية أو اللغات الإجرائية الأكثر انتشارًا بحيث يصعب تعلمها وتصحيح أخطائها.طبيعتها المدمجة بشكل عام تجعل من السهل جدًا إحداث الكثير من الضرر عن غير قصد.

لذلك، في حين أن XSLT هي آلية فعالة لدمج البيانات في العرض التقديمي، إلا أنها تفشل في قسم سهولة الاستخدام.أعتقد أن هذا هو السبب وراء عدم انتشاره حقًا.

أتذكر كل الضجيج حول XSLT عندما تم إصدار المعيار حديثًا.كل الإثارة حول القدرة على بناء واجهة مستخدم HTML كاملة من خلال تحويل "بسيط".

دعونا نواجه الأمر، فهو صعب الاستخدام، ومن المستحيل تقريبًا تصحيح أخطائه، وغالبًا ما يكون بطيئًا بشكل لا يطاق.والنتيجة النهائية تكون دائمًا ملتوية وأقل من المثالية.

سأقوم بقضم ساقي عاجلاً بدلاً من استخدام XSLT بينما توجد طرق أفضل للقيام بالأشياء.لا يزال لديه أماكنه، وهو جيد لمهام التحويل البسيطة.

لقد استخدمت XSLT (وأيضًا XQuery) على نطاق واسع لأشياء مختلفة - لإنشاء تعليمات برمجية C++ كجزء من عملية الإنشاء، ولإنتاج وثائق من تعليقات المستندات، وداخل تطبيق يجب أن يعمل مع XML بشكل عام وXHTML بشكل خاص كثيرًا .كان منشئ التعليمات البرمجية على وجه الخصوص يزيد عن 10000 سطر من كود XSLT 2.0 منتشرة حول حوالي اثني عشر ملفًا منفصلاً (لقد قام بالكثير من الأشياء - رؤوس للعملاء، والوكلاء عن بعد/بذرة، ومغلفات COM، ومغلفات .NET، وORM - على سبيل المثال لا الحصر قليلة).لقد ورثتها عن شخص آخر لم يكن يفهم اللغة جيدًا، وبالتالي كانت الأجزاء القديمة في حالة من الفوضى.ومع ذلك، فإن الأشياء الأحدث التي كتبناها كانت في الغالب سليمة وسهلة القراءة، ولا أتذكر أي مشاكل معينة في تحقيق ذلك.بالتأكيد لم يكن الأمر أصعب من القيام بذلك مع لغة C++.

عند الحديث عن الإصدارات، فإن التعامل مع XSLT 2.0 يساعد بالتأكيد على إبقائك عاقلًا، ولكن الإصدار 1.0 لا يزال مناسبًا للتحويلات الأبسط.في مكانها، فهي أداة سهلة الاستخدام للغاية، ومن الصعب مطابقة الإنتاجية التي تحصل عليها من بعض الميزات الخاصة بالمجال (الأهم من ذلك، الإرسال الديناميكي عبر مطابقة القالب).على الرغم من الألفاظ الملحوظة في بناء الجملة المستند إلى XML الخاص بـ XSLT، إلا أن نفس الشيء في LINQ إلى XML (حتى في VB مع أحرف XML الحرفية) كان عادةً أطول عدة مرات.ومع ذلك، في كثير من الأحيان، يتم انتقادها بشكل غير مستحق بسبب الاستخدام غير الضروري لـ XML في بعض الحالات في المقام الأول.

ليتم تلخيصه:إنها أداة مفيدة بشكل لا يصدق في صندوق الأدوات الخاص بك، ولكنها أداة متخصصة للغاية، لذا فهي جيدة طالما أنك تستخدمها بشكل صحيح وللغرض المقصود منها.أتمنى حقًا أن يكون هناك تطبيق .NET أصلي مناسب لـ XSLT 2.0.

أستخدم XSLT (لعدم وجود بديل أفضل)، ولكن ليس للعرض التقديمي، فقط للتحويل:

  1. أكتب تحويلات XSLT قصيرة لإجراء تعديلات جماعية على ملفات pom.xml الخاصة بنا.

  2. لقد قمت بكتابة سلسلة من التحويلات لإنشاء مخططات XML من XMI (مخطط UML).لقد نجح الأمر لفترة من الوقت، لكنه أصبح أخيرًا معقدًا للغاية وكان علينا التخلص منه خلف الحظيرة.

  3. لقد استخدمت التحويلات لإعادة بناء مخططات XML.

  4. لقد تغلبت على بعض القيود في XSLT باستخدامه لإنشاء XSLT للقيام بالعمل الحقيقي.(هل سبق لك أن حاولت كتابة ملف XSLT ينتج عنه مخرجات باستخدام مساحات أسماء غير معروفة حتى وقت التشغيل؟)

أستمر في العودة إليه لأنه يقوم بعمل أفضل في التجول في ملف XML الذي يعالجه مقارنة بالطرق الأخرى التي جربتها، والتي بدت خاسرة بلا داع أو ببساطة أساءت فهم XML.XSLT غير سارة، ولكن أجد استخدامه الأكسجين يجعلها محتملة.

ومع ذلك، أنا أحقق في استخدام كلوجر (lisp) لإجراء تحويلات لـ XML، لكنني لم أقطع مسافة كافية حتى الآن لأعرف ما إذا كان هذا الأسلوب سيجلب لي فوائد.

أنا شخصياً استخدمت XSLT في سياق مختلف تمامًا.استخدمت لعبة الكمبيوتر التي كنت أعمل عليها في ذلك الوقت عددًا كبيرًا من صفحات واجهة المستخدم المحددة باستخدام XML.أثناء عملية إعادة البناء الرئيسية بعد وقت قصير من الإصدار، أردنا تغيير بنية مستندات XML هذه.لقد جعلنا تنسيق إدخال اللعبة يتبع بنية أفضل بكثير وأكثر وعيًا بالمخطط.

يبدو أن XSLT هو الخيار الأمثل لهذه الترجمة من التنسيق القديم -> التنسيق الجديد.وفي غضون أسبوعين، أجريت تحويلاً عمليًا من القديم إلى الجديد لمئات الصفحات لدينا.لقد تمكنت أيضًا من استخدامه لاستخراج الكثير من المعلومات حول تخطيط صفحات واجهة المستخدم الخاصة بنا.لقد قمت بإنشاء قوائم بالمكونات التي تم تضمينها فيها بسهولة نسبية ثم استخدمت بعد ذلك XSLT للكتابة في تعريفات المخطط الخاص بنا.

أيضًا، نظرًا لأنها تأتي من خلفية C++، فقد كانت لغة ممتعة جدًا ومثيرة للاهتمام لإتقانها.

أعتقد أنها أداة رائعة لترجمة XML من تنسيق إلى آخر.ومع ذلك، فهي ليست الطريقة الوحيدة لتحديد خوارزمية تأخذ XML كمدخلات ومخرجات شئ ما.إذا كانت الخوارزمية الخاصة بك معقدة بما فيه الكفاية، فإن حقيقة أن الإدخال هو XML يصبح غير ذي صلة باختيارك للأداة - على سبيل المثال، استخدم خوارزميتك الخاصة في C++ / Python / أيًا كان.

بالنسبة لمثالك، أتخيل أن أفضل فكرة هي إنشاء XML->تحويل XML الخاص بك والذي يتبع منطق عملك.بعد ذلك، اكتب مترجم XSLT يعرف فقط التنسيق ولا يفعل شيئًا ذكيًا.قد يكون هذا حلاً وسطًا جيدًا ولكنه يعتمد تمامًا على ما تفعله.إن وجود مترجم XSLT على المخرجات يجعل من السهل إنشاء تنسيقات مخرجات بديلة - قابلة للطباعة، للهواتف المحمولة، وما إلى ذلك.

نعم، أستخدمه كثيرًا.باستخدام ملفات xslt مختلفة، يمكنني استخدام نفس مصدر XML لإنشاء ملفات HTML متعددة اللغات (X) (تقديم نفس البيانات بطرق مختلفة)، وخلاصة RSS، وخلاصة Atom، وملف واصف RDF، وجزء من خريطة الموقع .

انها ليست حلا سحريا.هناك أشياء يقوم بها بشكل جيد، وأشياء لا يقوم بها بشكل جيد، ومثل جميع جوانب البرمجة الأخرى، يتعلق الأمر كله باستخدام الأداة المناسبة للوظيفة المناسبة.إنها أداة تستحق أن تمتلكها في صندوق الأدوات الخاص بك ولكن يجب استخدامها فقط عندما يكون ذلك مناسبًا للقيام بذلك.

بالتأكيد أوصي بالتمسك بها.خاصة إذا كنت تستخدم الاستوديو المرئي الذي يحتوي على أدوات التحرير والعرض وتصحيح الأخطاء المضمنة لـ XSLT.

نعم، إنه ألم أثناء التعلم، ولكن معظم الألم يتعلق بالألفة.الألم يتضاءل عندما تتعلم اللغة.

لدى W3schools مقالتان لهما قيمة خاصة:http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

لقد وجدت أن التعامل مع XSLT صعب للغاية.

لقد كانت لدي خبرة في العمل على نظام مشابه إلى حد ما للنظام الذي تصفه.لاحظت شركتي أن البيانات التي كنا نعيدها من "الطبقة الوسطى" كانت بتنسيق XML، وأن الصفحات سيتم عرضها بتنسيق HTML الذي قد يكون أيضًا XHTML، بالإضافة إلى أنهم سمعوا أن XSL كان معيارًا للتحويل بين XML التنسيقات.لذلك قرر "المهندسون المعماريون" (وأعني بذلك الأشخاص الذين يفكرون في أفكار تصميمية عميقة ولكن من الواضح أنهم لا يقومون بالبرمجة أبدًا) قرروا أن الطبقة الأمامية لدينا سيتم تنفيذها عن طريق كتابة نصوص XSLT التي تحول البيانات إلى XHTML للعرض.

تبين أن الاختيار كان كارثيا.يبدو أن لغة XSLT تمثل صعوبة في الكتابة.ولذلك كان من الصعب كتابة جميع صفحاتنا وصيانتها.كان من الأفضل أن نستخدم JSP (كان هذا في Java) أو بعض الأساليب المماثلة التي تستخدم نوعًا واحدًا من العلامات (الأقواس الزاوية) لتنسيق الإخراج (HTML) ونوعًا آخر من العلامات (مثل <%... %>) للبيانات التعريفية.الشيء الأكثر إرباكًا في XSLT هو أنه مكتوب بلغة XML، ويترجم من XML إلى XML...من الصعب جدًا الاحتفاظ بجميع مستندات XML الثلاثة المختلفة في ذهن المرء.

حالتك مختلفة قليلاً:بدلاً من تأليف كل صفحة في XSLT كما فعلت، تحتاج فقط إلى كتابة بت واحد من التعليمات البرمجية في XSLT (الكود المطلوب تحويله من القوالب لعرضه).لكن يبدو أنك واجهت نفس الصعوبة التي واجهتها.أود أن أقول إن محاولة تفسير DSL بسيط يستند إلى XML (لغة خاصة بالمجال) كما تفعل ليست إحدى نقاط القوة في XSLT.(على الرغم من أنه يستطيع القيام بهذه المهمة ...بعد كل شيء، إنه تورينج كامل!)

ومع ذلك، إذا كان ما لديك أبسط:لديك بيانات بتنسيق XML واحد وأردت إجراء تعديلات بسيطة عليها - ليس خط DSL لوصف الصفحة بالكامل، ولكن بعض التعديلات البسيطة والمباشرة، لذا فإن XSLT أداة ممتازة لهذا الغرض.إن طبيعتها التصريحية (وليست الإجرائية) هي في الواقع ميزة لهذا الغرض.

-- مايكل تشيرمسايد

من الصعب التعامل مع XSLT، ولكن بمجرد التغلب عليها سيكون لديك فهم شامل جدًا لـ DOM والمخطط.إذا كنت تستخدم XPath أيضًا، فأنت في طريقك لتعلم البرمجة الوظيفية وسيعرضك هذا لتقنيات وطرق جديدة لحل المشكلات.وفي بعض الحالات، يكون التحول المتتالي أقوى من الحلول الإجرائية.

أستخدم XSLT على نطاق واسع لواجهة أمامية مخصصة بنمط MVC.يتم "تسلسل" النموذج إلى XML (وليس عبر تسلسل XML)، ثم يتم تحويله إلى html عبر xslt.تكمن الميزة على ASP.NET في التكامل الطبيعي مع XPath، ومتطلبات الصياغة الجيدة الأكثر صرامة (من الأسهل بكثير التفكير في بنية المستند في xslt مقارنة بمعظم اللغات الأخرى).

لسوء الحظ، تحتوي اللغة على العديد من القيود (على سبيل المثال، القدرة على تحويل مخرجات تحويل آخر) مما يعني أنه من المحبط أحيانًا العمل بها.

ومع ذلك، فإن الفصل بين الاهتمامات الذي يمكن تحقيقه بسهولة والذي يتم فرضه بقوة والذي يمنحه ليس شيئًا أرى أن تقنية أخرى توفره الآن - لذلك بالنسبة لتحويلات المستندات، لا يزال هذا أمرًا أوصي به.

لقد استخدمت XML وXSD وXSLT في مشروع تكامل بين أنظمة قواعد بيانات غير متشابهة جدًا في وقت ما في عام 2004.كان علي أن أتعلم XSD وXSLT من الصفر ولكن الأمر لم يكن صعبًا.إن الشيء العظيم في هذه الأدوات هو أنها مكنتني من كتابة كود C++ المستقل للبيانات، والاعتماد على XSD وXSLT للتحقق من صحة/التحقق ثم تحويل مستندات XML.قم بتغيير تنسيق البيانات، وقم بتغيير مستندات XSD وXSLT وليس كود C++ الذي يستخدم مكتبات Xerces.

للفائدة:كان حجم XSD الرئيسي 150 كيلو بايت وكان متوسط ​​حجم XSLT أقل من 5 كيلو بايت IIRC.

والفائدة الكبيرة الأخرى هي أن XSD عبارة عن مستند مواصفات يعتمد عليه XSLT.الاثنان يعملان في وئام.والمواصفات نادرة في تطوير البرمجيات هذه الأيام.

على الرغم من أنني لم أواجه الكثير من المتاعب في تعلم الطبيعة التصريحية XSD وXSLT، إلا أنني وجدت أن مبرمجي C/C++ الآخرين واجهوا مشكلة كبيرة في التكيف مع الطريقة التصريحية.عندما رأوا أن الأمر قد انتهى، تمتموا بطريقة إجرائية، الآن بعد أن فهمت!وشرعوا (التورية؟) في كتابة XSLT الإجرائية!الشيء المهم هو أنه عليك أن تتعلم XPath وتفهم محاور XML.يذكرني بمبرمجي لغة C القدامى الذين اعتادوا استخدام OO عند كتابة لغة C++.

لقد استخدمت هذه الأدوات لأنها مكنتني من كتابة قاعدة تعليمات برمجية صغيرة لـ C++ والتي تم عزلها عن جميع تعديلات بنية البيانات باستثناء التعديلات الأساسية وكانت هذه الأخيرة عبارة عن تغييرات في بنية قاعدة البيانات.على الرغم من أنني أفضّل لغة C++‎ على أي لغة أخرى، إلا أنني سأستخدم ما أعتبره مفيدًا لتحقيق جدوى مشروع برمجي على المدى الطويل.

كنت أعتقد أن XSLT كانت فكرة عظيمة.أعني ذلك يكون فكرة رائعة.

حيث فشل هو التنفيذ.

المشكلة التي اكتشفتها مع مرور الوقت هي أن لغات البرمجة في XML مجرد فكرة سيئة.فهو يجعل الأمر برمته غير قابل للاختراق.على وجه التحديد، أعتقد أن لغة XSLT من الصعب جدًا تعلمها وتشفيرها وفهمها.إن XML الموجود أعلى الجوانب الوظيفية يجعل الأمر برمته مربكًا للغاية.لقد حاولت تعلمها حوالي 5 مرات في حياتي المهنية، ولم تنجح.

حسنًا، يمكنك "استخدام الأداة" -- أعتقد أن هذا كان الهدف من تصميمها جزئيًا -- ولكن هذا هو الفشل الثاني:جميع أدوات XSLT الموجودة في السوق هي، بكل بساطة...هراء!

ال مواصفات XSLT يُعرّف XSLT بأنها "لغة لتحويل مستندات XML إلى مستندات XML أخرى".إذا كنت تحاول القيام بأي شيء سوى معالجة البيانات الأساسية ضمن XSLT فمن المحتمل أن تكون هناك حلول أفضل.

تجدر الإشارة أيضًا إلى أنه يمكن توسيع إمكانات معالجة البيانات الخاصة بـ XSLT في .NET باستخدام وظائف الامتداد المخصصة:

أحتفظ بنظام توثيق عبر الإنترنت لشركتي.يقوم الكتّاب بإنشاء الوثائق بلغة SGML (لغة تشبه لغة XML).يتم بعد ذلك دمج SGML مع XSLT وتحويله إلى HTML.

يتيح لنا ذلك إجراء تغييرات بسهولة على تخطيط التوثيق دون الحاجة إلى إجراء أي تعليمات برمجية.إنها مجرد مسألة تغيير XSLT.

هذا يعمل بشكل جيد بالنسبة لنا.في حالتنا، فهي وثيقة للقراءة فقط.لا يتفاعل المستخدم مع الوثائق.

وأيضًا، باستخدام XSLT، فإنك تعمل بشكل أقرب إلى مجال المشكلة (HTML).أنا دائما أعتبر أن هذه فكرة جيدة.

وأخيرًا، إذا كان نظامك الحالي يعمل، فاتركه وشأنه.لن أقترح أبدًا حذف التعليمات البرمجية الموجودة لديك.إذا كنت سأبدأ من الصفر، فسأستخدم XSLT، لكن في حالتك، سأستخدم ما لديك.

يتعلق الأمر بما تحتاجه من أجله.قوتها الرئيسية هي سهولة صيانة التحويل، وكتابة المحلل اللغوي الخاص بك يمحو ذلك بشكل عام.ومع ذلك، في بعض الأحيان يكون النظام صغيرًا وبسيطًا ولا يحتاج حقًا إلى حل "فاخر".طالما أن المنشئ المعتمد على التعليمات البرمجية الخاص بك قابل للاستبدال دون الحاجة إلى تغيير تعليمات برمجية أخرى، فلا مشكلة كبيرة.

أما بالنسبة لقباحة XSL، فنعم إنها قبيحة.نعم، يستغرق الأمر بعض الوقت للتعود عليه.ولكن بمجرد أن تتقن الأمر (لا ينبغي أن يستغرق الأمر وقتًا طويلاً في المنظمة البحرية الدولية)، يصبح الأمر في الواقع إبحارًا سلسًا.تعمل التحويلات المجمعة بسرعة كبيرة حسب تجربتي، ويمكنك بالتأكيد تصحيح الأخطاء فيها.

ما زلت أعتقد أن لغة XSLT يمكن أن تكون مفيدة ولكنها لغة قبيحة ويمكن أن تؤدي إلى فوضى فظيعة غير قابلة للقراءة ولا يمكن الحفاظ عليها.يرجع ذلك جزئيًا إلى أن لغة XML ليست قابلة للقراءة بدرجة كافية من قبل الإنسان لتكوين "لغة" وجزئيًا لأن لغة XSLT عالقة في مكان ما بين كونها تصريحية وإجرائية.بعد قولي هذا، وأعتقد أنه يمكن إجراء مقارنة مع التعبيرات العادية، فإن لها استخداماتها عندما يتعلق الأمر بمشكلات بسيطة محددة جيدًا.

يمكن أن يكون استخدام النهج البديل وتحليل XML في التعليمات البرمجية أمرًا سيئًا بنفس القدر وتريد حقًا استخدام نوع من تكنولوجيا تنظيم/ربط XML (مثل JiBX في Java) التي ستحول XML الخاص بك مباشرة إلى كائن.

إذا كان بإمكانك استخدام XSLT بأسلوب تعريفي (على الرغم من أنني لا أوافق تمامًا على أنها لغة تعريفية) فأعتقد أنها مفيدة ومعبرة.

لقد كتبت تطبيقات ويب تستخدم لغة OO (C# في حالتي) للتعامل مع طبقة البيانات/المعالجة، ولكن يتم إخراج XML بدلاً من HTML.ويمكن بعد ذلك استهلاك هذا مباشرة من قبل العملاء كواجهة برمجة تطبيقات بيانات، أو تقديمه بتنسيق HTML بواسطة XSLTs.نظرًا لأن لغة C# كانت تُخرج لغة XML التي كانت متوافقة من الناحية الهيكلية مع هذا الاستخدام، فقد كان كل شيء سلسًا للغاية، وظل منطق العرض التقديمي تصريحيًا.كان من الأسهل المتابعة والتغيير بدلاً من إرسال العلامات من C#.

ومع ذلك، نظرًا لأنك تحتاج إلى المزيد من منطق المعالجة على مستوى XSLT، يصبح الأمر معقدًا ومطولًا - حتى لو "حصلت" على النمط الوظيفي.

بالطبع، ربما كنت قد كتبت هذه الأيام تطبيقات الويب باستخدام واجهة RESTful - وأعتقد أن "لغات" البيانات مثل JSON تكتسب قوة جذب في المجالات التي تم فيها تحويل XML تقليديًا بواسطة XSLT.لكن في الوقت الحالي لا تزال تقنية XSLT تقنية مهمة ومفيدة.

لقد أمضيت الكثير من الوقت في استخدام XSLT ووجدت أنه على الرغم من كونها أداة مفيدة في بعض المواقف، إلا أنها بالتأكيد ليست حلاً لجميع المشاكل.إنه يعمل بشكل جيد جدًا لأغراض B2B عندما يتم استخدامه لترجمة البيانات لإدخال/إخراج XML القابل للقراءة آليًا.لا أعتقد أنك تسير على المسار الخاطئ في بيانك بشأن حدوده.أحد الأشياء التي أحبطتني أكثر كانت الفروق الدقيقة في تطبيقات XSLT.

ربما يجب عليك إلقاء نظرة على بعض اللغات الترميزية الأخرى المتاحة.أعتقد أن جيف كتب مقالًا حول هذا الموضوع بالذات بخصوص Stack Overflow.

هل HTML لغة ترميزية إنسانية؟

أود أن ألقي نظرة على ما كتبه.ربما يمكنك العثور على حزمة برامج تفعل ما تريده "خارج الصندوق"، أو على الأقل قريب جدًا منه بدلاً من كتابة الأشياء الخاصة بك من الألف إلى الياء.

أنا مكلف حاليًا بجمع البيانات من موقع عام (نعم، أعرف).ولحسن الحظ أنه يتوافق مع xhtml لذا فأنا قادر على استخدام xslt لجمع البيانات التي أحتاجها.الحل الناتج قابل للقراءة ونظيف وسهل التغيير إذا لزم الأمر.ممتاز!

لقد استخدمت XSLT من قبل.كانت مجموعة ملفات .xslt الستة (التي تمت إعادة هيكلتها من ملف واحد كبير) تحتوي على حوالي 2750 سطرًا قبل وقت طويل من إعادة كتابتها بلغة C#.يتكون رمز C# حاليًا من 4000 سطر يحتوي على الكثير من المنطق؛لا أريد حتى أن أفكر في ما قد يتطلبه الأمر للكتابة في XSLT.

النقطة التي استسلمت فيها هي عندما أدركت أن عدم وجود XPATH 2.0 كان يضر بشكل كبير بتقدمي.

للإجابة على أسئلتك الثلاثة:

  1. لقد استخدمت XSLT مرة واحدة منذ بضع سنوات.
  2. أعتقد أن XSLT قد يكون الحل الصحيح في ظروف معينة.(لا تستصعب شئ أبداً)
  3. أميل إلى الاتفاق مع تقييمك بأنه مفيد في الغالب للتحويلات "البسيطة".لكنني أعتقد أنه طالما أنك تفهم لغة XSLT جيدًا، فهناك مبرر لاستخدامها في مهام أكبر مثل نشر موقع ويب بتنسيق XML يتم تحويله إلى HTML.

أعتقد أن السبب وراء عدم إعجاب العديد من المطورين بـ XSLT هو أنهم لا يفهمون النموذج المختلف جذريًا الذي يعتمد عليه.ولكن مع الاهتمام الأخير بالبرمجة الوظيفية، قد نشهد عودة XSLT...

أحد الأماكن التي يتألق فيها xslt حقًا هو إنشاء التقارير.لقد وجدت أن العملية تتكون من خطوتين، حيث تقوم الخطوة الأولى بتصدير بيانات التقرير كملف 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.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top