Java Server Faces 2.0'ın ana dezavantajları nelerdir?

Dün mutlu bir ASP.NET MVC / jQuery geliştiricisi olmama rağmen, gerçekten etkileyici görünen Java Server Faces 2.0'da bir sunum gördüm. JSF hakkında en çok sevdiğim, özellikle AJAX-ağır sitelerde ASP.NET MVC'den çok daha hızlı geliştirme yapan çok sayıda AJAX-Etkin UI bileşeni oldu. Entegrasyon testi de çok güzel görünüyordu.

Sunum sadece JSF'nin avantajlarını vurguladığından, diğer tarafı da duymak isterim.

Yani sorularım:

• Java Server Faces 2.0'ın ana dezavantajları nelerdir?
• Bir JSF geliştiricisinin JSF yerine ASP.NET MVC kullanmayı düşünmesini ne sağlayabilir?

JSF 2.0 dezavantajları? Dürüst olmak gerekirse, temel Web Geliştirme (HTML / CSS / JS, sunucu tarafı ile istemci tarafı, vb.) Ve temel Java Servlet API'sı (istek / yanıt / oturum ) hakkında sağlam bir arka plan bilginiz olmadığında göreceli dik öğrenme eğrisinin dışında , yönlendirme / yönlendirme vb.), ciddi dezavantajlar ortaya çıkmaz. JSF'nin mevcut sürümünde, erken yaşlarda kazandığı olumsuz görüntüden kurtulması gerekiyor ve bu sırada birkaç ciddi dezavantaj vardı.

JSF 1.0 (Mart 2004)

Bu ilk sürümdü. Bilmek istemediğiniz hem çekirdek hem de performans alanlarındaki hatalarla doluydu. Web uygulamanız her zaman sezgisel olarak beklediğiniz gibi çalışmadı. Geliştirici olarak ağlayarak kaçacaktınız.

JSF 1.1 (Mayıs 2004)

Bu, hata düzeltme sürümüdür. Performans hala çok gelişmedi. Ayrıca büyük bir dezavantaj vardı: JSF sayfasında HTML'yi kusursuz bir şekilde satır içi yapamazsınız. Tüm düz vanilya HTML'si , JSF bileşen ağacından önce oluşturulur . Tüm düz vanilyayı <f:verbatim>, JSF bileşen ağacına dahil edilmeleri için etiketlere sarmanız gerekir . Bu şartnameye göre olmasına rağmen, bu çok eleştiri aldı. Ayrıca bkz. JSF / Facelets: JSF / Facelets'i HTML etiketleriyle karıştırmak neden iyi bir fikir değil?

JSF 1.2 (Mayıs 2006)

Bu, Ryan Lubke tarafından yönetilen yeni JSF geliştirme ekibinin ilk sürümüdür. Yeni ekip çok iyi iş çıkardı. Teknik özelliklerde de değişiklikler oldu. En büyük değişiklik, görünüm yönetiminin iyileştirilmesiydi. Bu sadece JSP'yi JSP'den tamamen ayırmakla kalmadı, bu yüzden JSP'den farklı bir görünüm teknolojisi kullanabildiler, aynı zamanda geliştiricilerin <f:verbatim>etiketlerle uğraşmadan JSF sayfasında düz vanilya HTML'si satır içi yapmasına izin verdi . Yeni ekibin bir diğer önemli odağı performansı artırmaktı. (Kod adı edildi Sun JSF Referans Uygulama 1.2 geçerlilik süresi içinde Mojarra 2008 civarında, yapı 1.2_08 beri), hemen her yapı bir sonraki olağan (minör) onarımları için (büyük) performans iyileştirmeleri ile sevk gördü.

