Guillaume, if you feel strongly about this, please file a JIRA. Thanks!
Steve
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).
-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.
