ما هي العيوب الرئيسية لـ Java Server Faces 2.0؟

Question

لقد شاهدت بالأمس عرضًا تقديميًا عن Java Server Faces 2.0 والذي بدا مثيرًا للإعجاب حقًا، على الرغم من أنني حاليًا مطور سعيد لـ ASP.NET MVC / jQuery.أكثر ما أعجبني في JSF هو الكم الهائل من مكونات واجهة المستخدم التي تدعم AJAX والتي يبدو أنها تجعل التطوير أسرع بكثير من ASP.NET MVC، خاصة على المواقع ذات AJAX الثقيلة.بدا اختبار التكامل لطيفًا جدًا أيضًا.

وبما أن العرض أكد فقط على مزايا JSF، أود أن أسمع عن الجانب الآخر أيضًا.

لذلك أسئلتي هي:

• ما هي العيوب الرئيسية لـ Java Server Faces 2.0؟
• ما الذي قد يجعل مطور JSF يفكر في استخدام ASP.NET MVC بدلاً من JSF؟

Answer 1

JSF 2.0 عيوب؟ بصراحة ، بصرف النظر عن منحنى التعلم الحاد النسبي عندما لا يكون لديك معرفة خلفية قوية عنها تطوير الويب الأساسي (HTML/CSS/JS ، جانب الخادم مقابل جانب العميل ، إلخ) و أساسية java servlet API (طلب/استجابة/جلسة ، إعادة توجيه/إعادة توجيه ، إلخ) ، لا تتبادر إلى الذهن أي عيوب خطيرة. لا يزال يتعين على JSF في إصداره الحالي التخلص من الصورة السلبية التي اكتسبتها خلال العصور المبكرة ، حيث كانت هناك العديد من العيوب الخطيرة.

JSF 1.0 (مارس 2004)

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

JSF 1.1 (مايو 2004)

كان هذا إصدار Bugfix. كان الأداء لم يتحسن كثيرًا. كان هناك أيضًا عيب رئيسي واحد: لا يمكنك ضمن HTML في صفحة JSF بلا عيب. يتم تقديم جميع الفانيليا العادي HTML قبل شجرة مكون JSF. تحتاج إلى لف كل الفانيليا العادية في <f:verbatim> العلامات بحيث يتم تضمينها في شجرة مكون JSF. على الرغم من أن هذا كان وفقًا للمواصفات ، فقد تلقى هذا الكثير من الانتقادات. انظر أيضا AO JSF/FaceLets: لماذا ليس من الجيد خلط JSF/Facelets مع علامات HTML؟

JSF 1.2 (مايو 2006)

كان هذا هو الإصدار الأول من فريق تطوير JSF الجديد الذي يقوده ريان لوبك. قام الفريق الجديد بالكثير من العمل الرائع. كانت هناك أيضا تغييرات في المواصفات. كان التغيير الرئيسي هو تحسين معالجة الرأي. هذا ليس فقط JSF المنفصل تمامًا من JSP ، لذلك يمكن للمرء استخدام تقنية عرض مختلفة عن JSP ، ولكنه سمح أيضًا للمطورين بتضمين HTML العادي في صفحة JSF دون أن يتلاعب مع <f:verbatim> العلامات. التركيز الرئيسي الآخر للفريق الجديد هو تحسين الأداء. خلال عمر تطبيق Sun JSF المرجعي 1.2 (الذي تم تسجيل اسمه موجارا منذ Build 1.2_08 ، حوالي عام 2008) ، تم شحن كل بناء عمليًا مع تحسينات الأداء (الرئيسية) بجوار الإثارات المعتادة (الثانوية).