JSF 1.x'in (1.2 dahil) tek ciddi dezavantajı, konuşma kapsamı olarak adlandırılan istek ve oturum kapsamı arasında bir kapsamın olmamasıdır . Bu, geliştiricileri gizli giriş öğeleriyle, gereksiz DB sorgularıyla uğraşmaya ve / veya bir sonraki istekte ilk model verilerini tutmak istediğinde oturum kapsamını kötüye kullanmaya zorladı. karmaşık web uygulamaları. Ağrı, MyFaces Tomahawk bileşeni, JBoss Seam konuşma kapsamı ve MyFaces Orkestrası gibi sonraki talepte gerekli verileri tutan bir 3. taraf kütüphanesi benimsenerek yumuşatılabilir. <t:saveState> konuşma çerçevesi.

HTML / CSS puristleri için bir başka dezavantaj, JSF'nin , özellikle bir bileşen görünümde birden çok kez yeniden kullanıldığında (şablon oluşturma, yineleme bileşenleri vb.) Üretilen HTML çıktısındaki :HTML öğesinin benzersizliğini sağlamak için iki nokta üst üste işaretini karakter ayırıcı karakter olarak kullanmasıdır. id. Bu CSS tanımlayıcıları yasadışı bir karakter olduğu için, kullanmak gerekir \gibi çirkin ve tuhaf görünümlü seçicileri sonuçlanan CSS seçicileri içinde iki nokta üst üste kaçmaya #formId\:fieldId {}hatta #formId\3A fieldId {}. Ayrıca bkz. JSF tarafından oluşturulan HTML öğesi kimliği, CSS seçicilerinde iki nokta üst üste ":" ile nasıl kullanılır? Ancak, saf bir kullanıcı değilseniz, ayrıca okuyun Varsayılan olarak JSF, web standartlarının css kısmı ile uyumlu olmayan kullanılamaz kimlikler oluşturur .

Ayrıca, JSF 1.x, Ajax olanaklarıyla kutudan çıkmadı. Gerçekten teknik bir dezavantaj değil, ancak bu dönemdeki Web 2.0 hype nedeniyle fonksiyonel bir dezavantaj haline geldi. Exadel , yıllar boyunca iyice geliştirilmiş ve JBoss RichFaces bileşen kütüphanesinin çekirdek parçası haline gelen Ajax4jsf'i tanıtmaya erken başladı . Başka bir bileşen kütüphanesi de yerleşik Ajax güçleriyle birlikte sevk edildi, iyi bilinenler ICEfaces idi .

JSF 1.2 ömrünün yaklaşık yarısında, yeni bir XML tabanlı görünüm teknolojisi tanıtıldı: Facelets . Bu, özellikle şablonlama alanında JSP'nin üzerinde muazzam avantajlar sundu.

JSF 2.0 (Haziran 2009)

Bu, Ajax'ın buzzword olduğu ikinci büyük sürümdü. Birçok teknik ve işlevsel değişiklik vardı. Varsayılan görüntüleme teknolojisi olarak JSP yerine Facelets kullanılır ve Facelets, saf XML ( bileşik bileşenler adı verilen ) kullanılarak özel bileşenler oluşturma özellikleriyle genişletilmiştir . Ayrıca bkz . JSF2.0'dan itibaren görünüm tanımı dili olarak Neden JSP yerine JSP tercih edilir?

Ajax yetkileri, <f:ajax> Ajax4jsf ile çok benzerlik gösteren bileşenin lezzetiyle tanıtıldı. Ayrıntılı dosya ve yapılandırma üzerinde kural iyileştirmeleri , ayrıntılı dosyayı mümkün olduğunca öldürmek için tanıtıldı faces-config.xml. Ayrıca, varsayılan adlandırma kapsayıcı kimliği ayırıcı karakteri :yapılandırılabilir hale geldi, böylece HTML / CSS temizleyicileri rahatlayabilir. Tek yapmanız gereken tek şey olarak tanımlamaktır init-paramiçinde web.xmladı ile javax.faces.SEPARATOR_CHARaşağıda belirtilenler gibi istemci kimliği yıllarda her yerde karaktere kendini kullanmadığınızı ve sağlanması -.

