لماذا لم تشهد XSLT أبدًا شعبية العديد من اللغات الأخرى التي ظهرت أثناء ازدهار الإنترنت؟[مغلق]
https://stackoverflow.com/questions/77342
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
لم يشهد استخدام XSLT (تحويل لغة أوراق أنماط XML) نفس الشعبية التي حققتها العديد من اللغات الأخرى التي ظهرت أثناء ازدهار الإنترنت.أثناء استخدامه، وفي بعض الحالات من قبل شركات كبيرة ناجحة (على سبيل المثال:Blizzard Entertainment)، لم يبدو أنها وصلت إلى الاتجاه السائد على الإطلاق.لماذا تعتقد أن هذا هو؟
المحلول
مشكلة واحدة هي أن XSLT تبدو معقد.يجب أن يكون أي مطور قادرًا على التقاط بنيات اللغة نظرًا لوجود نظائرها في معظم اللغات الأخرى.تكمن المشكلة في أن البنيات والبيانات جميعها تبدو متماثلة تمامًا مما يجعل من الصعب التمييز بين الاثنين مما يجعل قراءة XSLT أكثر صعوبة من اللغات الأخرى.
المشكلة الثانية هي أن استخداماتها محدودة أكثر من اللغات الأخرى.XSLT رائع فيما يفعله؛إجراء تحولات معقدة أو جذرية على XML.ولكنها لا تنطبق على مجموعة واسعة من المشاكل مثل اللغات الأخرى، لذلك لا يتم استخدامها بنفس القدر.
ثالثًا، العديد من لغات البرمجة لديها مكتباتها الخاصة لتحويل XML.في معظم الأوقات عند العمل باستخدام XML، لا يلزم سوى إجراء تغييرات أو عمليات بحث بسيطة.من المحتمل أيضًا أن يتم إنشاء XML أو استهلاكه بواسطة برنامج يكتبه المطور بالفعل بلغة أخرى.تعني هذه العوامل أن استخدام الأدوات المساعدة المضمنة في اللغة يعد أكثر ملاءمة.
والمشكلة الأخرى التي تساهم فيها كل هذه القضايا هي الجمود.أي أن الناس لا يعرفونه، ولا يرون أن لديهم حاجة كبيرة إليه، فيتجنبونه كحل إذا كان هناك خيار آخر.
ما ينتهي بك الأمر هو اللغة التي تعد الخيار الأخير للعديد من المطورين عند إنشاء الحلول.ومن المحتمل أن يتم تجنب XSLT حتى عندما تكون أفضل أداة للمهمة نتيجة لذلك.
نصائح أخرى
تستخدم XSLTs برمجة وظيفية - وهو أمر لا يعتاد عليه معظم المبرمجين (ولهذا السبب يعتبره بعض الأشخاص غير بديهي على ما أعتقد).
في رأيي، أحد أكثر الأشياء المزعجة في XSLT القياسي (أنا أتحدث عن XSLT 1.0 لأن هذا هو الإصدار الوحيد الذي استخدمته) هو أنه يفتقر إلى دعم تحويلات السلسلة وبعض عمليات التلاعب الأساسية بوظائف التاريخ والوقت.
هناك شيء واحد لا أستطيع أن أفهمه أبدًا وهو لماذا تم تصميم وظيفة مثل Translation() وتنفيذها في xpath في حين أن الوظائف الأخرى الأكثر فائدة مثل يستبدل, لخفض, إلى_العلوي, أو - لنكن مجانين - التعبيرات العادية لم تكن كذلك.
تمت معالجة بعض هذه المشكلات على ما أعتقد eXSLT (xslt ممتد؟) للموزعين بخلاف MSXML من Microsoft.أقول أعتقد ذلك لأنني في الواقع لم أستخدمه أبدًا لأنه تم الإعلان عن عدم توافقه مع MSXML.
لا أفهم لماذا تم تصميم XSLT 1.0 وفقًا لهذا المبدأ القائل بأن معالجة "النص" لم تكن ضمن نطاق اللغة عندما يكون من الواضح أنه عندما تقوم بتحويل الملفات، لا يمكنك تجنب مشكلات تحويل السلسلة هذه (على سبيل المثال.:تحويل تاريخ مبطن بشكل غير منتظم معين بالتنسيق الفرنسي إلى التنسيق الأمريكي، 31/1/2008 إلى 2008-01-31) هاه...
كانت مشكلات معالجة النص بشكل عام أساسية جدًا ويمكن معالجتها بسهولة في MSXML من خلال السماح بتوسيع XSL باستخدام وظائف JScript:يمكنك استدعاء وظيفة JScript لإجراء بعض المعالجة تمامًا كما تفعل مع أي قالب XSL، لكنني دائمًا ما وجدت هذا الحل غير أنيق وانتهى بي الأمر بإنشاء مكتبات قوالب XSL الخاصة بي.أولاً لأن طريقة JScript عطلت إمكانية نقل XSL لديك، ثم لأنها أجبرتك على مزج منطق البرمجة الخاص بك:بعض البتات في تعبير XPath/XSLT خالص وبتات أخرى في تدوين DOM/object باستخدام JScript.
يعد عدم وجود متغيرات قابلة للتحديث قيدًا آخر مربكًا جدًا للقادمين الجدد، وبعض الأشخاص لا يتغلبون على هذا ويستمرون في معاناتهم من ذلك.في بعض الحالات البسيطة، يمكن أن يكون لديك حلول بديلة باستخدام مزيج من القوالب المتناظرة والاستدعاءات العودية (على سبيل المثال لتنفيذ عداد متزايد أو متناقص) ولكن دعونا نواجه الأمر، العودية ليست طبيعية.
أعتقد أنني سمعت أن كل هذه القيود قد تمت معالجتها في مواصفات XSLT 2.0، وللأسف قررت MS عدم تنفيذها والترويج لـ XQuery بدلاً من ذلك.وهذا أمر محزن، لماذا لا يتم تنفيذ كل منهما؟أعتقد أن XSLT ستظل لديها فرصة جيدة لتصبح مشهورة مثل CSS بالنسبة لـ HTML.عندما تفكر في الأمر، فإن الجزء الأكثر صعوبة في تعلم XSLT هو XPath، والباقي ليس صعبًا مثل فهم السلوك المتتالي في CSS، وقد أصبح CSS شائعًا جدًا...
لذا، في رأيي، فإن الافتقار إلى كل تلك الأشياء الصغيرة المذكورة هنا والوقت المستغرق لمعالجتها في XSLT 2.0 (مع عدم دعم MS لها على أي حال) هو ما أدى إلى حالة عدم الشعبية هذه.كم أتمنى أن يقرر MS تنفيذه بعد كل شيء ...
لأن معظم تطبيقات XSLT لها بصمة ذاكرة عالية (أفترض أن السبب في ذلك هو تصميم اللغة)، لأن الناس يميلون إلى إساءة استخدام XSLT لجميع أنواع الأشياء التي لم تكن مناسبة لها بشكل خاص والطبيعة التعريفية البحتة لـ XSL مما يجعل أنواع معينة من التحولات صعبة للغاية.
إنه رائع لـ XML، ولكنه ليس رائعًا للترميز النموذجي.فهو يفتقر إلى المفاهيم الأساسية النموذجية (أي المتغيرات القابلة للتغيير) ويجعل ما ينبغي أن يكون بسيطًا معقدًا للغاية (أو مستحيلًا).تنبع معظم مشكلاتها من حقيقة أن لغة XML هي لغة رائعة لتمثيل البيانات ولكنها ليست لغة برمجة رائعة.ومع ذلك، أستخدمه يوميًا وأوصي به عندما يكون ذلك منطقيًا.بالاشتراك مع مساحات الأسماء الخارجية، يمكن جعلها أكثر فائدة (استدعاءات إلى Java، وما إلى ذلك).في النهاية، إنها لغة أخرى يجب تعلمها، ويفضل العديد من المبرمجين الالتزام بشيء اعتادوا عليه أو يشبه شيئًا اعتادوا عليه.
لأنه من الأسهل كتابة وصيانة التعليمات البرمجية التي تستخدم Java وC# وJavaScript وما إلى ذلك.لإلغاء تسلسل دفق XML، وتحويله، وتصدير المخرجات المطلوبة، ولا يوفر XSLT أي ميزة أداء كبيرة.
يجعل XSLT بعض الأمور سهلة، ولكنه يجعل الأمور الأخرى صعبة للغاية.
حسنًا...ربما لأنه من الألم كتابة xslts ...كان علي أن أكتب بضعة xslts منذ بضعة أشهر وكنت أحلم بأقواس مدببة ...
<Really>
<No>
<fun/>
</No>
</Really>
(أعلم أن هذا ليس xslt)
بشكل عام، ستكون الأوقات التي سيُطلب منك فيها تحويل بيانات XML إلى نموذج مختلف من بيانات XML، دون إجراء أي معالجة أخرى لها، محدودة للغاية.عادةً ما يتم استخدام XML كوسيط بين نظامين منفصلين، أحدهما عادةً ما يكون مخصصًا لمعالجة مخرجات الآخر.على هذا النحو، يكون من الأسهل كتابة أحد الأنظمة لمعالجة مخرجات XML للنظام الآخر دون الحاجة إلى الخطوة الإضافية المتمثلة في الاضطرار إلى إجراء نوع ما من التحويل.
XSL هو الاتجاه السائد والمعتمد على نطاق واسع.ما هي اللغات الأخرى التي تقصدها؟XSL ليست لغة برمجة، مجرد لغة التحول, ، لذا فهو محدود النطاق جدًا.
أعتقد أن الأمر يتلخص في أن بناء جملة XML جيد لوصف البيانات، ولكنه ليس بناء جملة رائعًا لما هو في الأساس لغة برمجة (XSLT).
كما ذكرنا سابقًا، فإن XSLT (مثل "الأجزاء الجيدة" من JavaScript) هي لغة برمجة وظيفية.يكره معظم المبرمجين التقليديين حالة انعدام الجنسية هذه.كما أن الكثير من المبرمجين التقليديين يكرهون الأقواس الزاوية.
ولكن الأهم من ذلك هو أن الاستخدام الصحيح لـ XSLT يحل مشكلة إنشاء واجهة المستخدم الرسومية التعريفية ومشكلة ربط البيانات لخادم الويب بطريقة لا تعتمد على النظام الأساسي.ليس لدى البائعين مثل مايكروسوفت أي حافز للاحتفال بهذه القوة "غير المريحة".
ومع ذلك، سأزعم أن Microsoft لديها أفضل دعم XSLT لـ IDE (Visual Studio). فى العالم.
أعتقد أنها حاولت تغطية عدد كبير جدًا من حالات الاستخدام وبالتالي أصبحت لغة تورينج كاملة (أو هكذا سمعت).إذا حاولت القيام بأي تحويل غير تافه، فسينتهي بك الأمر بكتابة حلقات وشروط معقدة...بلغة قبيحة ومطولة، ومن الأفضل القيام بذلك باستخدام GPL.
من وجهة نظري، هذا التعقيد يجعل كتابة التنفيذ الصحيح لـ XSLT أمرًا صعبًا ويحد من الخيارات المتاحة، وبالتالي، الاستخدام على نطاق واسع بين المتسللين الصوتيين الذين غالبًا ما يحبون العبث بكود صغير وفعال، وليس كود المؤسسات.
XSLT قوي جدًا، ولكنه يتطلب طريقة مختلفة للتفكير في المشكلة.كما أنها جعلت الحياة صعبة على نفسها من خلال عدم توفير وظائف بيانات مفيدة في الإصدارات المبكرة.لنأخذ على سبيل المثال طريقة نمط ToUpper()، وعادةً ما تقوم بتنفيذها باستخدام شيء مثل:
<xsl:variable name="lcletters">abcdefghijklmnopqrstuvwxyz</xsl:variable>
<xsl:variable name="ucletters">ABCDEFGHIJKLMNOPQRSTUVWXYZ</xsl:variable>
<xsl:value-of select="translate($toconvert,$lcletters,$ucletters)"/>
ليست أسهل طريقة للترميز!
يعد xslt رائعًا بالنسبة إلى ملفات xml إلى xml، عندما يكون لديك بيانات تم تجاوزها بالفعل وتعريف واضح للمدخلات والمخرجات.استخدامه لأشياء مثل xml2html بالنسبة لي يبدو وكأنه صداع، ومع أي لغة ديناميكية وcss تقريبًا، يكون تنفيذ الإخراج أسهل كثيرًا بأسلوب أنيق.
لقد وجدت أنه أمر رائع بالنسبة لـ "هندسة خدمة الويب المركبة". في بعض الأحيان، يعمل عدد من خدمات الويب معًا للحصول على الناتج النهائي. عندما تحتاج خدمات الويب هذه إلى التواصل فيما بينها عبر XML، يمكن لـ XSLT تحويل رسالة xml من نموذج إلى آخر.