العيب الجاد الوحيد لـ JSF 1.x (بما في ذلك 1.2) هو عدم وجود نطاق بين طلب و جلسة النطاق ، ما يسمى محادثة الكائن. أجبر هذا المطورين على المتاعب مع عناصر الإدخال المخفية ، واستعلامات DB غير الضرورية و/أو إساءة استخدام نطاق الجلسة كلما أراد المرء الاحتفاظ ببيانات النموذج الأولي في الطلب اللاحق من أجل معالجة عمليات التحقق من صحة وتحويلات النموذج بنجاح في المزيد WebApplications المعقدة. يمكن تخفيف الألم من خلال تبني مكتبة طرف ثالثة تحتفظ بالبيانات اللازمة في الطلب اللاحق مثل myfaces tomahawk <t:saveState> عنصر، Jboss التماس نطاق المحادثة و أوركسترا myfaces إطار محادثة.

عيب آخر لصيانة HTML/CSS هو أن JSF يستخدم القولون : كحرف فاصل ID لضمان تفرد عنصر HTML id في إخراج HTML الذي تم إنشاؤه ، خاصة عند إعادة استخدام المكون أكثر من مرة في العرض (Templating ، المكونات التكرارية ، إلخ). لأن هذه شخصية غير قانونية في معرفات CSS ، ستحتاج إلى استخدام \ للهروب من القولون في محددات CSS ، مما يؤدي إلى محددات قبيحة وذات مظهر غريب #formId\:fieldId {} او حتى #formId\3A fieldId {}. أنظر أيضا كيفية استخدام معرف عنصر HTML الذي تم إنشاؤه مع JSF مع القولون ":" في محددات CSS؟ ومع ذلك ، إذا لم تكن خالصًا ، فاقرأ أيضًا بشكل افتراضي ، يقوم JSF بإنشاء معرفات غير صالحة للاستعمال ، والتي لا تتوافق مع جزء CSS من معايير الويب.

أيضًا ، لم يشحن JSF 1.x مع مرافق Ajax خارج الصندوق. ليس حقًا عيبًا تقنيًا ، ولكن بسبب الضجيج على الويب 2.0 خلال تلك الفترة ، أصبح عيبًا وظيفيًا. exadel كان مبكرًا لتقديم AJAX4JSF ، والذي تم تطويره تمامًا خلال السنوات وأصبح الجزء الأساسي من JBoss Richfaces مكتبة المكون. تم شحن مكتبات مكونة أخرى مع قوى Ajax بنيت أيضًا ، كائن معروف جيدًا Icefaces.

حوالي منتصف الطريق JSF 1.2 Lifetime ، تم تقديم تقنية عرض XML جديدة: الوجه. هذا يوفر مزايا هائلة فوق JSP ، وخاصة في مجال التحول.

JSF 2.0 (يونيو 2009)

كان هذا هو الإصدار الرئيسي الثاني ، مع Ajax ككلمة طنانة. كان هناك الكثير من التغييرات التقنية والوظيفية. يتم استبدال JSP بوجهات الوجه حيث تم توسيع تقنية العرض الافتراضية ووجهات الوجه بقدرات لإنشاء مكونات مخصصة باستخدام XML النقي (ما يسمى مكونات مركبة). أنظر أيضا لماذا يفضل الوجهين على JSP باعتبارها لغة تعريف العرض من JSF2.0 فصاعدا؟

تم تقديم قوى Ajax في نكهة <f:ajax> المكون الذي لديه الكثير من أوجه التشابه مع AJAX4JSF. تم تقديم التعليقات التوضيحية وتحسينات التكوينات قتل المطول faces-config.xml ملف قدر الإمكان. أيضا ، حرف فاصل معرف حاوية التسمية الافتراضي : أصبح قابلاً للتكوين ، لذلك يمكن أن يتنفس أصحاب HTML/CSS. كل ما عليك فعله هو تعريفه init-param في web.xml مع الاسم javax.faces.SEPARATOR_CHAR والتأكد من أنك لا تستخدم الشخصية نفسك في أي مكان في معرف العميل ، مثل -.

