]
Jeff Cantrill commented on JBIDE-21667:
---------------------------------------
Working on replacing the first example with the code that exists from the rest client
ResourceKind.pluralize. I don't believe we do this in many places but its probably
not worth the effort at the moment to do an extensive analysis of the code base.
The second example is misleading since we are dynamically associating a declared id with
an observable property. I don't see how this can be changed since this class
generically handles various resource types. We rely on the plugin.xml id to match the
kind and resource we wish to display in the tabbed view.
Make computing property names more conspicuous
----------------------------------------------
Key: JBIDE-21667
URL:
https://issues.jboss.org/browse/JBIDE-21667
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: openshift
Affects Versions: 4.4.0.Alpha1
Reporter: Viacheslav Kabanovich
Assignee: Jeff Cantrill
Labels: code_quality
Fix For: 4.4.0.Alpha1
Created as follow up to JBIDE-21590.
Property names of resources are computed in two places.
- From kind of resource in ResourcesUIModel:
{code}
private static String getProperty(String kind) {
return StringUtils.pluralize(kind.toLowerCase());
}
{code}
- From tab id in OpenShiftResourcePropertySection.setInput :
{code}
String property = org.apache.commons.lang.StringUtils.right(id, id.length() -
id.lastIndexOf(".") - 1);
{code}
Maybe, there are more places that transform something to property name, I am not aware of
them yet. But, imho, even if they are only 2 places and no other will appear, they are too
much related to be separate and hidden in the depth of implementation. I suggest a utility
that will encapsulate all manipulations with resource property names, (being in an
internal package it may have public methods without getting into API), and describe in
Java docs in details how it works. Tests for this utility may help to find early if some
modification breaks consistency of related names.