Son fakat en az değil, yeni bir kapsam, görünüm kapsamı tanıtıldı . Daha önce açıklandığı gibi başka bir JSF 1.x dezavantajını ortadan kaldırdı. Sadece @ViewScopedsonraki (konuşma) isteklerinde verileri tutmak için tüm yolları zahmetsizce konuşma kapsamını etkinleştirmek için fasulye bildirir. Bir @ViewScopedfasulye daha sonra aynı görünüme (açılan tarayıcı sekmesinden / penceresinden bağımsız olarak) senkronize veya senkronize olmayan bir şekilde (Ajax) gönderip gittiğiniz sürece yaşayacaktır. Ayrıca bkz yönetilen fasulye Görünüm ve İstek kapsamı arasındaki Fark ve nasıl sağ fasulye kapsamını seçilir?

Her ne kadar JSF 1.x'in tüm dezavantajları ortadan kaldırılmış olsa da, JSF 2.0'a özgü hatalar gösterebilir. @ViewScopedEtiket işleyicileri başarısız nedeniyle kısmi devlet tasarrufunda bir tavuk-yumurta meselesine. Bu JSF 2.2'de düzeltildi ve Mojarra 2.1.18'de desteklendi. Ayrıca HTML5 gibi özel niteliklerin iletilmesidata-xxx de desteklenmez. Bu JSF 2.2'de yeni geçiş öğeleri / öznitelikleri özelliği ile düzeltildi. Ayrıca JSF uygulaması Mojarra'nın kendi sorunları vardır . Nispeten birçoğu ile ilgilidir bazen unintuitive davranışları<ui:repeat> , yeni kısmi devlet tasarrufu uygulanması ve kötü uygulanan flaş kapsamı . Çoğu Mojarra 2.2.x sürümünde düzeltildi.

JSF 2.0 zamanı boyunca, jQuery ve jQuery kullanıcı arayüzüne dayanan PrimeFaces tanıtıldı. En popüler JSF bileşen kütüphanesi oldu.

JSF 2.2 (Mayıs 2013)

JSF 2.2'nin piyasaya sürülmesiyle, HTML5 teknik olarak sadece tüm eski JSF sürümlerinde desteklenmiş olmasına rağmen terim olarak kullanıldı. Ayrıca bkz.XHTML neden hala kullanılmaktadır JavaServer Faces 2.2 ve HTML5 desteği . En önemli yeni JSF 2.2 özelliği, özel bileşen öznitelikleri desteğidir, böylece özel tableless radyo düğmesi grupları gibi bir olasılıklar dünyası açar .