أخيرًا وليس آخرًا ، تم تقديم نطاق جديد ، رأي الكائن. لقد قضت على عيب JSF 1.x رئيسي آخر كما هو موضح من قبل. أنت فقط تعلن بين الفول @ViewScoped لتمكين نطاق المحادثة دون أن يثير كل الطرق للاحتفاظ بالبيانات في طلبات (محادثة) لاحقة. أ @ViewScoped ستعيش Bean ما دمت تقدمها لاحقًا وتنتقل إلى نفس العرض (بشكل مستقل عن علامة تبويب/نافذة المتصفح المفتوحة!) ، إما بشكل متزامن أو غير متزامن (Ajax). أنظر أيضا الفرق بين العرض ونطاق الطلب في الفاصوليا المدارة و كيف تختار نطاق الفول المناسب؟

على الرغم من التخلص من جميع عيوب JSF 1.x عملياً ، إلا أن هناك أخطاء محددة JSF 2.0 والتي قد تصبح عرضًا. ال @ViewScoped فشل في معالجات العلامات بسبب قضية دجاج البيض في توفير الحالة الجزئية. تم إصلاح هذا في JSF 2.2 وخلع في Mojarra 2.1.18. ايضا تمرير سمات مخصصة مثل HTML5 data-xxx غير مدعومة. تم إصلاح هذا في JSF 2.2 بواسطة ميزة/سمات العناصر/السمات الجديدة. علاوة على ذلك ، فإن تطبيق JSF لديه Mojarra مجموعة القضايا الخاصة بها. يرتبط الكثير منهم نسبيًا بـ في بعض الأحيان سلوك غير بديهي <ui:repeat>, ، ال تنفيذ جديد لتوفير الحالة الجزئية و ال نطاق الفلاش الذي تم تنفيذه بشكل سيئ. يتم إصلاح معظمهم في إصدار Mojarra 2.2.x.

حول وقت JSF 2.0 ، Primefaces تم تقديمه ، بناءً على jQuery و jQuery UI. أصبحت مكتبة مكونات JSF الأكثر شعبية.

JSF 2.2 (مايو 2013)

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

بصرف النظر عن الأخطاء المحددة للتنفيذ وبعض "الأشياء الصغيرة المزعجة" مثل عدم القدرة على حقن EJB في مدقق/محول (تم إصلاحه بالفعل في JSF 2.3) ، لا توجد عيوب كبيرة حقًا في مواصفات JSF 2.2.

مكون القائم على مكون MVC مقابل الطلب MVC

قد يختار البعض أن العيب الرئيسي لـ JSF هو أنه يتيح القليل من التحكم في الحبيبات الدقيقة على HTML/CSS/JS. هذا ليس JSF ، هذا فقط لأنه مكون على أساس إطار عمل MVC ، وليس أ طلب (إجراء) قائم إطار MVC. إذا كانت درجة عالية من السيطرة على HTML/CSS/JS هي متطلباتك الرئيسية عند النظر في إطار عمل MVC ، فيجب عليك بالفعل أن لا تبحث في إطار MVC على أساس مكون ، ولكن في إطار عمل MVC يعتمد على الطلب مثل الربيع MVC. ما عليك سوى أن تأخذ في الاعتبار أنه سيتعين عليك كتابة كل ما في HTML/CSS/JS Boilerplate بنفسك. أنظر أيضا الفرق بين طلب MVC و Component MVC.

أنظر أيضا:

• ما هو الفرق بين JSF و Servlet و JSP؟ (فقط لفهم الأساسيات)
• باستخدام JSF لتطوير تخطيطات CSS بدون ملوحة (أسطورة أخرى حول JSF)
• JSF مقابل HTML/CSS/JS/JQUERY (عندما يكون JSF هو الخيار الخاطئ)
• أنماط التصميم في تطبيقات الويب (يوضح الأيديولوجية وراء MVC)

Answer 2

بعد 5 سنوات من العمل مع JSF ، أعتقد أنه يمكنني إضافة 2 سنت.

اثنين الرائد JSF عيوب:

