Difference between revisions of "Globalyzer 5 Java Rules"
(→Result) |
(→Result) |
||
Line 55: | Line 55: | ||
== Result == |
== Result == |
||
+ | When the rules are applied, |
||
+ | * the string passed to the Dbg variable ''setText'' method is filtered out and does not show up as a candidate issue |
||
+ | * the string passed to the Label variable ''setText'' method is detected and does show up as a candidate issue |
||
+ | |||
+ | |||
[[File:Gz 5 Result.png]] |
[[File:Gz 5 Result.png]] |
Revision as of 17:50, 27 October 2015
Contents
Introduction
Globalyzer 5 introduces new types of rules based on a improved, in-depth i18n parsing.
Say that you want to filter strings passed as parameters to a method called get, which is a fairly common method name. With Globalyzer 5, you can specify the class name on which the rule should be applied. Let's say the I18nUtil class and the UIUtil both have a 'get' method. You can specify a string filter method on get for variables of type I18nUtil and you can specify a string detection method for variables of type UIUtil. Static methods are also handled. You can also have an overarching get filter for all classes if necessary in your code, as opposed to listing all the class types on which a detection or a filter must apply.
User Interface
Globalyzer 5 Java allows for class names to be specified as part of the rules. The following UI shows how to configure a new String Method Filter
for the smalljava
illustrative rule set.
- Name: That the name of the rule. It could be something like
i18n get
- Pattern: That is the pattern which would match the method name. It could be something as simple as
get
- Class or Variable Type(s): This is a pattern which would match the class name. It could be something like
company.project.util.I18nUtil
- Description: The description or the reason for this filter could be something like "I18nUtil get method string parameters do not need to be externalized into a resource bundle for i18n purposes"
- Help Page: The link to a more verbose help page which may indicate the context and the reason for the filter.
Type of Rules
Example
Code Snippet
import company.project.util.Dbg; // A fully qualified class name import company.project.ui.*; // Label is in the company.project package. [...] Dbg dbg = Dbg.getInstance(); Label lbl = new Label(); [...] dbg.setText("{0}: {1} action taken."); [...] label.setText("Menu");
This snippet of code does have strings.
The class company.project.Dbg
is a debug class and the text method puts the String parameter into a database for support purposes. That string is not visible to the end user. In that instance, the setText
method on a variable of type company.project.util.Dbg
should be filtered.
The variable lbl of class company.project.ui.Label
represents a text area in the User Interface and the setText
method passes a user visible string. The string Menu
passed to this setText
method should be flagged: It needs to be externalized out of the code into a resource bundle.
Rule
The String Method Filter rule would be configured the following way:
- Name: Debug setText
- Pattern: setText
- Class or Variable Type(s): company.project.util.Dbg
- Description: String parameters passed to the Debug setText must not be externalized and translated.
- Help Page: <blank>
The String Method Detection rule would be configured the following way:
- Name: User Interface Label setText
- Pattern: setText
- Class or Variable Type(s): company.project.ui.Label
- Description: String parameters passed to the Label setText method must be externalized and translated.
- Help Page: <blank>
Result
When the rules are applied,
- the string passed to the Dbg variable setText method is filtered out and does not show up as a candidate issue
- the string passed to the Label variable setText method is detected and does show up as a candidate issue