Uygulamaya özgü hatalar ve bir doğrulayıcı / dönüştürücüye (zaten JSF 2.3'te sabitlenmiş) bir EJB enjekte edilememesi gibi bazı "sinir bozucu küçük şeyler" dışında, JSF 2.2 spesifikasyonunda gerçekten büyük dezavantajlar yoktur.

Bileşen tabanlı MVC ve İstek tabanlı MVC

Bazıları, JSF'nin en büyük dezavantajının, üretilen HTML / CSS / JS üzerinde çok az ince kontrol yapılmasına izin vermesini tercih edebilir. Bu JSF'nin kendisi değil, bunun nedeni, bileşen tabanlı bir MVC çerçevesi, istek (eylem) tabanlı bir MVC çerçevesi değil. Bir MVC çerçevesini düşünürken HTML / CSS / JS'yi yüksek derecede kontrol etmek temel gereksiniminizse, bileşen tabanlı bir MVC çerçevesine değil, Spring MVC gibi isteğe bağlı bir MVC çerçevesine bakmalısınız . Sadece tüm HTML / CSS / JS ısıtıcı plakasını kendiniz yazmanız gerektiğini dikkate almanız gerekir. Ayrıca bkz . MVC İsteği ve Bileşen MVC'si arasındaki fark .

Ayrıca bakınız:

• JSF, Servlet ve JSP arasındaki fark nedir? (sadece temel bilgileri anlamak için)
• Tablosuz CSS mizanpajları geliştirmek için JSF kullanma (JSF hakkında başka bir efsane)
• JSF ve düz HTML / CSS / JS / jQuery (JSF yanlış seçim olduğunda)
• Web uygulamalarında tasarım modelleri (MVC'nin arkasındaki ideolojiyi gösterir)

5 yıllık JSF ile çalıştıktan sonra 2 sent ekleyebileceğimi düşünüyorum.

İki büyük JSF dezavantajı:

1. Büyük öğrenme eğrisi. JSF karmaşıktır, bu sadece doğrudur.
2. Onun bileşen doğası. Bileşen tabanlı çerçeve, çok sayıda komplikasyon ve felaketle (neredeyse 5 yıl içinde JSF'de GET'i desteklememek gibi) gelen Web'in gerçek doğasını gizlemeye çalışır.
   IMHO'nun HTTP İstek / Yanıtını geliştiriciden gizlemesi çok büyük bir hatadır. Deneyimlerime göre, bileşen tabanlı her çerçeve Web geliştirmeye soyutlama ekler ve bu soyutlama gereksiz ek yük ve daha fazla karmaşıklık ile sonuçlanır.

Ve aklıma gelen küçük dezavantajlar:

1. Varsayılan olarak, nesnenin kimliği ebeveynlerinin kimliklerinden oluşur, örneğin form1: düğme1.
2. Yanlış sayfanın parçasını yorumlamak için kolay bir yol yoktur. Etiket <ui:remove>, yine de ayrıştırılmış sözdizimsel olarak doğru içeriğe ihtiyaç duyar.
3. Örneğin kontrol etmiyoruz Düşük kaliteli 3. parti bileşenleri isRendered()içine processXxx()geçmeden önce yöntemi.
4. LESS & Sencha'yı dahil etmek zordur.
5. REST ile iyi oynamıyor.
6. UX tasarımcıları için o kadar kolay değil, çünkü kullanıma hazır bileşenlerin üzerine yazılması gereken kendi CSS stilleri vardır.

Beni yanlış anlamayın. Sürüm 2'de bir bileşen çerçevesi JSF gerçekten iyi, ama yine de bileşen tabanlı ve her zaman olacak ...

Lütfen Goblen, Wicket'in düşük popülaritesine ve deneyimli JSF geliştiricilerinin düşük hevesine bir göz atın (daha da anlamlı olanı). Ve kontrast için, Rails, Grails, Django, Play'in başarısına bir göz atın! Çerçeve - hepsi eylem tabanlıdır ve programcıdan gerçek istek / yanıt ve webin vatansız doğasından saklanmaya çalışmazlar .

Benim için büyük JSF dezavantajı. IMHO JSF bazı uygulama türlerine (intranet, form yoğun) uygun olabilir, ancak gerçek hayattaki web uygulamaları için iyi bir yol değildir.

Umarım birisine ön uçla ilgili seçimlerinde yardımcı olur.

Akla gelen birkaç dezavantaj:

1. JSF bileşen tabanlı bir çerçevedir. Bunun, bileşen modeline uymakla ilgili doğal kısıtlamaları vardır.
2. AFAIK JSF yalnızca POST'u destekler, bu nedenle bir yere GET istiyorsanız, düz bir sunucu uygulaması / JSP yapmanız gerekir.
3. Çoğu bileşen ilişkisel veritabanları ve ön uç JavaScript gibi etki alanları üzerinde soyutlamalar sağlamaya çalışır ve çoğu zaman bu soyutlamalar "sızıntılı" ve hata ayıklaması çok zordur.
4. Bu soyutlamalar, küçük bir geliştirici veya belirli bir alanla (ör. Ön uç JavaScript) rahat olmayan bir kişi için iyi bir başlangıç ​​noktası olabilir, ancak birkaç katman ve bunları kullanan birçok kişi olduğundan performans için optimize etmek çok zordur. kaputun altında neler olup bittiğini çok az anlamalısınız.
5. Genellikle JSF ile kullanılan şablonlama mekanizmalarının web tasarımcılarının çalışma şekliyle bir ilgisi yoktur. JSF için WYSIWYG editörleri ilkeldir ve her durumda, tasarımcınız size yaşları dönüştürmek için harcayacağınız HTML / CSS verecektir.
6. EL ifadeleri gibi şeyler statik olarak kontrol edilmez ve hem derleyici hem de IDE'ler hata bulmada iyi bir iş çıkarmaz, bu nedenle çalışma zamanında yakalamanız gereken hatalarla sonuçlanırsınız. Bu, Ruby veya PHP gibi dinamik olarak yazılmış bir dil için iyi olabilir, ancak Java ekosisteminin katıksız şişkinliğine dayanmam gerekirse, şablonlarım için yazmayı talep ediyorum.

Özetle: JSF / servlet / bean boilerplate kodunu yazmaktan kaçınmak için JSF ile tasarruf edeceğiniz zaman, ölçeklendirmek ve tam olarak ne yapmak istediğinizi yapmak için x10 harcarsınız.

Benim için JSF 2.0'ın en büyük dezavantajı sadece JSF'nin öğrenme eğrisi değil, aynı zamanda yararlı bir iş yapmak için kullanmanız gereken bileşen kütüphaneleri. Gerçekten yetkin olmak için uğraştığınız şaşırtıcı özellik ve standart sayısını düşünün:

• Çeşitli enkarnasyonlarda HTML. Bilmene gerek yokmuş gibi yapma.
• HTTP - neler olduğunu anlayamadığınızda Firebug'u açmalı ve görmelisin. Bunun için bunu bilmelisin.
• CSS - Beğen ya da beğenme. Gerçekten o kadar da kötü değil ve en azından orada bazı güzel araçlar var.
• XML - JSF muhtemelen ad alanlarını bu dereceye kadar kullandığınız ilk yer olacaktır.
• Servlet Özellikleri. Er ya da geç bu pakette arama yöntemlerine gireceksiniz. Bunun dışında Facelet'lerinizin XHTML'ye nasıl dönüştüğünü bilmelisiniz.
• JSP (çoğunlukla JSF'de neden ihtiyacınız olmadığını biliyorsunuz)
• JSTL (yine, çoğunlukla eski çerçeveyle başa çıkmak için)
• Anlatım Dili (EL) çeşitli şekillerde.
• ECMAScript, JavaScript veya başka bir ad vermek istediğiniz adrestir.
• JSON - bunu kullanmasanız bile bunu bilmelisiniz.
• AJAX. JSF 2.0'ın bunu sizden gizlemek için iyi bir iş yaptığını söyleyebilirim, ancak hala neler olduğunu bilmeniz gerekiyor.
• DOM. Ve bir tarayıcı nasıl kullanıyor. Bkz. ECMAScript.
• DOM Etkinlikleri - tek başına bir konu.
• Java Kalıcılık Mimarisi (JPA), uygulamanızın herhangi bir arka uç veri tabanına sahip olmasını istiyorsanız.
• Java'nın kendisi.
• Siz varken JSEE.
• Bağlam Bağımlılık Enjeksiyonu belirtimi (CDI) ve JSF 2.0 ile nasıl çakıştığı ve JSF 2.0 ile nasıl kullanıldığı
• JQuery - Onsuz iyi geçinmeni görmek istiyorum.

Şimdi, işiniz bittiğinde, tescilli spesifikasyonlar, yani bileşen kütüphaneleri ve sağlayıcı kütüphaneleri ile devam edebilirsiniz:

• PrimeFaces (bileşen bileşen kütüphanem)
• RichFaces
• MyFaces
• IceFaces
• EclipseLink (JPA Sağlayıcım)
• Hazırda
• Kaynak

Ve kabı unutma! Ve tüm bu yapılandırma dosyaları:

• GlassFish (2, 3 vb.)
• JBoss
• erkek kedi

Peki - BU KOLAY YAPIYOR MU? Elbette, tek yapmanız gereken en basit etkileşimlere sahip en temel web sayfaları olduğu sürece JSF 2.0 "kolay" dır.

Basitçe söylemek gerekirse, JSF 2.0, bugün yazılım evreninde olduğu gibi yapıştırılmış teknolojilerin en karmaşık ve hantal karmasıdır. Ve kullanmayı tercih ettiğim hiçbir şey düşünemiyorum.

1. Deneyimsiz geliştiriciler genellikle acı veren yavaş uygulamalar yaratacak ve kod gerçekten çirkin ve bakımı zor olacaktır. Başlaması aldatıcı basittir, ancak iyi programlar yazmak istiyorsanız aslında öğrenmeye biraz yatırım gerektirir.
2. En azından başlangıçta sık sık bazı sorun üzerinde "sıkışmış" olacak ve internet üzerinde çalışmak balusc mesajları okumak için daha fazla zaman harcayacak :) Bir süre sonra daha az ve daha az olacak, ama yine de can sıkıcı olabilir.
3. Sorunun bilgi / hata eksikliğinden değil aslında bir hatadan kaynaklandığını öğrendiğinizde daha da can sıkıcı. Mojarra oldukça hatalıydı ve başka bir bileşen katmanı daha da fazla sorun yaratıyor. Richfaces şimdiye kadar yazılmış en büyük bok yazılım parçasıydı :) Şimdi sürüm 4'te nasıl olduğunu bilmiyorum. Daha iyi olan Primefaces var, ama yine de özellikle daha egzotik bileşenlerle hatalara veya özellik eksikliğine rastlayacaksınız. Ve şimdi Primefaces güncellemeleri için ödeme yapmanız gerekecek. Yani ben onun arabası söyleyebilirim ama özellikle 2.2 sürümü spec bazı sorunları düzelttikten sonra daha iyi oluyor. Çerçeve daha olgunlaşıyor ama yine de mükemmel olmaktan uzak (belki de daha iyi?).
4. Özellikle esnek bulmuyorum. Genellikle çok çok özelleştirilmiş bir şeye ihtiyacınız varsa ve bunu yapan hiçbir bileşen yoksa - biraz acı verici olacaktır. Yine ortalama geliştirici perspektifinden konuşuyorum - son teslim tarihleri, hızlı okuma öğreticileri olan ve takıldığınızda stackoverflow'u arama, çünkü gerçekten nasıl çalıştığını öğrenmek için zaman yok :) Çoğu zaman bazı bileşenler "neredeyse" neye ihtiyacınız var gibi görünüyor, ama tam olarak değil ve bazen istediğiniz bir şey yapmak için çok fazla zaman harcayabilirsiniz :) Kendi oluşturmak veya mevcut bileşen işkence daha iyi olup olmadığını değerlendirirken dikkatli olmak gerekir. Aslında gerçekten benzersiz bir şey oluşturuyorsanız JSF'yi tavsiye etmem.

Kısacası dezavantajlarım: Karmaşıklık, Çok düzgün bir gelişme değil, buggy, esnek değil.

Tabii ki de avantajları var, ama sorduğunuz şey bu değil. Her neyse, çerçeve ile olan deneyimim başkalarının farklı fikirleri olabilir, bu yüzden en iyi yolu sadece bir süre denemek için onun için olup olmadığını görmek için (sadece daha karmaşık bir şey - naif örnekler değil - JSF gerçekten parlıyor :) IMHO en iyi kullanım örneği JSF, CRM'ler gibi iş uygulamaları ...

"JSF, Denetleyici koduna girmeden kontrol edemeyeceğiniz veya değiştiremeyeceğiniz Görünüm katmanı HTML ve JavaScript çıktısını verecektir."

Aslında JSF size esneklik sağlar, standart / üçüncü taraf bileşenleri kullanabilir veya oluşturulanlar üzerinde tam kontrole sahip olan kendi bileşenlerinizi oluşturabilirsiniz. JSF 2.0 ile özel bileşenlerinizi oluşturmanız gereken tek bir xhtml'dir.

Java Server Faces uzmanı değilim. Ama IMHO ana dezavantajı sunucu tarafı olmasıdır. ASP.NET Web Formları, ASP.NET MVC, Java Sunucu Yüzleri, Struts, php çerçeveleri ve raylar çerçevelerinde ruby ​​gibi sunucu tarafı web sunum katmanı çerçevelerini öğrenmek ve kullanmaktan bıktım. Hepsine elveda dedim ve Angularjs ve TypeScript'e merhaba dedim. Sunum katmanım tarayıcıda çalışıyor. Php veya ASP.NET çalıştıran Windows IIS tarafından veya Linux üzerinde çalışan bir Apache web sunucusu tarafından sunulması önemli değil. Sadece her yerde çalışan tek bir çerçeve öğrenmem gerekiyor.

Sadece iki sentim.

JSF ile örnek bir proje geliştirdik (Üç haftalık bir araştırmaydı, bu yüzden bazı şeyleri kaybedebiliriz!)

Core jsf kullanmaya çalışıyoruz, eğer bir bileşen gerekirse PrimeFaces kullandık.

Proje navigasyonlu bir web sitesiydi. Menü tıklandığında her sayfa ajax aracılığıyla yüklenmelidir.

Site iki kullanım alanına sahiptir:

1. Izgaralı bir sayfa. Izgara ajax aracılığıyla yüklenir ve sıralama ve sayfalamayı desteklemelidir
2. Üç adımda sihirbaz sayfası. Her sayfada istemci tarafı doğrulaması (basit doğrulamalar için) ve sunucu tarafı ajax temel doğrulaması (karmaşık doğrulamalar için) vardır. Herhangi bir sunucu istisnası (servis katmanından) sonraki sayfaya gitmeden aynı sihirbaz sayfasında görüntülenmelidir.

Onu bulduk:

1. JSF görünüm durumunu düzeltmek için omniFaces'den bazı hack'ler kullanmanız gerekir. Birbirine ajax aracılığıyla sayfalar eklediğinizde JSF durumu bozulur. Bu JSF'de bir hata gibi görünüyor ve sonraki sürümlerde düzeltilebilir (2.3'te değil).
2. JSF Flow, ajax ile düzgün çalışmıyor (veya çalışamadık!) Bunun yerine asal yüz sihirbazı bileşenini kullanmaya çalışıyoruz, ancak istemci doğrulaması standart JSF akış standardı değilken desteklenmiyor ve ortalama görünüyor.
3. JqGird gibi bazı jQuery bileşenlerini kullanırken ve JSON sonuçlarını yüklemeniz gerekiyorsa, saf sunucu uygulaması kullanmanız önerilir, JSF sizin için hiçbir şey yapmaz. Dolayısıyla, bu tür bileşenleri kullanırsanız, tasarımınız JSF'ye sığmaz.
4. Ajax tamamlandığında bazı istemci komut dosyaları yapmaya çalışıyoruz ajaxCompleteve PF 4'ün kendi ajax etkinliklerini uyguladığını tespit ettik. Bazı jQuery bileşenleri vardı ve kodlarını değiştirmemiz gerekiyor.

