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

[Martin Sladecek]

Maybe some special tags can solve the problem, like
<fx:property name="TEXT">abc</fx:property>
<fx:new class="hello.text" text="abc"/>
<fx:static class="text" property="TEXT">abc</fx:static>

They could be used in cases where the class name violates the 
restrictions we have for property/object tags. FXML version and SB will 
have to be update though, which means such fxml will not be compatible 
with older versions. This is definitely something we should do only on 
major release (9).

-Martin

On 5.6.2014 22:21, Stephen F Northover wrote:
> Seems like we can't/shouldn't fix this.  We can at least make sure it 
> is documented.
>
> Steve
>
> On 2014-06-05, 4:19 PM, Martin Sladecek wrote:
>> 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.
>>>
>>
>