Difference between revisions of "Globalyzer 5 Java Rules"

From Lingoport Wiki
Jump to: navigation, search
(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

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.

RS with Class or Variable Type.png

  • 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


Gz 5 Result.png