يجب استخدام Vaadin إطار [مغلقة]
https://stackoverflow.com/questions/1183801
-
19-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أنا فقط حاولت أن تلعب مع Vaadin إطار ويبدو لي من السهل جدا للاستخدام.بالإضافة إلى ما أحب حول الإطار هو أنها بنيت على أعلى من Google Web Toolkit (GWT).
ما رأيك ، هل يجب الاستمرار في استخدام هذا الإطار أو أنه من الأفضل أن العصا مع GWT?
المحلول
مرحبا.كما إخلاء أنا أعمل في شركة تطوير Vaadin.
Vaadin يستخدم GWT في الطريقة التي لديها مجموعة من المكونات المترجمة مسبقا في GWT.يمكنك, بالطبع, بالإضافة إلى ذلك جعل بنفسك المكونات إذا كنت تريد ذلك.ومع ذلك ، فإن مجموعة من المكونات كاملة تماما ، وغالبا ما تكون مخصصة للحاجة الخاصة بك.وهذا يعني أن ليس لديك إلى إعادة ترجمة التعليمات البرمجية الخاصة بك من جافا سكريبت في كل مرة يمكنك تغيير التطبيق الخاص بك.كنت مجرد الجمع بين ما هو متاح بالفعل المكونات معا.
الإطار هو الخادم مدفوعة, لذلك كل منطق التعامل معها على جانب الملقم.مكونات جزأين الخادم والعميل الملف.جانب العميل هو مجرد دمية "عرض" المكون.بمجرد التفاعل مع ذلك ، فإنه يرسل رسالة إلى الخادم أن هذا أو ذاك تم الضغط/كتب/الخ.الملقم ثم يقرر ما ينبغي القيام به.هذا هو من أجل زيادة الأمن ، لأنك لا يمكن أن "الاختراق" منطق صغير فقط كما API يعني لإرسال الطلبات هو متاح في جافا سكريبت.قد يكون هذا في بعض الحالات قليلا مفاضلة مع سرعة التطبيق ، ولكن لا أعتقد أنها سيئة للغاية.أسوأ مطبات عادة db الاستعلام المستديرة مثل هذه الرحلات التي لا يكون لها أي علاقة مع اختيار واجهة المستخدم الإطار.تباطؤ العروض المقترحة يمكن لأنك بعيد عن الخادم أو هناك ارتفاع ضرب المستخدم في هذه اللحظة.حاول في بيئة الخاصة ، إغلاق التطبيق النهائي من التطبيق الخاص بك ، انظر جيدا كيف ينفذ.هناك بعض مستعد التطبيق أنه يمكنك فقط نشر لاختبار بها.
أعتقد خيار يتلخص في ما كنت تحاول القيام به.Vaadin جيدة لتطبيقات الويب ، يمكنك بناء طبيعية تطبيق جافا و لا الديناميكية على شبكة الإنترنت واجهة المستخدم بسهولة.إذا كان الخاص بك تفعل شيئا أكثر من التقليدية على الويب ، حيث المستخدمين فقط آراء الصفحة - أكثر من بنشاط يتفاعل معها ، ثم Vaadin هو أفضل وسيلة للذهاب.الذهاب مع بعض مجانية أخرى أطر مثل القضبان أو إطار php الخ.أعتقد أنك أكثر يقوم التطبيق كما كنت أقترح عليك أن تستخدم GWT الآن لذا Vaadin يجب أن تكون جيدة.
طرح المزيد من الأسئلة ، هنا ، على Vaadin المنتديات أو في irc قناة #vaadin @freenode و ربما شخص ما يمكن أن تعطيك المزيد من الأسباب لماذا أو لماذا لا تستخدم Vaadin.
نصائح أخرى
بعد ما يقرب من 1.5 سنة النامية ليست ضخمة جدا GWT التطبيق ، وذلك باستخدام أفضل الممارسات تعلمت من الماضي Google I/O مثل MVP ، EventBus ، CommandPattern ، إلخ.أقول هذا من أعماق قلبي:بعد قضاء أيام في محاولة للحصول على عمل الأشياء بالطريقة التي زملائي في الفريق و يريد العميل سواء من الناحية الفنية والبصرية ، حتى بعد الإفراج عن UiBinder, Vaadin جاء لي مثل الضوء في نهاية النفق.
بعد كتابة ما يقرب من ألف النمطي الإجراءات الأوامر نمط آخر ألف العروض وآراء أخرى ألف معالجات الأحداث ، الخ..عدم الاضطرار إلى التعامل مع ما يقرب من 75% من هذه الفئات و لا يزال الحفاظ على نمط جيد النهج (appfoundation add-on), القليل من شبكة علوية مقبول.مع Vaadin خارج منطقة الجزاء ، تحصل جيدة الحاجيات ، الترحيل ربط البيانات, تصميم لا تشوبه شائبة.كل هذا من أجل ماذا ؟ المزيد من استهلاك الذاكرة في جانب الخادم.
أعتقد أنني يمكن أن أقول هذا غير مقبول لأنني لست المبنى التالي Facebook أو شيء من هذا.أنا لا تزال لا يمكن التعامل مع الآلاف من المستخدمين في وقت واحد في المتوسطة server و لكن الحفاظ على انخفاض الكمون ذهابا وإيابا.
مع Vaadin أستطيع بناء التطبيق لطيف مع ما يقرب من نصف من الأسطر من التعليمات البرمجية و لا يزال التطبيق يبدو أكثر اكتمالا.:-)
!!تحديث فبراير 23, 2011:لا أستطيع أن أؤكد كيف ينبغي للمرء أن يكون على بينة من كل إطار القيود.Vaadin لا يختلف.ينبغي للمرء أن يكون على علم بأن Vaadin ملخصات بعيدا من أي شكل HTML أو جافا سكريبت.أيضا, مما أدى HTML هو ثقيل جدا و يجب أن تأخذ الرعاية من تاريخ الدولة التغييرات نفسك.هكذا, يكون على بينة من تلك النفقات العامة عند إنشاء المشروع الخاص بك.
تنصل: أنا تابع مع أي من المكتبات المذكورة فيما بعد ولكنه يحدث لمعرفة طريقي من حولهم جيدا.
مثلك، تعثرت عند هذا المنصب عند التفكير في أي مكدس / إطار لاستخدامه لمشروع جديد. كان لدي بعض الخبرة الصلبة مع اللعب! (موافق، في Scala، ولكن هذا غير مناسب هنا) ولكن الأدوات الحاجيات المقنعة وتكاملها غير الملحومة مع جانب الخادم + الأرجوحة مثل التطوير قام بيكير اهتمامي. كان ذلك في أواخر عام 2010، وكما أقنعني الإجابات بإعطاء فايدين جربا، قررت أن أعود وأكتب الإجابة التي كنت سأرغب في قراءتها هنا، ESP. كما لا يزال السؤال وثيق الصلة اليوم. وفي الوقت نفسه، ذهب فاادين من الإصدار 6 إلى 7 مع بعض التحسينات البارزة التي كانت هناك حاجة، العب! ذهبت من الإصدار 1 إلى 2 و I (+ فريق صغير) أكمل عددا صغيرا من المشاريع الناجحة بكل كلا الأطر.
أعتقد أن المقارنة مثيرة للاهتمام لأن كلا الأطر
- تشغيل على JVM ويمكن الاستفادة من النظام البيئي الوفير
- لا يمكن أن يكون أكثر اعتزازا في نهجها في تطبيقات الويب وماذا، كما يجب أن يهتم المطور، و
- إلى حد أقل، كيف تتعلق ب Java EE.
مدح
في جملة واحدة، إذا وجدت فكرة نقل تطبيق سطح المكتب إلى متصفح بينما يتم تجريده بالكامل من آلية طلب HTTP / الاستجابة الأساسية، فمن المحتمل أن Vaadin هو المرشح الخاص بك لصنع تطبيق الويب. يمكن أن يكون التأرجح مثل نهج البرمجة نسيما لأولئك الذين يسعدون بعيدا عن أدنى مستوى من HTML و JavaScript. يتم بالفعل بدء طلب جديد إلى تطبيقك مثيل جديد وبقية التدفق متروك لك ولمنطقك. الروابط الرجوع إلى الأزرار القديمة الجيدة للملاحة وأنت حر في إنشاء تخطيطاتك باستخدام العديد من القوالب المضمنة دون أن تكون هناك حاجة إلى قرص HTML أو CSS. واجهة برمجة التطبيقات هي عموما متسقة للغاية ومؤكفة موثقة جيدا ( كتاب فاادين هو قراءة إلزامية. تفعل ذلك تماما كما تتوفر العديد من الأشياء بسهولة، على سبيل المثال. ملزمة حبوبك إلى المكونات والمصادف، ...). تحتوي هذه الحاجيات على توافق كبير للمتصفح الشامل، وبالتالي ضمان سلوك متسق من طلبك على مجموعة واسعة من العملاء.
التحقق من الواقع
قضينا وقتا سعيدا في تطوير واختبار تطبيقات Vaadin الخاصة بنا. أصبحت الأمور أكثر وضوحا وأكثر إغاظة عندما أصدرنا الإصدار الأول وبدأ في جمع الملاحظات. أدركنا ذلك كان لدينا بالفعل منحازة في بعض الطرق الأساسية, ، يسمى:
في عام 201X، كان لدى معظم المستخدمين تاريخا طويلا لاستخدام الويب، وعدد قليل منهم بالكاد يستخدمون تطبيقات سطح المكتب بعد الآن. نقطة المفتاح هنا هو ذلك توحيد المتصفحات تفاعل UX مع روابط النص التشعبي، وظهر إلى الأمام، زر إعادة التحميل، علامات التبويب في كل مكان، وأحيانا، والفكرة الأساسية أن معظم الإجراءات تؤدي إلى طلب HTTP وسوف تنتظر استجابة. وبعد هذا هو العقد الضمني الذي تلتزم المواقع الإلكترونية وحولها والتي بنيتها. لذلك، يجب ألا نتفاجأ عندما اشتكى المستخدمون من أنهم لم يستطعوا استخدام الأزرار الخلفية / الأمام لأنها كانت تستخدم، أو أن علامات التبويب لم تنجح بالطريقة المتوقعة. واتفقنا. لقد كسرنا العقد غير المرئي يرتدون المستخدمين والمتصفحات. في الواقع، نحن أنفسنا بشكل ضمني عدم استخدام متصفحنا مع تطبيق Vaadin بالطريقة التي استخدمناها مع أي موقع ويب آخر. بالطبع، قد تعود إلى الكتاب المذكور وقرأنا بعناية على تكرار تجربة ملاحة ويب مع شظايا URL وسترى أنها تشارك في الواقع أكثر مما كان متوقعا لأن تطبيقات Vaadin هي دعوة. وبعد علاوة على ذلك، فإن النماذج MVC أو MVP تفرض فقط على المطور، على النقيض من اللعب! حيث لا يوجد خيار آخر تقريبا. لا تأخذ هذا طفيفة ولكن يتم استخدام عقلك على شاشة بيضاء مشرقة موضحة لجزء بسيط من الثانية بعد تغيير الصفحة. عند النقر فوق المستخدمون ونتوقع أن يؤخذوا صفحة جديدة، يعترف المتصفح بإظهار الساعة الرملية (أو الاختلافات منه). مع AJAX، يتم وضع الطلبات وراء الكواليس. هناك أماكن اليوم التي أصبحت فيها ضربات أجاكس صغيرة تقريبا هي القاعدة، ولكن ليس لتحديثات UI الرئيسية بعد.
التطبيقات الدائنة تجلب حصتها من التحديات ... والمتاعب. تحميل موازنة (إذا كنت مهتما) لأحد أكثر تعقيدا. مفهوم المعاملة يختلف تماما حيث تمتد جلسات Vaadin العديد من الطلبات، وبالتالي فهي طويلة على النقيض من الراحة مقرها، لكنها قصيرة نسبيا عاش من حيث UX. في الواقع، ليس من غير المألوف أن يعود المستخدمون إلى نموذج بدأوا منذ ساعات لإنهاء مهمتهم. يمكن ذلك، من الناحية النظرية، من الناحية النظرية، مع Vaadin أيضا، لكنك يتعين عليك الحفاظ على جلسات حية لفترة طويلة طويلة مع الذاكرة المحظورة طوال الوقت والتفكير بعناية في حالة جيدة، من شأنها أن تدرج المستخدمين المتزامنين.
الصفحات الدائنة أصعب أيضا للمستخدمين المشاركة، ناهيك عن الإشارة المرجعية (التي تتحمل أنك تعاملت مع شظايا URL).
أخيرا، نشارك الانطباع بأن واجهة المستخدم هي عموما أكثر بطيئة مع وجود المنطق على الخادم. بالطبع، قد تقوم دائما بإنشاء عنصر واجهة مستخدم محملة بجانفاسكريبت من جانب العميل لتقليم عدد الرحلات الدائرية ولكنك ستضطر حتما إلى إجراء بعض تحديثات واجهة المستخدم على الخادم. JS هو بالفعل ثقيل جدا للتفسير في تجربتي ويجعل تجربة أقل على الأجهزة المحمولة (أنا أدرك لوحة Touchkit، ولكن لا يزال: تطبيقات HTML5 على الأجهزة المحمولة فقط لا تقطعها بالنسبة لي). أيضا، ضع في اعتبارك أن مؤشر ترابط UI نشط بعد أن يتم نشر طلب (أي عمل المستخدم على جانب العميل، على غرار سحب تحديثات UI) وسيتم الوصول إليك من خلال مستمعين مختلفين. ومع ذلك، فإن تحديث UI من خيوط الخلفية أكثر تعقيدا (على سبيل المثال. دفع التحديثات). تحسين Vaadin 7 الوضع في هذا الصدد، خاصة مع نسبيا أخف وزنا html الناتج. كانت تحسينات كبيرة على تفاعل UI ملحوظا ببساطة عن طريق تشغيل ضغط HTTP.
خاتمة
لذلك توقفنا وتساءلت عما وجدناه جذابا للغاية في نهج فايدين للبدء. كانت التنمية الأولي هي ركوب سلس نسبيا مما يؤدي إلى نتائج سريعة ولكن إعادة صياغة بعض المفاهيم لاستيعاب توقعات الويب UX أعطانا انطباعا قويا بالسباحة ضد المد. خلصنا إلى أن فكرة الإغواء المتمثلة في مجردة (غامضة؟) من آلية طلب HTTP / الاستجابة أثبت سيف ذو حدين مزدوج كشف النقاب عن عدم تطابق المعاوقة الحقيقي بين تطبيقات الويب وتطبيقات سطح المكتب.
بدلا من التظاهر بأن الويب هو طبقة أخرى، شعرنا بشدة أن المرء يجب أن يحتضن الطريقة التي يعمل بها وهذا يبدأ بوجود تطبيق مركز URL (كما فرضه القضبان / django / اللعب). ربما سمعت شخصا ما يقول أن البيانات توضح التطبيق. تتم الإشارة إلى البيانات في الوقت الحاضر عن طريق موارد URL، لذلك يمكن للمرء أن يقول بأمان أن عناوين URL تنفذ البيانات. بعد كل شيء، هم ما المرجعين الناس، أليس كذلك؟ لذلك يجب تطبيق الفصل الأساسي للمخاوف أيضا على هذا المستوى. ربما هذا هو السبب في أن الشبكة أصبحت تحظى بشعبية كبيرة في المقام الأول. لذلك أعيد النظر في تطبيقنا على هيكله أكثر حول وحدة تحكم مركزي يستجيب للإجراءات انا لا تلعب مصنوعة على مسارات موارد متميزة.
في الوقت الحالي، نحافظ على تطبيقات Vaadin الخاصة بنا ولكن نظرا لبعض هذه القيود وتحول النموذج الأساسي لن نبدأ مشاريع جديدة معها. ومع ذلك، قم بإيقاف تشغيله إلى الفريق الذي بنى متماسكا من الناحية الفنية، متماسكا ومواسقا وموثقا جيدا على الويب 360 درجة جافا يتطلب معرفة القليل جدا من أعمال الويب الداخلية. على الجانب الاتجاه الصعودي حتى يدعم إطارهم مع شركة بيع الخدمات الاستشارية. أنا ممتن للتجربة وكيف جعلني أعيد إعادة تقييم وجهات نظري على تطبيقات الويب. سأراقب عن كثب تطورها لكننا بالتأكيد نحتاج إلى مزيد من السيطرة والتحبيب.
نأمل في يوم واحد، سيقوم Vaadin بحفظ نفسه من بنية Servlet بأكملها التي تعتمد عليها من خلال خادم HTTP الخاص به. ما زلت أفضل سيكون تصميم MVC مجذور عميق في الإطار. ولكن هذا غير مرجح إلى حد ما في المستقبل المنظور حيث يبدو أنه قد وجد مكانة مربحة بين جافا غوريلا من الشركات المحنك التي أقسمها فقط من قبل ه. تألق.
TL؛ دكتور: أعتقد أن فاادين يفتقد أن نقطة ما هي WebApps والأهم من ذلك، وكيف ينبغي أن تتصرف. لقد اعتنق المبرمجين الوقت على الويب وكيف تتفاعل المستخدمون معها (أي زر مرة أخرى أو زر إعادة تحميل وعلامات التبويب والإشارات). تقريب تطبيق تطبيق ويب لطلبات وثلاثي HTTP (الأفعال)، والأرجح أكثر احتمالا لتتناسب مع توقعات المستخدم. وهذا هو المفتاح.
تعديل: إذا كان لديك أي تجربة بيثون، فسوف أوصي بشدة بمحاولة القارورة أيضا للحصول على نكهة من برمجة تطبيقات الويب المتمركدة على عنوان URL
تحرير 2.: إذا شعرت بأي سبب من الأسباب، فيجب عليك استخدام إطار كومة مكدس يشبه VAADIN، ثم أعط النيزك. إنه إطار عمل جافا سكريبت (كل من الطرفين المفرد والظهر) الذي يعمل على node.js بالاتصال غير المتزامن الذي يحدث من خلال Websocket (وبالتالي زينة أصغر من الطلب / الاستجابة) وهو رد فعل افتراضي. تم تناول عدد من الأشياء التي لا أحبها في فايدين في نيزك. على سبيل المثال، يعمل المنطق الخاص بتحديثات UI على العميل الذي يجعله أكثر استجابة بكثير مما كانت عليه في Vaadin. لا تتقاطع الأشخاص في مجتمعات جافا سكريبت وجافا كثيرا ولكن عندما سمعت به لأول مرة، أدلىني بالتوازي مع فايدين على الفور. يتمتع حاليا بقليل من الزخم في المجتمع لأسباب تشبه تلك التي جعلت Vaadin شعبية، أي. القدرة على جعل تطبيقات الويب التي تشبه سطح المكتب. أعطها جربا إذا كنت قد أدركت أيضا أن Java لا ينتمي إلى الكثير في صورة تطبيقات الويب المستقبلية أو إذا كنت تعبت من تلك الدورات المنتشرة الطويلة عند ضرب التحديث هو كل ما يجب أن يستغرقه كل شيء. لكن فكر مرتين قبل ربط تطبيق كامل إلى مكتبة واحدة فقط.
يتعلق الحديث المعتاد حول Vaadin بمجموعة القطعة والمخاوف بشأن اتصال الرحلة ذهابا وإيابا بين العميل والخادم.
ولكن في رأيي يطل هذا الجانب الأكثر أهمية (ربما ثورية) من Vaadin: إنه يلغي تماما مهمة تصميم وتنفيذ اتصال خادم العميل الذي هو مطلوب عادة لتطبيقات AJAX ("A" و "x" في AJAX) وبعد
مع Vaadin، يمكنك أن تنسى تماما DTO (كائنات نقل البيانات)، ومشاكل الأمن المستندة إلى البروتوكول، استثناءات التحميل كسول السبات، إلخ.
أنت في بعض المعلور فقط كتابة تطبيق سطح مكتب جافا سوينغ العادي، فقط تستخدم مجموعة أدوات UI مختلفة من الأرجوحة.
من تجربتي، تتطلب GWT الكثير من رمز الغزل والبطيء عند التعرف على المبنى وغني. عادة ما نتعامل مع نماذج تطبيق معقدة للغاية تحمل العديد من كائنات المجال المستمرة. لجلب كل البيانات إلى العميل، ستحتاج إلى إدخال نموذج عميل منفصل وتوفير آلية تحويل البيانات. لقد استخدمنا Dezer لهذا الغرض، ويستغرق الأمر الكثير من الوقت لتعيين كل قدمت، وإنشاء محولات مخصصة واختبار كل هذه الأشياء.
من ناحية أخرى، إذا لم تسقط في المناطق الرضيعة، وإذا كان التطبيق غير معقد للغاية، فقد يستغرق الأمر فائدة من استخدام موارد العميل وتحمل حمولة أقل عند الخادم. بهذه الطريقة، قد تقلل من التواصل بشكل كبير مع الخادم واحصل على برنامج أكثر استجابة.
يبدو Vadin مطورا جدا صلى الله عليه وسلم :) لكنني خائف قليلا من "هجوم أجاكس ضخمة" على الخادم. لدي خبرة في ZK وواجهنا في كثير من الأحيان مشاكل الأداء عندما تعمل عملية تافهة على UI بطيئة لأنها تتطلب التواصل مع الخادم.
Wicket هو إطار جيد آخر ولكنه أكثر ملاءمة لمواقع الويب. يمكن أن تعمل مع وبدون ajax، يمكن فهرسة بواسطة محركات البحث. والشيء الأكثر جاذبية يتعامل مع كود HTML النظيف - لا توجد علامات مخصصة، لا توجد هياكل تحكم، فصل صارم للمخاوف وغير المحددة Namigigs فقط عن المكونات.
معظمها يعتمد على احتياجاتك:
- إذا كنت بحاجة إلى تطبيق سريع للغاية وبسيط - استخدم GWT واستخدام موارد العميل
- إذا كان طلبك معقد تماما من Vaadin يبدو أنه أفضل خيار
- إذا كان التطبيق الخاص بك عاما وتحتاج إلى قدرة على فهرسها لسيو من اختيار النصيبات.
الشيء هو، من أجل التنمية الجادة، لا يمكنك أن تنسى أي شيء، ناهيك عن DTOS .. أنا خندق التماس، ومفهوم خادم جانب الخادم فقط لأنني أتمنى السيطرة الدقيقة على ما يجري على السلك .. مشكلة فايدين لي هو بالضبط، وجود حالة على جانب الخادم ..
كانت هناك "مخاوف" حول النصيبات باستخدام جلسات لإدارة دول المكونات وقابلية التوسع مماثلة للحجج حول معالجة VAADIN وخادم الجانب. لقد تعلمت خلال السنوات العشر الماضية أن مجتمع Java عادة ما يكون مخطئ حول كيفية قياس إمكانات إطار الويب (من بين أمور أخرى). من JSF إلى الشاحنات، عادة ما يستغرق بضع مئات من جيجابايت من الذاكرة وعشرات من ملفات جرة مفتوحة المصدر على الأقل مع وظائف متداخلة وغير فعالة للحصول على تطبيق الإنتاج قيد التشغيل. انظر حولك وسترى معظم شركات استضافة الويب لا تقدم خيار جافا عمليا بسبب اتخاذ تقنيات Java غير الرسمية لأطر الويب. لا يزال GWT 2.1 آلام لاستخدامها بسبب سرعة الترجمة، وهي مجرد جادة مع MVP وجداول البيانات التي يجب أن تكون هناك من البداية. أحب النصيبيت، لكن فايدين يبدو واعدا ... لكن معرفة كيف تذهب أطر جافا، أنا متأكد من أنهم سوف يطلقون النار في القدمين في مرحلة ما، لكنني أشك في أنه سيكون بسبب معالجة جانب الخادم الثقيل.
لبناء واجهة مستخدم جيدة، أود أن أقول أن هذه هي الطريقة للذهاب. بالإضافة إلى أنها موثقة جيدا جدا.
لقد كنت أستخدمها لبضعة أسابيع وأنا حقا مثل ذلك حتى الآن. الرمز هو الصلبة، مستندات إعادة جيدة، بناء منطقي للغاية، النتائج النهائية ممتازة.
أنا أحب ذلك بالاشتراك مع السبات لفرز جميع قاعدة البيانات tedium.
بالإضافة إلى ذلك - من السهل النشر (مع Tomcat، يمكنك فقط تحميل ملف .war واحد عبر واجهة الويب، لا يمكن أن يكون أسهل)
انها أيضا تستحق النظر اباتشي النصيب كديل قوي لأطر Java Web UI الموجهة نحو المكونات. Vaadin يبدو رائعا ولا أريد أن ينتقص من هذه المناقشة، لكن الاختيار هو شيء جيد. هناك عدد قليل من الأمثلة مع المصدر المرتبط بالصفحة الرئيسية، وحتى أكثر في موقع Wicketstuff، والكتاب الممتاز من Manning يشكل وثائق جهة خارجية رائعة.
ألق نظرة على Vaadin Demo Build with Maven:http://asolntsev.blogspot.com/2009/11/vaadin-demo.html.
أعتقد أن الويكيت كان الطريق إلى الأمام، حتى حاولت أن أجعله يعمل بكفاءة وبدأ الاكتئاب (نكتة). ثم، لقد تحولت إلى GWT، والتي تبدو رائعة، ولكن هناك الكثير من رمز لوحة المرجل لكتابة الكثير والوثائق ليست كبيرة ... -> جاء الضوء من فايدين: بسيطة، تشغيلية، لا البق حتى الآن ... !!!
في شركتنا التي هي في الغالب منزل Java SW كبير (من بين أمور أخرى)، جاءنا فرصة لنا فرصة لإنشاء منتج جديد على الويب. كانت مجموعة من المنتجات وهناك العديد من الفرق في ثلاث دول تنمية هذا. عندما يتعلق الأمر بفريقنا، كان لدي اختيار باستخدام Vaadin لصالح الاستفادة من تجربة تطوير Java لدينا. بحثت Google لمساعدتي في قراري. أنا أيضا قراءة هذا المنصب؛ ومع ذلك اخترت ضد استخدام Vaadin على الرغم من اختلاف العديد من الفرق الأخرى فادين. فيما يلي أسباب البريد الذي أرسلته في ذلك الوقت قبل البدء في المنتج (إلى VAADIN أو لا). هذا من وجهة نظري الشخصية وعدم ثقة الأطر بشكل عام هو دائما في درجات متفاوتة. لذلك أردت فقط أن تعطي آخر تأخذ على هذا السؤال للقارئ.
حسنا، لقد ذهبنا في التعلم Spree تعلم HTML، CSS، CSS محددات، لغة رائعة JavaScript و JS Libs، JQuery و Yui وخلق منتج الويب في الوقت المناسب مع واجهة المستخدم الرسومية الكاملة والامتثال للأداء؛ وأنا شخصيا أنا سعيد والفريق كذلك وكذلك المستخدمين.
أنشأت الفرق الأخرى التي ذهبت إلى طريقة فايدين منتجاتها في الوقت المناسب وأعتقد أنها سعيدة بنفس القدر. (فقط لا يعرفون فرحة جافا سكريبت فهي مفقودة :)).
وكما قال أحدهم، فإن كل التجريدات هي تجريدات متسربة وعندما اضطروا إلى الهجرة من فاادين 6 إلى فاادين 7 كانوا يتعين عليهم فعل بعض إعادة العمل واتخذوا المزيد من الوقت أكثر من أي شخص يفكر؛ على الرغم من بالطبع تمكنوا من طحن وفمعها؛ لا يزال هناك القليل من التأخير بسبب هذا. كما أعتقد أن هناك بعض المشاكل مع Addon Invientcharts التي لم تكن داعمة Vaadin 7 التي تسببت في شراء الفرق ($$) الرسوم البيانية ذات الصلة Vaadin Addon وتغيير ذلك ....
إلى فاادين أم لا
مع VAADIN يبدو أن جافا سكريبت الأساسي، يتم إنشاء HTML و CSS ديناميكيا من تطبيق Java Swing Type. من وجهة نظر منحازة متحيزة وربما سخيفة من وجهة نظر "سوف تولد رمز لك" لا تعطي رائحة تصميم جيدة. ما لم تكن بحاجة إلى تجريد لماذا ربط مع إطار آخر. كما هو الحال مع أي إطار توليد من التعليمات البرمجية، يجب أن يعمل بشكل أفضل للجرم Vaadin في الاعتبار، ولكن ليس مرنا للغاية؛ أشعر أنه إذا كنا تقنية الويب، فمن الأفضل أن تفعل ذلك في الأدوات واللغات التي أثارت التكنولوجيا - وهي مكتبات HTML و CSS و JavaScript / JavaScript بدلا من الاعتماد على مستوى آخر من التجريد - إطار Vaadin. قد يشعر هذا بالسوء إلى مطور GWT أو Vaadin كخبراء، كما أعتقد أن شركة Google Liqueers تولد أكثر جافا سكريبت مثبتة من تلك المشفرة يدك،، يساعد في إدارة التعليمات البرمجية بشكل أفضل بين فرق متعددة وغيرها (ولكن في الغالب عند تطوير تطبيقات الويب Biggish جميلة)، مطور أفضل الإنتاجية، أسهل تصحيح الأخطاء وما إلى ذلك. ومع ذلك، فإن مكونات الكتابة في Java for Vaadin، ثم التحويل التلقائي إلى JS، أشعر أنني غير صحيح في أن العديد من مطورينا لن يتعلموا أبدا لغة برمجة مهمة للغاية - جافا سكريبت لتطوير الويب (واكتساب الجر بسرعة جانب الخادم - node.js). عند الاعتماد على الأطر للحصول على JavaScript مباشرة كما لن تتفوق أبدا في هذه اللغة. أعتقد أن الشركة القائمة على المنتج، من المهم تعلم اللغة مباشرة لغة الويب بدلا من ذلك. نظرا لأن شخصا ما علقت أن جافا أصبح مثل COBOL من العام العام، فمن الضروري أن تعتمد الكفاءة لتعلم لغات مهمة أخرى مثل JavaScript. ومع ذلك، فقد عملت في JS لوقت صغير لدي، لقد لاحظت أنه إذا كنا نصمم مع بعض الانضباط (نمط الوحدة النمطية)، اختبر كل وحدة المنطق - وحدة JavaScript - JStestDriver، وتشغيل Jshint، فهي لغة قوية إلى حد ما للعمل معها والإنتاجية تتحسن من جافا بمجرد تعلمها. أيضا معظم المكونات المهمة مثال - يتم كتابة OpenLayers في JS وإذا كنت بحاجة إلى تمديد هذه أو العمل مع الأمثل، فأنت بحاجة إلى معرفة JavaScript، أو لهذه المسألة مكتبات قوية مثل D3.js باختصار حتى هناك الكثير من ميزة في استخدام Vaadin والأطر، على المدى الطويل ربما باستخدام JavaScript مهم؟
أنا أستخدم vaadin كذلك. على الرغم من أن التطبيق ليس كبيرا، فإن ما أعجبني حقا بالتجربة هو أن واجهة برمجة التطبيقات كانت ثابتة، موثقة جيدا بشكل عام ونظرا بأداة جديدة، كنت قادرا على كرنك الأشياء ل جدا عميل مطالب في نفسه، أو في بعض الحالات، أطر زمنية أفضل من الأدوات التي استخدمتها من قبل.
قلة قليلة جدا. واحد الوحيد الآن هو أن العميل يصر على استخدام IE 7 (لا تسأل) وبعض الحلوى العين الفردية لا تعمل تماما بنسبة 100٪ تماما في مكون الملحق (الرسم البياني).
راجع للشغل أنا لا أعمل من أجل Vaadin إما :-)
لقد جربت النصيبيت وفاسيت كلاهما وإذا حاولت حقا لبعض الوقت، فأنت تعلم أن فايدين هو الطريق للذهاب وليس الويكيت، الفترة. - dheeraj g.
لقد بحثنا في النصيبات حيث أعمل ولكن وجدنا بدلا من 9000 ملف، قد يكون لدينا أكثر من 30،000. لدينا ما يقرب من 1000 شاشات مع تطبيق خدماتنا المالية الأساسية لدينا وعلى الرغم من أن النصيبات تبدو كبيرة من الصعب للغاية تحويل كود الدعامات 1.3 لدينا إلى النصيبيت. قام المهندس المعماري لدينا بمشروع POC و 3 شاشات فقط أضاف عدة مئات من الفصول (كثير منهم لإعادة الاستخدام). من الصعب أيضا البروتوبيب شاشة مع النصيبات لأن HTML يجب أن تتطابق مع رمز Java والعكس صحيح.
فايدين يبدو واعدا ولكن سيكون من الصعب بيع الفريق.
ملاحظة: بغض النظر عن مدى عظيم الإطار، لن يتعلم أي شخص ما إذا لم يتم استخدامه في هذه الصناعة. Wicket موجود حول لحظة حتى الآن عدد قليل جدا من الشركات استخدامها. يهتم معظم المطورين الذين أتحدث معهم بتعلم إطار جديد عديم الفائدة في السيرة الذاتية.
الشيء الرئيسي هو Vaadin يستخدم تصميم يشبه التأرجح ويساعد في أن بدأت في جافا باستخدام التأرجح.
لقد استخدمت Vaadin لتطوير giftAdvisor في الشركة التي أعمل بها (وليس فايدن؛).
يسمح لك Vaadin بإنشاء تطبيقات الويب المكونة على الأرجوحة.
إذا كنت تشعر بالقلق إزاء ذهاب وإياب جولة الخادم العميل مقابل كل نقرة، فأنا أذهب إلى هذا: قمت بإنشاء زر Mouseover يغير مظهر الزر عند نعم، Mouseover. لهذا الإطار يجب أن يذهب إلى الخادم والظهر. ويعمل بسرعة ما يكفي من المنظمة البحرية الدولية. يرى http://www.cadeau.nl/sophie. للتحقق من ما أعنيه.
أحب Vaadin، وهي أجنحة احتياجاتي وتجعل WebdeEmment نسيم.
التحيات، روب.
لقد بدأت مع Vaadin قبل يومين فقط وتمكنت من بناء تطبيق CRUD صغير على Osgi كاملة مع "مشروط"، ملزمة البيانات، خدمات OSGI للمثابرة. شيء لطيف حقا هو أن واجهة المستخدم الخاصة بي كاملة هو فقط 118 خطا من التعليمات البرمجية ويدعم عمليات CRUD كاملة للحصول على بنية بسيطة جافا بسيطة.
من الجيد أيضا أن Vaadin يعمل بشكل مثالي في Osgi. إنها بالفعل حزمة وجدت جسر صغير من نيل بارتلتي الذي يجعل Vaadin سهل الاستخدام للغاية في Osgi.
لا أمانع استخدام الدول على جانب الخادم. يخدم الغرض منه. مع الحوسبة السحابية الآن، أصبحت تخزين وعرض النطاق الترددي رخيصة. لكن نعم يمكنني أن أرى وجهة نظرك من منظور تصميم جيد خاصة إذا كنت ترغب في إعادة طلبك. لكنني أعتقد أن هناك إيجابيات أكثر من سلبيات فيما يتعلق بفادين وما شابه ذلك. شيء رئيسي واحد، أنت لا تضطر إلى تعديل قدر كبير حول تطبيقات الويب الخاصة بك لمتصفح معين يتيح تسميتها IE، لمعنويات JavaScript / CSS - خاصة إذا كنت موجها نحو النهاية الخلفية مثلي. يصبح جميع WebApps متوافقا عبر المتصفح دون الحاجة إلى القلق أي شيء. تذكر وقت المطور بريق من ذلك من التخزين وعرض النطاق الترددي. هذا رأيي. =)