1. منحنى التعلم الكبير. JSF معقد ، هذا صحيح.
2. إنه عنصر طبيعة سجية. يحاول الإطار القائم على المكونات إخفاء الطبيعة الحقيقية للويب ، والتي تأتي مع قدر كبير من المضاعفات والكوارث (مثل عدم دعم الحصول على JSF في غضون 5 سنوات تقريبًا).
   IMHO يخفي طلب/استجابة HTTP من المطور خطأ هائل. من تجربتي ، يضيف كل إطار عمل قائم على المكون تجريدًا إلى تطوير الويب ، وهذا التجريد يؤدي إلى تعقيد غير ضروري وتعقيد أعلى.

و صغير العيوب التي تتبادر إلى ذهني:

1. يتكون المعرف الافتراضي للكائن من معرفات والديه ، على سبيل المثال Form1: Button1.
2. لا توجد طريقة سهلة للتعليق على شظية الصفحة غير صحيحة. بطاقة شعار <ui:remove> يحتاج إلى محتوى صحيح النحوي الذي يتم تحليله على أي حال.
3. مكونات الجودة الثالثة ذات الجودة المنخفضة التي لا تتحقق على سبيل المثال isRendered() داخل processXxx() الطريقة قبل المتابعة.
4. دمج أقل و sencha صعب.
5. لا يلعب بشكل جيد مع الراحة.
6. ليس من السهل جدًا على مصممي UX ، لأن المكونات الجاهزة للاستخدام لها أنماط CSS الخاصة بها ، والتي تحتاج إلى الكتابة فوقها.

لا تفهموني خطأ. باعتباره إطارًا مكونًا JSF في الإصدار 2 جيد حقًا ، لكنه لا يزال يعتمد على المكونات ، وسيظل دائمًا ...

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

بالنسبة لي ، إنه عيب JSF الرئيسي. يمكن لـ IMHO JSF أن يناسب نوعًا من التطبيقات (Intranet ، كثافة النماذج) ، ولكن للحياة الحقيقية الويب التطبيق ليس وسيلة جيدة للذهاب.

آمل أن يساعد شخص ما مع خياراته التي تعتبر الواجهة الأمامية.

Answer 3

بعض العيوب التي تنبثق:

1. JSF هو إطار قائم على المكون. هذا له قيود متأصلة تتعلق بطاعة نموذج المكون.
2. يدعم AFAIK JSF النشر فقط ، لذلك إذا كنت تريد الحصول على مكان ما ، فيجب عليك القيام بخدمة Servlet/JSP عادي.
3. تحاول معظم المكونات تقديم تجريدات على المجالات مثل قواعد البيانات العلائقية وجافا سكريبت الواجهة الأمامية ، والعديد من الوقت هذه التجريدات "متسربة" ومن الصعب للغاية تصحيحها.
4. قد تكون هذه التجريدات نقطة انطلاق جيدة لمطور صغار أو شخص غير مرتاح لمجال معين (مثل JavaScript الواجهة الأمامية) ، ولكن يصعب تحسينه للأداء ، نظرًا لوجود العديد من الطبقات ، ومعظم الأشخاص الذين يستخدمونها لا تفهم سوى القليل لما يجري تحت الغطاء.
5. لا علاقة لآليات التقييم التي يتم استخدامها عادة مع JSF مع كيفية عمل Desigers على الويب. يعد محرري WysiWyg لـ JSF بدائيًا ، وعلى أي حال ، سيعطيك المصمم HTML/CSS الذي سيتعين عليك قضاء أعمارهم في التحويل.
6. لا يتم فحص أشياء مثل EL Expressions بشكل ثابت ، ولا يقوم كل من المترجم والمعاصف بعمل جيد في العثور على أخطاء ، لذلك ستنتهي بالأخطاء التي يتعين عليك التقاطها في وقت التشغيل. قد يكون هذا جيدًا للغة المكتوبة ديناميكيًا مثل Ruby أو PHP ، ولكن إذا اضطررت إلى تحمل الانتفاخ الشديد للنظام الإيكولوجي Java ، فأنا أطلب الكتابة على القوالب الخاصة بي.

