jsf組件不顯示

自從我上次查看三個主要JSF組件庫的質量以來已經有一段時間了。 在2009年12月，我開始比較RichFaces，Primefaces和ICEfaces的整體軟件質量 。 從那時起，事情發生了變化，從現在開始，我想重新評估和更新它。 我在2009年使用的工具仍然有效，但是工具套件的設置有些棘手，我只是在浪費時間做這些事情。 由于最近對FAMIX 2.1出口商的需求，我再次查看了inFusion 。 它為GlassFish City帖子（ 第一 ， 第二 ）發揮了作用。 但是除此之外，還有更多。 它是幫助評估系統質量的工具。 它專注于體系結構和設計質量，并允許數百萬個LOC系統的質量保證。

在我向您介紹inFusion可以為您做些什么之前（隱式地通過分析候選者，我不做廣告：-D）我必須感謝Radu Marinescu博士和Adrian Trifu博士提供了完整的功能測試，以及他們的產品評估許可證給我。 沒有這個，我將無法像今天一樣向您展示偉大的軟件城市或有關開源項目質量的博客！ 請查看這篇文章下面的資源，以獲取有關inFusion及其背后原理的更多鏈接。 如果您希望我完成產品發布，請在評論中告訴我！

本文重點
?
PrimeFaces ， RichFaces和ICEfaces是三個最常用的JSF組件庫。 看著使用它的社區，我總是感覺到有一場比賽是唯一的。 這絕對是由PrimeFaces領導推動的。 您可以考慮他在做什么，是否喜歡。 在這篇文章中，我不是要怪罪任何人的政治正確行為，而是要通過查看交付的質量，將其重新歸因于不同項目的一些客觀觀點。

介紹
?
在獲得結果之前，我需要向您介紹一些基礎知識。 如果您覺得自己已經看過足夠多的內容，并且下面的所有內容都很簡單，請隨時處理單個結果。 InFusion以圍繞但不以指標為中心的方式評估軟件質量。 因此，它引入了一種特殊的質量模型（QM），該模型通過一些可測量的特征來表達軟件系統的質量。 質量本身可能意味著很多不同的東西（外部，過程，內部質量）。 inFusion將質量的概念定義為“內部質量”，即系統的體系結構和設計的質量。 inFusion QM定義了兩個分解層：“質量屬性”層和“設計屬性”層。 較高級別的概述包含一組五個“設計屬性”，它們是基于幾個眾所周知的“設計原理”（例如DRY原理和Demeter定律）構建的。 牢記這些原則，inFusion衡量與大多數這些原則和設計規則的偏差。 通過考慮“難聞的氣味”，可以對這些偏差進行量化。 所有這一切與正確的映射（可以在inFusion本身或下面提到的出版物中查找）一起計算出“質量赤字指數”（QDI）。 QDI是一個向上的，向上的無限制值，它是對分析的系統的設計質量相對于系統總體大小的“不良”度量。

除了這些高級措施之外，inFusion還提供可視化效果，例如在不同級別（包，繼承，類和模塊）上的耦合，封裝和設計缺陷。
我也喜歡指標金字塔。 它以某種方式回答了“我的項目與其他項目相比如何？”的問題。它會生成一個金字塔，顯示您項目的關鍵指標，并與這些數字的行業標準范圍進行比較。它分為三個不同的類別（繼承性，大小）和溝通）。

金字塔概述

數字表示比率。 顏色表示比率符合行業標準范圍的位置（來自眾多開源項目）。 每個比例
是綠色（接近平均范圍），藍色（接近低范圍）或紅色（接近高范圍）。 生成的數字有兩個目的。 首先，它們使您可以在多個維度上將代碼庫與其他代碼庫進行比較。 其次，這些數字表示您可能要花費很多精力來改善代碼衛生和設計的地方。 但是，您必須根據上下文理解這些數字。

PrimeFaces（QDI：30,8）

PrimeFaces上的設計缺陷

成立于2009年，擁有不斷增長的用戶群。 發展負責人是?a？atay?ivici 。 以下分析是在最新的開發主干上進行的。

系統中的代碼行總數為44.123（包括注釋和空格）。 素面的質量缺陷指數是30,8。
InFusion檢測到12個不同的設計缺陷。 影響最大的是24個數據類和23個拒絕父母遺贈類。 其次是三個神級。 有很多重復缺陷，但沒有圈依賴。

類層次結構往往又高又寬 （即，繼承樹傾向于具有許多深度級別和基類以及許多直接派生的子類）

類傾向于包含平均數量的方法。 以相當細粒度的程序包進行組織（即每個程序包幾個類）

方法往往相當長，并且具有平均的邏輯復雜性 ; 從其他幾個類別中調用許多方法 （高耦合強度）（低耦合色散）；

PrimeFaces的度量標準金字塔

