سؤال

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

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

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

لذا، أعتقد أن سؤالي هو، ما هو الخيار الأفضل، أم أن الأمر مجرد مسألة رأي، وهل يجب أن أتقبله وأستخدم Django إذا حقق ما أريد بأقل قدر من الضجة (أريد المصادقة وواجهة CRUD لـ قاعدة البيانات الخاصة بي)؟لقد جربت Werkzeug وGlashammer والأصدقاء، لكن AuthKit وRepoze أخافتني، بالإضافة إلى عدد الخطوات المتضمنة لإعداد المصادقة الأساسية.لقد ألقيت نظرة على Pylons، ولكن يبدو أن الوثائق غير موجودة، وعند الإشارة إلى ميزات بسيطة مثل المصادقة أو واجهة CRUD، بدا أن صفحات ووثائق wiki المختلفة تتعارض مع بعضها البعض، مع اختراقات مختلفة للإصدارات وما شابه.


بفضل س.لوت للإشارة إلى أنني لم أكن واضحا بما فيه الكفاية.سؤالي هو:أي مما يلي جدير بالاهتمام على المدى الطويل، ولكنه غير مؤلم على المدى القصير (على سبيل المثال، نوع من الحلول الوسطى، أي شخص؟) - تعلم WSGI، أو التزم بإطار عمل "متضمن بالبطاريات"؟إذا كان الخيار الأخير، سأكون ممتنًا لاقتراح حول ما إذا كان ينبغي لي تجربة Django مرة أخرى، أو الالتزام بـ TurboGears 1.x، أو المغامرة في إطار عمل آخر.

لقد قمت أيضًا بتجريب CherryPy، لكن يبدو أنني لم أتمكن من العثور على تطبيق CRUD جيد بما يكفي يمكنني استخدامه واستخدامه على الفور.

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

المحلول

أقترح إلقاء نظرة أخرى على TG2.أعتقد أن الناس فشلوا في ملاحظة بعض الخطوات التي تم إحرازها منذ الإصدار الأخير.بصرف النظر عن مجموعة أدوات WSGI المتزايدة المتاحة، هناك عدد لا بأس به من العناصر الخاصة بـ TG2 التي يجب أخذها في الاعتبار.فيما يلي بعض النقاط البارزة:

نظام إدارة TurboGears - واجهة CRUD هذه لقاعدة البيانات الخاصة بك قابلة للتخصيص بالكامل باستخدام فئة التكوين التعريفي.كما أنه مدمج مع Dojo ليمنحك جداول قابلة للتمرير بشكل لا نهائي.يتم أيضًا التحقق من صحة جانب الخادم تلقائيًا.تستخدم واجهة الإدارة عناوين url RESTful وأفعال HTTP مما يعني أنه سيكون من السهل الاتصال بها برمجيًا باستخدام معايير الصناعة.

CrudRestController/RestController - توفر TurboGears طريقة منظمة للتعامل مع الخدمات في وحدة التحكم الخاصة بك.نوفر لك القدرة على استخدام أفعال HTTP القياسية ببساطة عن طريق توسيع RestController الخاص بنا.يجمع سبروكس باستخدام CrudRestController، ويمكنك وضع الخام في أي مكان في التطبيق الخاص بك باستخدام النماذج المُنشأة تلقائيًا والقابلة للتخصيص بالكامل.يدعم TurboGears الآن أنواع mime كامتدادات للملفات في عنوان url، بحيث يمكنك جعل وحدة التحكم الخاصة بك تعرض .json و.xml بنفس الواجهة التي تستخدمها لتقديم html (إرجاع قاموس من وحدة التحكم)

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

مع الافضل قاعدة بيانات للانترنت, ORM, ، و نظام القالب(s) (اختر ما يناسبك) تحت الغطاء، من السهل معرفة سبب كون TG منطقيًا للأشخاص الذين يرغبون في المضي قدمًا بسرعة، وما زالوا يتمتعون بقابلية التوسع مع نمو موقعهم.

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

نصائح أخرى

المناقشات الدينية بين معسكري جانغو وWSGI

قد يبدو الأمر كما لو كنت في حيرة من أمرك بشأن ماهية WSGI وما هو Django.إن القول بأن Django وWSGI يتنافسان يشبه إلى حد ما القول بأن C وSQL يتنافسان:أنت تقارن التفاح والبرتقال.

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

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

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

بعض التجارب الشخصية:لقد أمضيت سنوات، متقطعة، أعبث مع Twisted/Nevow، وTurboGears، وعدد قليل من أطر عمل الويب الخاصة بـ Python.لم أنتهي من أي شيء مطلقًا لأن كود إطار العمل كان غير مكتمل دائمًا وتتم إعادة كتابته تحتي، وكانت الوثائق في كثير من الأحيان غير موجودة أو خاطئة وكان الدعم الوحيد القابل للتطبيق هو عبر IRC (حيث كنت أحصل في كثير من الأحيان على نصيحة رائعة، ولكنني شعرت أنني كنت أفرض نفسي إذا طلبت ذلك أيضًا) كثير من الأسئلة).

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

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

يبدو أن سؤالك هو "هل يستحق تعلم WSGI والقيام بكل شيء بنفسك،" أو استخدام "إطار عمل مكدس كامل يفعل كل شيء من أجلك."

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

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

لمعالجة مشكلاتك الخاصة:

  • نحن نقدم نظام ترخيص جاهزًا يطابق النظام الذي اعتدت عليه من TG1.
  • نحن نوفر واجهة مبتكرة مثل "Django admin" تسمى tgext.admin، والتي تعمل بشكل رائع مع dojo لجعل واجهة جدول البيانات الرائعة مثل الواجهة الافتراضية.