لتلخيص: في الوقت الذي ستوفر فيه مع JSF ، من تجنب كتابة رمز JSP/Servlet/Bean Boilerplate ، ستقضيه X10 لجعله مقياسًا وفعل ما تريد القيام به بالضبط.

Answer 4

بالنسبة لي أكبر عيب في JSF 2.0 هو منحنى التعلم ليس فقط لـ JSF ، ولكن المكتبات المكونة التي يجب عليك استخدامها من أجل الحصول على عمل مفيد. النظر في العدد المذهل من المواصفات والمعايير التي تتعامل معها لتكون حقا كفاءة:

• HTML في التجسد المختلفة. لا تتظاهر بأنك لست بحاجة إلى معرفة ذلك.
• HTTP - عندما لا يمكنك معرفة ما يجري ، يجب عليك فتح Firebug ورؤية. لذلك تحتاج إلى معرفة هذا.
• CSS - أحب ذلك أم لا. إنه ليس سيئًا جدًا وهناك بعض الأدوات اللطيفة على الأقل.
• XML - من المحتمل أن يكون JSF أول مكان تستخدمه مساحات الأسماء في هذه الدرجة.
• مواصفات servlet. عاجلاً أم آجلاً ، سوف تحصل على أساليب الاتصال في هذه الحزمة. بصرف النظر عن ذلك ، عليك أن تعرف كيف يتم تحويل وجماهيرك إلى XHTML أو أي شيء آخر.
• JSP (في الغالب حتى تعرف لماذا لا تحتاجه في JSF)
• JSTL (مرة أخرى ، في الغالب للتعامل مع الإطار القديم)
• لغة التعبير (EL) في أشكالها المختلفة.
• Ecmascript ، JavaScript ، أو أي شيء آخر تريد تسميته.
• JSON - يجب أن تعرف هذا حتى لو لم تستخدمه.
• أياكس. أود أن أقول إن JSF 2.0 يقوم بعمل لائق لإخفاء هذا منك ولكن لا تزال بحاجة إلى معرفة ما يجري.
• دوم. وكيف يستخدمه المستعرض. انظر Ecmascript.
• أحداث DOM - موضوع من تلقاء نفسه.
• بنية ثبات Java (JPA) ، إذا كنت تريد أن يكون لتطبيقك قاعدة بيانات النهاية الخلفية.
• جافا نفسها.
• jsee وأنت في ذلك.
• مواصفات حقن تبعية السياق (CDI) وكيفية اشتباكها وتستخدم مع JSF 2.0
• jQuery - أود أن أراك تتماشى بدونها.

الآن ، بمجرد الانتهاء من ذلك ، يمكنك الاستمرار في المواصفات الاحتكارية ، وهي مكتبات المكونات ومكتبات مقدمي الخدمات التي ستلتقطها على طول الطريق:

• Primefaces (مكتبة المكونات الخاصة بي المختار)
• ريتشفس
• myfaces
• Icefaces
• Eclipselink (مزود JPA الخاص بي)
• بيات شتوى
• اللحام

ولا تنس الحاوية! وجميع ملفات التكوين هذه:

• الأسماك الزجاجية (2 ، 3 ، إلخ)
• jboss
• هر

إذن - هذا يجعل الأمر سهلاً؟ من المؤكد أن JSF 2.0 "سهل" طالما أن كل ما تريد فعله هو أبسط صفحات الويب مع أبسط التفاعلات.

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

Answer 5