Yukarıdaki örneği Ajax olmayan bir şekilde değiştirirseniz projeyle (veya en azından daha az ajax projesiyle) değiştirirseniz, yukarıdaki sorunların çoğuyla karşılaşmazsınız.

Araştırmamızı şöyle özetliyoruz:

JSF tamamen ajax temel web sitesinde iyi çalışmıyor.

Tabii ki JSF'de bazı projelerde çok yardımcı olabilecek birçok güzel özellik buluyoruz, bu yüzden proje ihtiyaçlarınızı düşünün.

Lütfen JSF avantajlarını incelemek için JSF teknik belgelerine bakın ve bence JSF'nin en büyük avantajı @BalusC ;-) 'den TAM VE BÜYÜK destek.

Benim için JSF'nin en büyük eksikliği programlı (dinamik olarak) oluşturulan sayfalar için yetersiz destek.
Sayfanızı dinamik olarak java kodundan oluşturmak istiyorsanız (sayfa bileşeni modeli oluşturun). Örneğin, WYSIWYG web sayfası yapıcısı üzerinde çalışıyorsanız. Bu kullanım durumunun yeterli dokümantasyonu genellikle mevcut değildir. Denemeniz gereken birçok nokta vardır ve gelişim yavaştır. Birçok şey beklediğiniz gibi çalışmaz. Ama genellikle olası bir şekilde kesmek.
İyi olan şey, JSF'nin felsefesinde veya mimarisinde sorun olmamasıdır. Yeterince ayrıntılı değil (bildiğim kadarıyla).

