الفرق بين Apache Tapestry و Apache Wicket

Question

apache wicket ( http://wicket.apache.org/ ) و Apache Tapestry ( http://wicket.apache.org/ ) نكون كلا الإطار الموجود نحو المكونS - على عكس الأطر القائمة على الإجراءات مثل Stripes - من قبل مؤسسة Apache. كلاهما يسمح لك ببناء تطبيقك من المكونات في Java. كلاهما يشبهني جدًا.

ما هي الاختلافات بين هذين الإطارين؟ هل خبرة شخص ما في كليهما؟ خاصة:

• كيف يتم أدائهم ، وكم يمكن تخصيص معالجة الدولة ، هل يمكن استخدامها عديمي الجنسية?
• ما هو الفرق في نموذج المكون الخاص بهم؟
• ما الذي تختاره للتطبيقات؟
• كيف يتكاملون مع Guice ، Spring ، JSR 299؟

يحرر: لقد قرأت الوثائق لكليهما واستخدمت كليهما. لا يمكن الإجابة على الأسئلة بشكل كافٍ من قراءة الوثائق ، ولكن من التجربة من استخدامها لبعض الوقت ، على سبيل المثال كيفية استخدام الويكيت في وضع عديمي الجنسية لمواقع الأداء العالية. شكرًا.

Answer 1

بعض الاختلافات ذات الصلة كما أراها:

• يستخدم Tapestry بنية صفحة شبه ثابتة ، حيث يمكنك العمل مع الشرطية والحلقات لتحقيق سلوك ديناميكي. الويكيت ديناميكي تمامًا ؛ يمكنك تحميل المكونات ديناميكيًا ، واستبدالها في وقت التشغيل ، وما إلى ذلك. عواقب ذلك هي أن النسيج أسهل في التحسين ، وأن الويكيت أكثر مرونة في استخدامه.
• كلا الإطارين فعالان تقريبًا في التنفيذ ، لكن ويكيت يعتمد على تخزين جانب الخادم (افتراضيًا على الصفحة الحالية في الجلسة ، والصفحات السابقة في "ذاكرة التخزين المؤقت للمستوى الثاني" والتي تعتبر ملفًا مؤقتًا في نظام الملفات). إذا كان هذا يزعجك ، فكر في عدد الجلسات المتزامنة التي تتوقع أن يكون لديك في أوقات الذروة وحسابها مع قول 100 كيلو بايت لكل جلسة (والتي ربما تكون على الجانب العالي). هذا يعني أنه يمكنك تشغيل جلسات متزامنة 20 ألفًا تقريبًا لـ 2 جيجابايت. قل 15 كيلو لأنك تحتاج إلى تلك الذاكرة لأشياء أخرى أيضًا. بالطبع ، هناك عيب في تخزين الحالة هو أنه لن يعمل بشكل جيد مع تقارب الجلسة ، لذلك يعد هذا القيد عند استخدام الويكيت. يوفر لك Framework وسيلة لتنفيذ صفحات عديمة الجنسية ، ولكن إذا كنت تقوم بتطوير تطبيقات عديمية تمامًا ، فقد تفكر في إطار مختلف.
• هدف الويكيت هو دعم الكتابة الثابتة إلى أقصى حد ، في حين أن Tapestry هو أكثر حول حفظ خطوط التعليمات البرمجية. لذا ، من المحتمل أن تكون قاعدة الكود الخاصة بك أصغر ، وهي جيدة للصيانة ، ومع الويكيت ، يتم كتابتك كثيرًا بشكل ثابت ، مما يجعل من السهل التنقل باستخدام IDE والتحقق من برنامج التحويل البرمجي ، وهو أمر جيد أيضًا للصيانة. شيء ليقوله لكلا IMHO.

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

Answer 2

مراجعة بعد دراسة النسيج 5.

هدف الويكيت هي محاولة لجعل تطوير الويب يشبه واجهة المستخدم الرسومية لسطح المكتب واحد. تمكنوا من القيام بذلك بشكل جيد على حساب استخدام الذاكرة (httpsession).

هدف النسيج 5 هو جعل مُحسّن جدًا (لمجتمع وحدة المعالجة المركزية والذاكرة) إطار الويب الموجود نحو المكون.

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

• IMHO باستخدام الويكيت هو بعض الشيء حتى تقوم بتحسين/ معلمات تطبيق الويب
• يصعب دراسة IMHO Wicket إذا كان لديك تطبيقات الويب المبرمجة وترغب في التفكير فيما يتعلق بمعالجة الطلب
• نسيج 5 تلقائيًا إعادة تحميل فئات المكونات بمجرد تغييرها. كلا الإطارات علامة إعادة تحميل مكون.
• قوات الويكيت فصل الترميز/ الرمز, ، Tapestry 5 فقط أعطيك هذه القدرة. يمكنك أيضًا استخدام بناء جملة أقل مطولاً في Tapestry 5. كما هو الحال دائمًا ، تتطلب هذه الحرية المزيد من التحذيرات.
• من الأسهل تصحيح قلب Wicket: تعتمد مكونات المستخدم على الميراث بينما تعتمد مكونات مستخدم Tapestry 5 على التعليقات التوضيحية. من الجانب الآخر الذي يمكن أن يجعل التحولات إلى الإصدارات المستقبلية أسهل بالنسبة للنسج ثم للويكيت.

للأسف نسيج 5 تعليمي لا يؤكد أن رمز النسيج مثال مثل "T: Loop Source =" 1..10 "..." يمكن أن يكون ممارسة سيئة. لذلك يجب بذل بعض الجهد في كتابة اتفاقيات استخدام النسيج/ الممارسات الجيدة إذا لم يكن فريقك صغيرًا جدًا.

توصياتي:

• استخدم الويكيت عندما يكون بنية الصفحات الخاصة بك ديناميكية للغاية ويمكنك تحمل تكاليف إنفاق 10-200 كيلو بايت من ذاكرة HTTPSESSERESS لكل مستخدم (هذه أرقام خشنة).
• استخدم Tapestry 5 في الحالات التي تحتاج فيها إلى استخدام أكثر كفاءة للموارد

Answer 3

إليك مقارنة شاملة جدًا من أعمال مطور IBM.

http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html؟ca=drs

تحديث: الرابط ميت ، ولكن يمكنك العثور على الصفحة على http://web.archive.org/web/20131011174338/http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html؟ca=drs

Answer 4

أعتقد أن الويكيت هو إطار أبسط للاستخدام.

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

Answer 5

لا أحب نموذج البرمجة النسيجية وأعرف العديد من المطورين الذين يغادرون نسيجًا بسبب الكثير من التغييرات وعدم التوافق في التطوير. نرى: http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/

Answer 6

الويكيت هو إطار عمل جيد جدا. أفضل من كل ما أعرفه. أنا أستخدمه منذ الإصدار 1.3 وأحصل دائمًا على ما أريد. يمتلك Wicket تكاملًا ممتازًا مع Spring - فقط استخدم التعليق التوضيحي لـ SpringBean في رمزك لضخ أي فول الربيع في فصولك.

Answer 7

محاولة http://incubator.apache.org/click/ . إنه لأمر مدهش إطار عمل جافا. بعض الناس يسمونه "تصنع الصحيح" ؛-)

Answer 8

كما قلت عندما كان 4.1 هو الإصدار المستقر الرسمي:

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

الالتزام باستخدام Tapestry 5 يعني:

يجب أن تصبح ملتزما. تحتاج إلى مواكبة كل التطوير الجديد ، التخلي عن الإصدارات القديمة بأسرع ما يمكن ؛ الحفاظ على إصدارات مستقرة بنفسك.