Guillaume, if you feel strongly about this, please file a JIRA. Thanks!


On 2014-06-05, 4:29 PM, Martin Sladecek wrote:
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).


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.


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.


On 5.6.2014 20:57, Stephen F Northover wrote:
I see no reason why we should enforce this.  Martin, any idea?


On 2014-06-05, 12:05 PM, Guillaume Anctil wrote:

on a project I work on, the code convention does not follow the Java
standard and class names start with a lower case 'c': ""

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?


Reply via email to