JSF 2, bileşen geliştirmeyi kolaylaştıracak Kompozit Bileşenleri getirdi, ancak dinamik (programatik) yapıya destekleri çok zayıf. Sessiz karmaşık ve neredeyse belgelenmemiş dinamik Kompozit Bileşen yapısının üstesinden gelirseniz, birkaç Kompozit bileşeni biraz daha derine yerleştirirseniz, bazı istisnalar atmadan çalışmayı bırakırlar.

Ancak JSF topluluğunun bu eksikliklerin farkında olduğu anlaşılıyor. Bu iki
hatadan görebileceğiniz gibi onlar üzerinde çalışıyorlar http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

Durum en azından şartnameden bahsediyorsak JSF 2.2 ile daha iyi olmalıdır.

Primefaces / JSF deneyimimin son birkaç ayı hakkında yorumda bulunmak:

• Bileşenleri "raf dışında" kullanabiliyorsanız, sanırım korkunç değil.
• Ancak, dışarı çıktığınızda ve özel kullanıcı arayüzlerine ihtiyaç duyduğunuzda iyi oynamaz. - Örneğin, projemiz için Twitter'ın önyüklemesini kullanmamız gerekiyordu. (Asal önyükleme önyükleme değil).
  • Artık sayfalarımız şu şekilde çalışıyor:
    • Sayfa yüklenir.
    • Kullanıcı ajax işlevselliğine sahip bir Primefaces ile etkileşime girer
    • Bootstrap'ın javascript bağları kopuyor
    • Her şeyi yeniden hatırlatmak için ekstra javascript çalıştırıyoruz

