#221 JSF Rules

[Neil Venn]

I have created a set of XPath rules for JSF files that enforce some of our project standards. Would you be interested in accepting them as a contribution, at least as further examples?

The rules include:

<ruleset name="Custom JSF rules" language="jsp" <rule="" name="DontHardCodeLabels" message="Do not hard code the values used for labels - reference a Managed Bean."/>
<rule name="AvoidHardCodedValues" message="Avoid hard coding the values used for value attributes - reference a Managed Bean."/>
<rule name="AvoidPixelMeasurements" message="Avoid using pixels for sizing - use ems instead."/>
<rule name="AvoidHTMLTags" message="Avoid using HTML tags within JSF."/>
<rule name="IncludeResourceHistory" message="Include resource history and description in a header along with parameters for components - use &lt;h1&gt; and &lt;p&gt;."/>
<rule name="NoInlineStyle" message="Do not use class or inlineStyle within JSF - use styleClass."/>
<rule name="AvoidShortDesc" message="Do not assign a shortDesc attribute as a matter of course - only if required by Use Case."/>
</ruleset>

Regards
Neil Venn
http://www.seabright-consulting.co.uk

[Ryan Gustafson]

Logged In: YES
user_id=342470
Originator: NO

Yes, please attach the patch. You should just attach the patch from the beginning, let's us avoid this back and forth just to get started at looking at it. :)

[Romain PELISSE]

Logged In: YES
user_id=1679130
Originator: NO

Hi Neal,

Yes i think this would be a very nice contribution. There is an other path in the tracker about JSF files, maybe you should look at it ?

The other patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1803573&group_id=56262&atid=479923

[Neil Venn]

Custom JSF Rules

[Neil Venn]

Logged In: YES
user_id=2035408
Originator: YES

<rule name="DontHardCodeLabels" message="Do not hard code the values used for labels - reference a Managed Bean."/>
- On our project we externalise label, captions, etc to enable I18N
<rule name="AvoidHardCodedValues" message="Avoid hard coding the values used for value attributes - reference a Managed Bean."/>
- Generally in JSP the values displayed will be found in the model - in a managed bean
<rule name="AvoidPixelMeasurements" message="Avoid using pixels for sizing - use ems instead."/>
- Using ems rather than pixel measurements is better for scaling dependent upon screen resolution and user font preferences
<rule name="AvoidHTMLTags" message="Avoid using HTML tags within JSF."/>
- HTML tags are device dependent (must be an HTML Web browser) - on our project we use a component library (Apache MyFaces Trinidad) which dynamically selects the renderer dependent upon device type
<rule name="IncludeResourceHistory" message="Include resource history and description in a header along with parameters for components - use &lt;h1&gt; and &lt;p&gt;."/>
- Our project standards require all pages to be a Facelets <ui:composition> where all code outside of the <ui:composition> is "lost" - we take advantage and include HTML comments for resource history
<rule name="NoInlineStyle" message="Do not use class or inlineStyle within JSF - use styleClass."/>
- inlineStyle may be device dependent - using styleClass delegates responsibility to the Trinidad CSS (which is somehow merged)
<rule name="AvoidShortDesc" message="Do not assign a shortDesc attribute as a matter of course - only if required by Use Case."/>
- shortDesc (hover help) is useful but it's use has not been specified on our project

File Added: custom-jsf.xml

[Ryan Gustafson]

Logged In: YES
user_id=342470
Originator: NO

Hi Neil,

I looked at the patch. There's a few things we'd need before committing these rules:
1) The rules should have better descriptions. The messages should be terse one sentence format like you provide, however the description should include the same as well as details of how/why the rule should be followed (e.g. justification/reasoning). The Eclipse IDE lets you lookup this more details rule information when you trigger a violation, so it's helpful to explain to the user why a rule is a good idea. It also helps people decide if they want to use a particular rule when reading thru the entire list of Rules on the PMD website.
2) The rules need examples. All the PMD documentation on rules is generated from this XML markup, so it needs to be complete.
3) We need test cases for the rules. At least one positive and one negative test case. We also manage most of the test cases using XML files, for example:

http://pmd.svn.sourceforge.net/viewvc/pmd/trunk/pmd/regress/test/net/sourceforge/pmd/rules/basic/xml/AvoidUsingHardCodedIP.xml?view=markup

If you can fix these things up, then we can reconsider applying the patch.

Thanks,
Ryan