ما هو أفضل نهج لترحيل CGI إلى إطار العمل؟

Question

لدي تطبيق ويب كبير يعمل بنظام Perl CGI.إنه يعمل بشكل جيد، وهو مكتوب بشكل جيد، ولكن كما كان الحال في الماضي، تم تعريف جميع نصوص html بشكل ثابت في مكالمات CGI، لذلك كما يمكنك أن تتخيل، من الصعب الحفاظ عليها وتحسينها وما إلى ذلك.والآن أود أن أبدأ في إضافة بعض القوالب والتكامل مع إطار العمل (المحفز أو CGI::application).سؤالي هو:شخص ما هنا لديه تجربة من هذا القبيل؟هل هناك أي أشياء يجب أن أنتبه لها؟أدرك أنه مع كلا الإطارين يمكنني تشغيل نصوص CGI الأصلية، لذلك يعد هذا أمرًا جيدًا لأنه يمكنني تشغيل كليهما (كود CGI الأصلي "الإطاري") معًا دون أي صدمة.أي نصائح؟

Answer 1

اكتب الاختبارات أولاً (على سبيل المثال مع Test::WWW::Mechanize).ثم عندما تقوم بتغيير الأشياء، فإنك تعرف دائمًا ما إذا كان هناك شيء ينكسر، وما الذي ينكسر.

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

بشكل عام، اتبع خطوة بخطوة حتى يكون لديك دائمًا تطبيق فعال.

Answer 2

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

Answer 3

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

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

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

Answer 4

إليك كيفية القيام بذلك باستخدام Python بدلاً من Perl، لكن هذا لا يهم:

1. تم فصل HTML و شفرة إلى ملفات متميزةلقد استخدمت أ محرك القالب من أجل هذا.
2. مخلوق المهام من شفرة الذي قدم أ نموذج مع مجموعة من المعلمات.
3. نظمت المهام (الذي أسميته الآراء, ، مستوحاة من جانغو) بطريقة معقولة.(مشاهدات المسؤول، وجهات نظر المستخدم، وما إلى ذلك) الآراء كل يتبع نفس اتفاقية الدعوة!
4. تمت إعادة هيكلة قاعدة البيانات وطلب الأشياء بحيث يمكن لـ الآراء كان تحتوي فقط على عرض رمز محدد (يقرأ:التعامل مع طلبات GET وPOST وما إلى ذلك.ولكن لا شيء على مستوى منخفض!).اعتمد بشكل كبير على المكتبات الموجودة لذلك.

أنا هنا في هذه اللحظة.:-) الخطوة الواضحة التالية هي بالطبع:

• اكتب المرسل التي خرائط عناوين URL لك الآراء.سيؤدي هذا أيضًا إلى عناوين URL أفضل و404 أفضل ومعالجة الأخطاء بالطبع.

Answer 5

أحد الافتراضات التي تضعها الأطر هو أن عناوين URL ترتبط بالكود.على سبيل المثال، في إطار العمل، غالبًا ما ترى ما يلي:

http://app.com/docs/list
http://app.com/docs/view/123

عادةً، على الرغم من أن نصوص CGI القديمة لا تعمل بهذه الطريقة، فمن المرجح أن يكون لديك شيء مثل:

http://app.com/docs.cgi?action=view&id=123

للاستفادة من إطار العمل، قد تحتاج إلى تغيير جميع عناوين URL.ما إذا كان بإمكانك القيام بذلك، وكيفية الحفاظ على عمل الروابط القديمة، قد يشكل جزءًا كبيرًا من قرارك.

توفر الأطر أيضًا دعمًا لنوع من ORM (مخطط الارتباطات الكائنية) الذي يلخص مكالمات قاعدة البيانات ويتيح لك التعامل مع الكائنات فقط.ل Catalyst هذا عادة DBIx::Class.يجب عليك تقييم تكلفة التحول إلى هذا.

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