JSF'nin javascript yazmaktan kaçınma sözü, Primefaces kullanmıyor olsaydık daha fazla javascript yazmaya dönüştü - ve bu javascript, Primefaces'in kırdığı şeyi düzeltmektir.

Bu bir zaman lavabo - tekrar "raf kapalı" şeyler kullanmak sürece. Ayrıca Selenium ile çalışmak zorunda kalırken gerçekten çirkin (Primefaces). Her şey yapılabilir - ama yine de - çok fazla zaman var.

Bir UX / tasarım ekibiyle çalışıyorsanız ve kullanıcı arayüzünde hızlı bir şekilde yinelenmeniz gerekiyorsa kesinlikle bundan kaçının - jquery / düz HTML yazarak veya tepki / açısal bakarak zaman kazanabilirsiniz.

JSF'nin birçok avantajı var, soru dezavantajlı olmak üzerine birkaç nokta eklememe izin verin.

Bir web projesini bir zaman çerçevesinde uygulamak için pratik bir senaryoda, aşağıdaki faktörleri göz önünde bulundurmanız gerekir.

• Ekibinizde her senaryoya uygun en iyi kontrolleri önerebilecek kadar kıdemli üyeniz var mı?

• İlk öğrenme eğrisini karşılayacak bant genişliğiniz var mı?

• Ekibinizde
  geliştiriciler tarafından üretilen JSF malzemelerini inceleyebilecek yeterli uzmanlığa sahip misiniz ?

Sorular için cevabınız 'Hayır' ise, sürdürülemeyen bir kod tabanı elde edebilirsiniz.

JSF'nin tek bir dezavantajı vardır: "JSF" geliştirmeye başlamadan önce web geliştirme, çekirdek java ve ön uç mimariyi açıkça anlamalısınız.

Günümüzde "yeni" JavaScript çerçeveleri sadece "JSF" bileşen tabanlı modeli kopyalamaya / yapıştırmaya çalışın.

Spring MVC, Wicket, Goblen vb.Gibi tüm "ana" çerçeveler arasında, Java EE'nin kompozit bileşenleri ile JSF'si, sunulan en ayrıntılı sunum katmanı ve bileşen odaklı teknolojidir. HybridJava tarafından sağlanan çözümlere kıyasla biraz hantal ve eksik.