الضوابط مقابل HTML القياسي
https://stackoverflow.com/questions/22084
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أنا أبدأ في استخدام ASP.NET (C# - أعلم أنه لا يهم بالنسبة لهذا السؤال تحديدًا، ولكن الكشف الكامل وكل ذلك)، وبينما أحب ذلك asp:توفر لي عناصر التحكم ذات النمط الكثير من العمل الشاق في صياغة HTML، وغالبًا ما أشعر بالإحباط بسبب بعض السلوكيات.لقد واجهت واحدة الليلة الماضية أثناء العمل مع الصفحات الرئيسية:لي <asp:BulletedList ID="nav">, ، عند تحويله إلى HTML، أصبح <ul id="ct100_nav">.
هناك مشكلات أخرى - لقد لاحظت أنه عندما تقوم بتعبئة DataGrid تلقائيًا، فإنها تضيف سمات إلى الجدول الناتج لا أريدها بالضرورة هناك.
أعلم أن هناك قدرًا معينًا من "الاتفاقيات المتعلقة بالتكوين" التي يتعين عليك قبولها عندما تعتمد على إطار عمل لتولي بعض واجباتك الشاقة، لكن "الاتفاقيات" في هذه الحالات ليست أي اتفاقيات راسخة بل إضافات غير ضرورية.أنا أعرف لماذا يضيف المعرف البادئة، ولكن يجب أن أكون قادرًا على تعديل وإيقاف أشياء مثل هذه، خاصة وأنني، باعتباري مبشرًا لمعايير الويب، لا أقوم بتكرار معرفات HTML في صفحة واحدة على أي حال.
لذا فإن السؤال هنا موجه لمطوري ASP.NET الأكثر خبرة مني:في تجاربك في تطوير ونشر التطبيقات، كيف يمكنك الاستفادة من هذه الضوابط؟هل تجد نفسك تلجأ مرة أخرى إلى HTML المشفر؟هل تستخدمين الخلطة؟لا أرغب في تصميم HTML الخاص بي حول المراوغات المميزة في عناصر التحكم هذه، ولكن إذا أمكن، أود الاستفادة منها عندما يكون ذلك ممكنًا.
ما هو الصبي أن تفعل؟
المحلول
شخصيا،
أعتقد أن عناصر التحكم القياسية في ASP.NET مناسبة للأشياء الداخلية - فالسرعة والقذرة أمر جيد في هذا السيناريو.لكنني عملت ذات مرة مع مطور ويب كان أيضًا مصممًا ورفض استخدام عناصر تحكم ASP.NET والتعليمات البرمجية بتنسيق HTML فقط وإضافة علامات runat = "server" عند الحاجة.كان هذا بسبب رغبته في معرفة كيفية عرض HTML بالضبط، وفي ذلك الوقت على أي حال، لم تكن بعض عناصر تحكم ASP.NET متوافقة مع المعايير.
أجلس في مكان ما في المنتصف - استخدم HTML حيثما كان ذلك مناسبًا وليس عندما لا يكون ذلك مناسبًا.يمكنك الحصول على أفضل ما في العالمين باستخدام محولات التحكم في CSS
نصائح أخرى
أشعر في الواقع بالارتياح الشديد لرؤية بعض الآراء هنا تتفق مع آرائي:ASP.NET كلغة قالب سيئة للغاية.
أود فقط دحض بعض النقاط الاحترافية المذكورة هنا (بدلة اللهب!):
يذكر ديف وارد تصادمات الهوية - وهذا صحيح، ولكن مدى سوء التعامل معها.كنت أفضّل رؤية العقد المشار إليها بواسطة محددات xpath أو محددات css العميقة بدلاً من جعل المعرف عديم الفائدة بشكل فعال إلا عن طريق التأجيل إلى مكونات ASP.NET الداخلية مثل معرف العميل - فهذا يجعل كتابة CSS وJS أكثر صعوبة بلا جدوى.
يتحدث روب كوبر عن كيف أن عناصر التحكم هي بديل لـ HTML، لذلك كل شيء على ما يرام (إعادة الصياغة، اعذرني يا روب) - حسنًا، هذا ليس جيدًا، لأنهم أخذوا لغة موجودة ومفهومة جيدًا وقالوا "لا، عليك أن تفعل الأشياء بطريقتنا" الآن"، وطريقتهم هي جداً سوء التنفيذ.على سبيل المثالasp:panel يعرض جدولًا في أحد المتصفحات وdiv في متصفح آخر!بدون التوثيق أو التنفيذ، لا يمكن التنبؤ بالترميز الخاص بعنصر التحكم في تسجيل الدخول (والعديد من العناصر الأخرى).كيف ستحصل على مصمم لكتابة CSS مقابل ذلك؟
تكتب Espo عن كيف تمنحك عناصر التحكم فوائد التجريد إذا قام النظام الأساسي بتغيير HTML - حسنًا، من الواضح أن هذا أمر دائري (إنه يتغير فقط لأن النظام الأساسي يتغير، ولن أحتاج إلى ذلك إذا كان لدي HTML الخاص بي هناك بدلاً من ذلك) و في الواقع يخلق مشكلة.إذا كان عنصر التحكم سيتغير مع التحديثات مرة أخرى، فكيف من المفترض أن يتعامل CSS الخاص بي مع ذلك؟
سيقول المدافعون "نعم ولكن يمكنك تغيير هذا في التكوين" أو يتحدثون عن تجاوز عناصر التحكم وعناصر التحكم المخصصة.حسنا لماذا يجب أن أفعل ذلك؟إن حزمة عناصر التحكم سهلة الاستخدام في CSS والتي تهدف إلى إصلاح بعض هذه المشكلات ليست سوى ترميز غير دلالي ولا تعالج مشكلة المعرف.
من المستحيل تنفيذ MVC (المفهوم المجرد، وليس التنفيذ 3.5) خارج الصندوق باستخدام تطبيقات نموذج الويب لأن عناصر التحكم هذه تربط العرض والتحكم بإحكام.يوجد الآن عائق أمام مصمم الويب التقليدي لأنه يتعين عليه المشاركة في التعليمات البرمجية من جانب الخادم لتنفيذ ما كان في السابق المجالات المنفصلة لـ CSS وJS.أنا أتعاطف مع هؤلاء الناس.
أنا أتفق بشدة مع وجهة نظر Kiwi بأن عناصر التحكم تسمح ببعض التطوير السريع جدًا للتطبيقات ذات ملف تعريف معين، وأوافق على أن بعض المبرمجين يجدون HTML غير سارة لأي سبب من الأسباب، علاوة على أن المزايا التي توفرها لك الأجزاء الأخرى من ASP.NET، الأمر الذي يتطلب هذه الضوابط، يمكن يكون يستحق هذا الثمن.
لكن، أنا أشعر بالاستياء من فقدان السيطرة، وأشعر أن نموذج التعامل مع أشياء مثل الفئات والأنماط والبرمجة النصية على Codebehind هو خطوة خاطئة إلى الوراء، وأشعر أيضًا أن هناك نماذج أفضل للقوالب (تنفيذ تنسيقات microformat وXSLT لهذه المنصة) على الرغم من أن استبدال عناصر التحكم بهذه العناصر ليس بالأمر الهين.
أعتقد أن ASP.NET يمكن أن يتعلم الكثير من التكنولوجيا ذات الصلة في LAMP و Rails World، وحتى ذلك الحين آمل أن أعمل مع 3.5 MVC حيثما أستطيع.
(آسف على الإطالة </rant>)
الإجابة المختصرة هي أنه لا يجب عليك أبدًا استخدام asp:...إصدار عنصر تحكم HTML قياسي ما لم يكن لديك سبب وجيه حقًا.
غالبًا ما ينجرف المطورون المبتدئون إلى استخدام عناصر التحكم هذه نظرًا لأنها مشمولة في معظم كتب ASP.NET، لذا يُفترض أنها أفضل.هم ليسوا كذلك.في هذه المرحلة، بعد 8 سنوات من التطوير اليومي لـ ASP.NET، لا يمكنني التفكير إلا في حالتين أو ثلاث حالات يكون من المنطقي فيها استخدام asp:...التحكم في الإدخال عبر HTML قياسي.
أما بالنسبة للمعرفات الموجودة على عناصر تحكم الخادم:يمكنك العثور على المعرف الفعلي الذي سيتم كتابته في المتصفح عن طريق الوصول إلى ClientID.وبهذه الطريقة يمكنك الجمع بين البرمجة النصية من جانب الخادم والعميل دون الحاجة إلى استخدام الكود الثابت _id="ct100_nav"_
أحاول دائمًا استخدام عناصر التحكم المضمنة بدلاً من "اختراق" HTML، لأنه إذا كان هناك تحديث أو بعض التحسين لاحقًا، فستظل جميع التعليمات البرمجية الخاصة بي تعمل بمجرد استبدال إطار العمل ولن أضطر إلى تغيير أي HTML.
أتمنى أن يساعدك هذا
Brian ، نعم!يمكنك التحكم إلى حد كبير في كل السلوك..فكر في إنشاء عناصر تحكم مخصصة (هناك ثلاثة أنواع).لقد قدمت مؤخرًا نظرة عامة عليهم في سؤالي هنا.
أود بقوة أوصي بفحصها، فقد ساعدتني بلا نهاية :)
أنا أيضًا في مغامرتي في ASP.NET وشعرت أيضًا بإحباطات مماثلة.ومع ذلك، سرعان ما تعتاد على ذلك.عليك فقط أن تتذكر، السبب وراء عدم قدرتك على صياغة HTML المملة هو أن عناصر تحكم ASP.NET تقوم بكل ذلك من أجلك.
إلى حد ما، يمكنك التحكم/تعديل هذه الأشياء، حتى لو كان ذلك يعني وراثة التحكم وتعديل مخرجات HTML من هناك.
لقد اضطررت إلى القيام بذلك في الماضي، حيث لم تكن بعض عناصر التحكم تجتاز التحقق من صحة W3C افتراضيًا عن طريق وضع بعض العلامات الإضافية هنا وهناك، لذلك قمت ببساطة بالتجاوز والتحرير حسب الضرورة (إصلاح يستغرق بضع دقائق حرفيًا).
أود أن أقول التعرف على كيفية عمل نظام الضوابط ..ثم اجمع بعضًا منها بنفسك، فقد ساعدني هذا حقًا في التعرف على ما يحدث تحت الغطاء، لذلك إذا واجهت أي مشكلة، لدي فكرة إلى أين أذهب.
يتم عرض HTML مع هذا النوع من المعرفات لأن طريقة ASP.NET الخاصة بها لمنع تضارب المعرفات.كل عنصر تحكم حاوية، مثل الصفحة الرئيسية أو عنصر تحكم المعالج، سوف يلحق "ID_" بالمعرفات الفرعية الخاصة به.
في حالة القائمة النقطية، يوفر ListView حلاً وسطًا جيدًا.لا يزال بإمكانك ربطه بمصدر بيانات، ولكنه يمنحك تحكمًا أكثر صرامة في HTML المعروض.لدى Scott Gu مقدمة رائعة لـ ListView هنا:
إذا كانت بادئة المعرف التي أضافتها ASP.NET تمثل مشكلة بالنسبة لك للوصول إليها لاحقًا باستخدام JS أو شيء من هذا القبيل...لديك جانب خادم خاصية .ClientID.
إذا تمت إضافة الحمل بواسطة ASP.NET، فيجب عليك مراعاة ASP.NET MVC (المعاينة المستمرة) حيث يمكنك التحكم الكامل في HTML المنبعث.
سأنتقل إلى MVC لأنني لا أحب كل هذه العناصر المضافة أيضًا....
أعتقد أن معظم الإجابات هنا تأخذ وجهة نظر المصمم.في مشروع صغير إلى متوسط، قد يبدو الأمر بمثابة عبء إضافي لمزامنة التعليمات البرمجية وCSS/HTML وجعلها متوافقة مع المعايير ونظيفة.طريقة المصمم للقيام بذلك هي التحكم الكامل في HTML المعروض.ولكن هناك العديد من الطرق للحصول على هذا التحكم الكامل في ASP.NET.وبالنسبة لي، فإن وجود HTML المطلوب في ملف aspx/ascx هو الطريقة الأكثر قذارة وغير قابلة للتطوير للقيام بذلك.إذا كنت تريد تصميم عناصر التحكم من خلال CSS، فيمكنك دائمًا تعيين جانب خادم الفئة من خلال خاصية CssClass.إذا كنت تريد الوصول إليها من خلال JS، فيمكنك إرسال JS بالمعرفات الصحيحة من جانب الخادم مرة أخرى.العيب الوحيد الذي يوفره هذا هو أن المطور والمصمم يجب أن يعملوا معًا بشكل وثيق.في أي مشروع كبير هذا أمر لا مفر منه على أي حال.لكن المزايا التي يوفرها ASP.NET تفوق بكثير هذه الصعوبات.ومع ذلك، إذا كنت تريد دعم HTML المتوافق مع المعايير والميزات الأخرى للتحكم في العلامات المعروضة، فيمكنك دائمًا استخدام عناصر تحكم الطرف الثالث.
وكما ذكر Dave Ward بالفعل، "إنها طريقة ASP.NET لمنع تضارب المعرفات."
ومن الأمثلة الجيدة جدًا على ذلك، إذا كنت تحاول وضع عنصر تحكم داخل عنصر تحكم مخصص، فاستخدم عنصر التحكم المخصص هذا في مكرر، بحيث يتم إخراج HTML الخاص بعنصر التحكم المخصص عدة مرات للصفحة.
كما ذكر آخرون، إذا كنت بحاجة إلى الوصول إلى عناصر التحكم في جافا سكريبت، فاستخدم خاصية ClientScript التي ستمنحك الوصول إلى ClientScriptManager وتسجيل البرامج النصية الخاصة بك على الصفحة بهذه الطريقة.تأكد عند كتابة البرامج النصية الخاصة بك لاستخدام خاصية ClientID في عنصر التحكم الذي تحاول الرجوع إليه بدلاً من مجرد كتابة معرف عنصر التحكم.
إذا كنت تريد هذا القدر من التحكم في HTML المعروض، فراجع ASP.NET MVC بدلاً من.