鑒于事實是這是一個組件庫，因此可以接受NDD（直接后代的數量）和HIT（繼承樹的高度）。 復雜的繼承使理解和預測行為更加復雜。 更深的樹構成更大的設計復雜性，因為涉及更多的方法和類，但是會增強繼承方法的潛在重用。 NOM是指方法的數量。 這是一個簡單的度量標準，它顯示了一個類的復雜性，即職責，而不是方法的大小。

RichFaces（QDI：9.1）

RichFaces上的設計缺陷

??
RichFaces于2005年底起源于Ajax4jsf。它是JBoss上廣泛使用的組件庫。
分析使用的是最新的開發路線，僅包括核心和組成部分。

系統中的代碼行總數為134.037（包括注釋和空格）。

RichFaces的質量赤字指數為9.1。

類層次結構往往較高且具有平均寬度 （即，繼承樹傾向于具有許多深度級別和基類以及幾個直接派生的子類）

類傾向于包含平均數量的方法。 并且以相當細粒度的程序包組織 （即每個程序包很少的類）；

方法趨于：在長度上是平均的 ，并且具有邏輯上的平均復雜度 ； 從其他幾個類別中調用許多方法 （高耦合強度）（低耦合色散）；

RichFaces的度量標準金字塔

通常，RichFaces在層次結構方面做得更好。 僅繼承樹的高度接近高范圍。 通訊類的NOM也接近很高。 其余的在定義的范圍內，這實際上導致了良好的QDI。

ICEfaces（QDI：16.6）

ICEfaces上的設計缺陷

ICEfaces從……開始存在。分析是針對3.1.0標簽進行的，其中包括核心，推入和組件。
系統中的代碼行總數為153.843（包括注釋和空格）。

ICEfaces的質量赤字指數為16.6。
InFusion檢測到16個不同的設計缺陷，包括35個數據類，13個上帝類，20個SAP Breakers，其次是21個拒絕父母遺贈類和35個循環依賴項。

類層次結構往往很高且具有平均寬度，即繼承樹傾向于具有許多深度級別和基類，以及幾個直接派生的子類）

類傾向于包含平均數量的方法。 以相當細粒度的程序包進行組織（即每個程序包幾個類）。

方法往往相當長，并且具有平均的邏輯復雜性 ; 從其他幾個類別 （低耦合色散）中調用許多方法 （高耦合強度）。

ICEfaces的度量標準金字塔

不出所料，我們還發現了接近高的繼承樹高度。 除此之外，只需要擔心方法的數量。

解釋
?
這種分析與我幾年前所做的分析不同。 我跳過了所有顯而易見的內容（例如，checkstyle，findbugs），因為每個人都在這里使用不同的方法，對我來說，這通常不是系統質量的可比基礎。

在這里得出結論之前，讓我首先表示，結果并不表示您應該使用或不使用任何候選人的天氣。

系統設計質量不會影響使用它們生成的代碼的質量。 同樣，它也不應該成為候選人是否穩定或沒有漏洞的任何指標。 它僅關注開發產品的開發人員可能面臨的問題。 從長遠來看，這也可能會對您作為用戶產生影響。 由于設計問題昂貴，頻繁且不可避免。 因此，在代碼庫中存在許多質量缺陷可能會影響團隊隨時間推移能夠提供的新功能的數量，或者修復錯誤的時間會大大增加。 最后，與一個小團隊一起，這可能會導致產品結束。

就繼承而言，所有三個候選人都有相同的問題。 這樣做的原因是，它們都是為客戶提供良好功能的框架。 結合候選人的人數，PrimeFaces在進行分析時似乎存在最大的設計缺陷。 在質量方面，RichFaces領先于其他兩個。 這是我希望從RedHat社區驅動的項目中看到的。 另一個指標是，工作中的軟件社區至關重要，技能嫻熟且踢腿！ ICEfaces是唯一具有循環依賴性和重復代碼數量異常的項目。 因此，他們可能最終不得不修復相同的錯誤幾次。

我在這里沒有任何要付出的代價，但是想向RichFaces團隊致以祝賀，感謝他們提供高質量的產品！ 保持良好的工作！

這是您的RichFaces-City（核心和組件）。 綠色區域是舊的org.ajax4jsf。*平房:)

富人城

資源：
灌輸產品頁面
實踐中的面向對象度量 （Springer，2006年） iPlasma：面向對象設計質量評估的集成平臺 （PDF） 實用設計質量評估 （幻燈片分享演示）

參考： JSF組件庫–質量不只是零缺陷。 來自我們的JCG合作伙伴 Markus Eisele在Java的企業軟件開發博客中。

翻譯自: https://www.javacodegeeks.com/2012/08/jsf-component-libraries-quality-is-more.html

jsf組件不顯示

總結

以上是生活随笔為你收集整理的jsf组件不显示_JSF组件库–质量不只是零缺陷的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。