1. عادة ما يقوم المطورون عديمي الخبرة بإنشاء تطبيقات بطيئة للغاية وستكون التعليمات البرمجية قبيحة للغاية ويصعب صيانتها.قد يكون البدء أمرًا بسيطًا ومخادعًا، ولكنه يتطلب في الواقع بعض الاستثمار في التعلم إذا كنت تريد كتابة برامج جيدة.
2. على الأقل في البداية، غالبًا ما "تتعثر" في مشكلة ما وستقضي وقتًا أطول في قراءة منشورات balusc على الإنترنت أكثر من العمل الفعلي :) بعد فترة من الوقت، سيقل الأمر أكثر فأكثر، لكنه لا يزال مزعجًا.
3. الأمر الأكثر إزعاجًا عندما تكتشف أن المشكلة ليست بسبب نقص المعرفة/الخطأ ولكنها في الواقع خطأ.كان Mojarra (هو؟) عربات التي تجرها الدواب تماما، وتضيف طبقة أخرى من المكونات المزيد من المشاكل.كان Richfaces أكبر برنامج تم كتابته على الإطلاق :) لا أعرف كيف هو الآن في الإصدار 4.لدينا Primefaces وهو الأفضل، ولكنك ستواجه أخطاء أو نقصًا في الميزات خاصة مع المكونات الأكثر غرابة.والآن ستحتاج إلى الدفع مقابل تحديثات Primefaces.لذلك أود أن أقول إنها عربات التي تجرها الدواب ولكنها تتحسن خاصة بعد أن قام الإصدار 2.2 بإصلاح بعض المشكلات المتعلقة بالمواصفات.أصبح إطار العمل أكثر نضجًا ولكنه لا يزال بعيدًا عن الكمال (ربما يكون وجهي أفضل؟).
4. لا أجدها مرنة بشكل خاص.في كثير من الأحيان، إذا كنت بحاجة إلى شيء مخصص للغاية ولا توجد مكونات تقوم بذلك - فسيكون الأمر مؤلمًا بعض الشيء.مرة أخرى، أنا أتحدث من منظور المطور العادي - المنظور الذي يتضمن مواعيد نهائية وبرامج تعليمية سريعة القراءة والبحث في تدفق المكدس عندما تتعثر لأنه لا يوجد وقت لمعرفة كيفية عمله حقًا :) غالبًا ما يبدو أن بعض المكونات تحتوي على ما تحتاجه "تقريبًا"، ولكن ليس بالضبط، وفي بعض الأحيان قد تقضي الكثير من الوقت لجعله يفعل شيئًا تريده :) يجب أن تكون حذرًا في تقييم ما إذا كان من الأفضل إنشاء المكون الخاص بك أو تعذيب المكون الحالي.في الواقع، إذا كنت تقوم بإنشاء شيء فريد حقًا، فلا أوصي بـ JSF.

لذلك باختصار عيوبي ستكون:التعقيد، ليس تقدمًا سلسًا جدًا في التطوير، عربات التي تجرها الدواب، غير مرنة.

بالطبع هناك مزايا أيضًا، لكن هذا ليس ما طلبته.على أي حال، هذه هي تجربتي مع إطار العمل الذي قد يكون لدى الآخرين آراء مختلفة، لذا فإن أفضل طريقة هي تجربته لفترة من الوقت لمعرفة ما إذا كان يناسبك (مجرد شيء أكثر تعقيدًا - وليس أمثلة ساذجة - يتألق JSF حقًا هناك :) أفضل حالة استخدام لـ IMHO JSF هي تطبيقات الأعمال، مثل CRMs وما إلى ذلك ...

Answer 6

"سيقوم JSF بإخراج Layer HTML و JavaScript لا يمكنك التحكم فيه أو التغيير دون الدخول إلى رمز وحدة التحكم."

في الواقع ، يمنحك JSF المرونة ، يمكنك إما استخدام مكونات قياسية/تابعة لجهة خارجية أو إنشاء تحكم كامل في ما يتم تقديمه. إنه مجرد XHTML واحد تحتاج إلى إنشاء مكوناتك المخصصة باستخدام JSF 2.0.

Answer 7

لقد قمنا بتطوير مشروع نموذجي مع JSF (لقد كان بحثًا مدته ثلاثة أسابيع لذا ربما فقدنا بعض الأشياء!)

نحن نحاول استخدام الأساسية jsf، إذا كانت هناك حاجة إلى مكون استخدمنا PrimeFaces.

