FXMLLoader <?import?> checking code conventions too much?

[Martin Sladecek]

Currently, we use case to distinguish between newly created objects 
(upper-case class name) and properties (lower-case). Otherwise, it would 
not be clear when there's e.g. a text property and text class if we 
should set a property called text or create new text object and try to 
assign it to the default property. The same problem with static setters.
Is "hello.text.text" a fully qualified name of text class in or "text" 
static setter of a hello.text class?

I guess we could define some order in which we would try out this 
options in the current context, but SB will have a problem since they 
use static mode which can be used without having the classes on the cp.

-Martin

On 5.6.2014 20:57, Stephen F Northover wrote:
> I see no reason why we should enforce this.  Martin, any idea?
>
> Steve
>
> On 2014-06-05, 12:05 PM, Guillaume Anctil wrote:
>> Hi,
>>
>> on a project I work on, the code convention does not follow the Java
>> standard and class names start with a lower case 'c': "cSomeClass.java"
>>
>> In the <?import ?> parsing of the FXMLLoader, the loadType function 
>> looks
>> like this:
>>
>> int i = name.indexOf('.');
>> int n = name.length();
>> while (i != -1
>>      && i < n
>>      && Character.isLowerCase(name.charAt(i + 1))) {
>>      i = name.indexOf('.', i + 1);
>> }
>>
>> if (i == -1 || i == n) {
>>      throw new ClassNotFoundException();
>> }
>>
>> String packageName = name.substring(0, i);
>> String className = name.substring(i + 1);
>>
>>
>> This causes a ClassNotFoundException on our custom controls because 
>> of the
>> lowercase check.
>>
>> I was wondering if a simple:
>>
>> int i = name.lastIndexOf('.');
>>
>> Instead of the lowercase check could be viable. The 
>> ClassNotFoundException
>> would still be thrown later on, when trying to actually load the class.
>>
>> Is there a reason that I don't see why the convention _must_ be 
>> upheld in
>> this case?
>>
>> Thanks.
>