أود أيضًا أن أتطرق إلى اثنين من الخيارات الأخرى المتوفرة وأن أتحدث قليلاً عن الفوائد.

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

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

  • أبراج تعد Pylons مثل CherryPy إطار عمل ويب بسيطًا رائعًا.على عكس CherryPy، يتم تمكين WSGI من خلال النظام بأكمله ويوفر بعض الإعدادات الافتراضية المعقولة مثل SQLAlchemy وMako التي يمكن أن تساعدك على التوسع بشكل جيد.تتميز المستندات الرسمية الجديدة بجودة أفضل بكثير من مستندات wiki القديمة التي يبدو أنك قد اطلعت عليها.

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

مع CherryPy، لديك حرية الاختيار في كل شيء.(إطار عمل القالب، ORM إذا رغبت في ذلك، الواجهة الخلفية، وما إلى ذلك)

تعلم WSGI

WSGI بسيط بشكل سخيف ..إنها في الأساس وظيفة تبدو ..

def application(environ, start_response) pass

يتم استدعاء الوظيفة عند تلقي طلب HTTP. environ يحتوي على بيانات مختلفة (مثل URI للطلب وما إلى ذلك)، start_response هي وظيفة قابلة للاستدعاء، وتستخدم لتعيين الرؤوس.

القيمة التي تم إرجاعها هي نص الموقع.

تطبيق def (البيئة، start_response):start_response ("200 OK" ، []) return "..."

هذا كل ما في الأمر، حقاً..إنه ليس إطارًا، ولكنه بروتوكول لاستخدام أطر الويب.

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

أي إطار عمل تستخدمه (CherryPy، Django، TurboGears، إلخ) هو في الأساس تفضيل شخصي.العب في كل منها، واعرف ما الذي يعجبك أكثر، ثم استخدمه.يوجد سؤال StackOverflow (مع إجابة رائعة) حول هذا الأمر، "توصية لأطر عمل بايثون المباشرة"

هل قمت بفحص web2py؟بعد تقييم العديد من أطر عمل الويب الخاصة بـ Python مؤخرًا، قررت اعتماد هذا الإطار.تحقق أيضًا من Google App Engine إذا لم تكن قد قمت بذلك بالفعل.

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

من ناحية أخرى، إذا كان لديك الوقت لتعلم مجموعة متنوعة من الأشياء الجديدة التي قد تنطبق في مجالات أخرى وترغب في الحصول على أوسع نطاق للتخصيص، فإن شيئًا مثل Turbogears هو الأفضل.تمنحك Turbogears أقصى قدر من المرونة ولكنك سوف يتعين عليك قضاء الكثير من الوقت في قراءة المستندات الخارجية لأشياء مثل Repoze وSQLAlchemy وGenshi لإنجاز أي شيء مفيد بها.تكون مستندات TG2 أقل تفصيلاً عن عمد من مستندات TG1 في بعض الحالات لأنها تعتبر أن المستندات الخارجية أفضل مما كانت عليه من قبل.ما إذا كان هذا النوع من الأشياء يمثل عقبة أو استثمارًا يعتمد على متطلباتك الخاصة.

من المؤكد أن Django يستحق التعلم، ويبدو أنه يناسب أغراضك.واجهة الإدارة التي تأتي معها سهلة الإعداد والتشغيل، وهي تستخدم المصادقة.

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

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

تبدو الأعمدة أداة رائعة بالنسبة لي:

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

لقد استخدمت CherryPy وTurboGears وألقيت نظرة على العديد من أطر العمل الأخرى ولكن لم يكن أي منها خفيفًا ومنتجًا مثل Pylons.افحص ال العرض التقديمي في جوجل.

أنا من محبي TurboGears، وهذا هو السبب بالضبط:مقايضة لطيفة جدًا بين السيطرة والقيام بالأشياء بشكل صحيح مقابل السيطرة عليها.سهل.

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

كما أوصي بـ TurboGears 2 إذا كان ذلك ممكنًا.عندما يخرج، أعتقد أنه سيكون أفضل بكثير من 1.0 من حيث ما تم اختياره للإعدادات الافتراضية (genshi، pylons، SqlAlchemy)

أود أن أقترح على TurboGears 2.لقد قاموا بعمل رائع في دمج أفضل ما في عالم بايثون.

WSGI: بافتراض أنك تقوم بتطوير مشاريع/حلول أعمال معقدة إلى حد ما في TG2 أو أي إطار عمل آخر مثل Grok.على الرغم من أن هذه الأطر تدعم WSGI، فهل هذا يعني أن الشخص الذي يستخدم هذه الأطر يجب أن يتعلم WSGI؟في معظم الحالات الجواب هو لا.أعني أنه من الجيد أن يكون لديك هذه المعرفة بلا شك.

ربما تكون معرفة WSGI أكثر فائدة في حالات مثل

  • تريد استخدام بعض البرامج الوسيطة أو بعض المكونات الأخرى التي لم يتم توفيرها كجزء من المكدس القياسي على سبيل المثال.Authkit مع TG أو جروك بدون ZODB.
  • أنت تقوم ببعض التكامل.

CherryPy يعد أمرًا جيدًا ولكن فكر في التعامل مع عمليات الالتزام/التراجع في قاعدة البيانات الخاصة بك في نهاية المعاملات، وكشف json، وعمليات التحقق من الصحة في مثل هذه الحالات، فإن أطر عمل TG وDjango تفعل كل ذلك من أجلك.

Web2py هي الصلصة السرية هنا.لا تفوت التحقق من ذلك.

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