كان المشروع عبارة عن موقع على شبكة الإنترنت مع الملاحة.يجب تحميل كل صفحة عبر اياكس عند النقر على القائمة.

يحتوي الموقع على حالتين للاستخدام:

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

لقد وجدنا أن:

1. تحتاج إلى استخدام بعض الاختراقات من omniFaces لإصلاح حالة عرض JSF.سوف تتلف حالة JSF عندما تقوم بتضمين صفحات عبر ajax في بعضها البعض.يبدو أن هذا خطأ في JSF وقد يتم إصلاحه في الإصدارات التالية (وليس في الإصدار 2.3).
2. لا يعمل تدفق JSF بشكل صحيح مع ajax (أو لم نتمكن من تشغيله!) نحن نحاول استخدام مكون معالج Primeface بدلاً من ذلك ولكن يبدو أن التحقق من صحة العميل غير مدعوم ويعني أنه لم يكن معيار تدفق JSF القياسي.
3. عند استخدام بعض مكونات jQuery مثل jqGird، وتحتاج إلى تحميل نتائج JSON، يُنصح باستخدام servlet خالص، ولن يفعل JSF شيئًا من أجلك.لذا، إذا كنت تستخدم هذا النوع من المكونات، فلن يتناسب تصميمك مع JSF.
4. نحاول تنفيذ بعض البرامج النصية للعميل عند اكتمال ajax ajaxComplete ووجدنا أن PF 4 قام بتنفيذ أحداث ajax الخاصة به.كان لدينا بعض مكونات jQuery ونحتاج إلى تغيير الكود الخاص بها.

إذا قمت بتغيير العينة أعلاه إلى أ غير اياكس مشروع (أو على الأقل مشروع أياكس أقل) فلن تواجه الكثير من المشكلات المذكورة أعلاه.

ونلخص بحثنا على النحو التالي:

JSF لا يعمل بشكل جيد في موقع قاعدة أياكس بالكامل.

بالطبع نجد الكثير من الميزات الرائعة في JSF والتي قد تكون مفيدة جدًا في بعض المشاريع، لذا ضع في اعتبارك احتياجات مشروعك.

يرجى الرجوع إلى المستندات الفنية لـ JSF لمراجعة مزايا JSF، وفي رأيي أن أكبر ميزة لـ JSF هي الدعم الكامل والضخم من @BaluC ؛-)

Answer 8

أنا لست خادم Java يواجه خبيرًا على الإطلاق. لكن IMHO العيب الرئيسي هو أنه جانب الخادم. لقد سئمت من التعلم واستخدام أطر طبقة العرض التقديمية على شبكة الإنترنت من جانب الخادم مثل نماذج الويب ASP.NET ، و ASP.NET MVC ، ووجوه خادم Java ، والدعامات ، وأطر PHP ، و Ruby On Rails. قلت وداعا لهم جميعا ، وقلت مرحبا ل angularjs و typeScript. تعمل طبقة العرض التقديمي على المتصفح. لا يهم ما إذا كان يتم تقديمه بواسطة Windows IIS تشغيل PHP أو ASP.NET ، أو إذا تم تقديمه بواسطة خادم الويب Apache الذي يعمل على Linux. أنا فقط بحاجة إلى تعلم إطار عمل واحد فقط يعمل في كل مكان.

جمعية البناء الخيرية.

Answer 9

بالنسبة لي ، فإن أكبر عيب في JSF هو الدعم الضعيف للصفحات التي تم إنشاؤها برمجيًا (ديناميكيًا).
إذا كنت ترغب في إنشاء صفحتك (إنشاء نموذج مكون الصفحة) ديناميكيًا من رمز Java. على سبيل المثال ، إذا كنت تعمل على مُنشئ صفحة WYSIWYG. الوثائق الكافية لحالة الاستخدام هذه في غير متوفرة بشكل عام. هناك العديد من النقاط التي يتعين عليك فيها التجربة والتطوير بطيئًا. أشياء كثيرة فقط لا تعمل كيف تتوقع. ولكن بشكل عام ، من الممكن اختراق ذلك بطريقة أو بأخرى.
شيء جيد هو أنها ليست مشكلة في فلسفة أو بنية JSF. إنه ببساطة غير مفصح بما فيه الكفاية (بقدر ما أعرف).

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

ولكن يبدو أن مجتمع JSF يدرك أوجه القصور هذه. إنهم يعملون على هذا كما ترون من هاتين الحشرات
http://java.net/jira/browse/javaserverfaces-1309
http://java.net/jira/browse/javaserverfaces_spec_public-599

يجب أن يكون الموقف أفضل مع JSF 2.2 على الأقل إذا كنا نتحدث عن المواصفات.

Answer 10

التعليق على الأشهر القليلة الماضية من تجربة PrimeFaces/JSF:

• إذا كنت تستطيع استخدام المكونات "خارج الرف" ، أعتقد أنه ليس فظيعًا.
• ومع ذلك ، فإنه لا يلعب بشكل جيد بمجرد الخروج إلى الخارج وتحتاج إلى واجهة مستخدم مخصصة. - على سبيل المثال ، كنا بحاجة إلى استخدام bootstrap من Twitter لمشروعنا. (وليس Primefaces bootstrap).
  • الآن صفحاتنا تعمل على النحو التالي:
    • تحميل الصفحة.
    • يتفاعل المستخدم مع primefaces التي لها وظيفة AJAX
    • Bootstrap's JavaScript Break
    • ندير JavaScript إضافي لإعادة ربط كل شيء

تحول وعد JSF لتجنب كتابة JavaScript إلى كتابة المزيد من javaScript أكثر مما كان لدينا إذا لم نستخدم PrimeFaces-وهذا JavaScript هو إصلاح ما يكسره PrimeFaces.

لقد حان الوقت للوعة-ما لم تكن تستخدم مرة أخرى أشياء "خارج الرف". أيضا قبيح حقا (primefaces) عند الاضطرار إلى العمل مع السيلينيوم. يمكن القيام كل ذلك-ولكن مرة أخرى-هناك الكثير من الوقت.

بالتأكيد تجنب هذا إذا كنت تعمل مع فريق UX/Design وتحتاج إلى التكرار بسرعة على واجهة المستخدم-يمكنك توفير الوقت من خلال تعلم jQuery/كتابة HTML مباشرة-أو النظر إلى React/Angular.

Answer 11

JSF لديه العديد من المزايا ، والأسئلة في وضع غير مؤات ، اسمحوا لي أن أضيف بضع نقاط عليها.

في سيناريو عملي لتنفيذ مشروع ويب به في إطار زمني ، تحتاج إلى مراقبة العوامل التالية.

• هل لديك عدد كاف من الأعضاء الكبار في فريقك يمكنهم اقتراح أفضل الضوابط مناسبة لكل سيناريو؟

• هل لديك عرض النطاق الترددي لاستيعاب منحنى التعلم الأولي؟

• هل لديك خبرة كافية في فريقك الذي يمكنه مراجعة JSF
  تنتج الأشياء من قبل المطورين؟

إذا كانت إجابتك "لا" للأسئلة ، فقد ينتهي بك الأمر في قاعدة كود غير قابلة للعيار.

Answer 12

لدى JSF عيب واحد فقط: قبل بدء تطوير "JSF" ، يجب أن تفهم بوضوح تطوير الويب ، و java الأساسية والهندسة الأمامية.

في الوقت الحاضر ، "New" JavaScript Frameworks فقط حاول نسخ/لصق "نموذج مكون" JSF ".

Answer 13

من بين جميع الأطر "التيار الرئيسي" مثل Spring MVC و Wicket و Tapestry ، وما إلى ذلك ، فإن JSF من Java EE مع مكوناتها المركبة هي أكثر طبقة العرض والتكنولوجيا الموجهة للمكونات المقدمة. إنها مرهقة بعض الشيء وغير مكتملة مقارنة بالحلول التي توفرها Hybridjava.