I shouldn’t care about this because I don’t use JavaFX. But it bugs me so I’ll rant a bit.
A while ago (probably around version 1.2) the language caught my eye. I especially liked its literal declarative syntax for creating tree structures and data binding. I thought I heard that Oracle was discontinuing JavaFX but version 2.0 is in beta. I now realize that it is only JavaFX Script that is canned — JavaFX is alive and well. (JavaFX Script lives on in visage.) The features of JavaFX are available as APIs that can be used from Java or other languages on the JVM. This is a good architecture.
Writing procedural code to construct a scene graph looks as ugly and cumbersome as JavaFX Script was elegant. To “fix” this problem FXML was invented. FXML is a XML dialect for declaring a scene graph.
From what I have read there are two main motivations for using XML:
- Familiarity — from the getting started with FXML page: “One of the advantages of FXML is that it is based on XML and is therefore familiar to most developers”
- No need to compile (presumably changes to FXML are made on the fly without having to restart the app). This is fair but doesn’t imply that XML is a good answer.
The familiarity argument is false. It confuses syntax with semantics. Yes many developers are familiar with the syntax of XML but just because someone knows XML Schema doesn’t mean they will have any understanding of XSLT. One must still learn the semantics of FXML and that’s the hard part.
Here is what I think is bad about FXML:
- XML is just not a convenient language for source code. It is verbose and cumbersome. It has lots of little things that get in the way such as entity references. New programming languages including declarative ones should not be XML.
- Use of character case in element names to distinguish between instances and properties is ugly.
- Properties can be represented by either XML attributes or XML elements. This is practical but confusing and stems from using the wrong tool for the job (XML).
- Type coercion.
And a few things I liked:
- Use of XML processing instructions.
- Built-in support for string translation. But it doesn’t go far enough. It should eliminate the need for maintaining resource property files and support format substitutions.
- Concept of static properties.
I created a blog on dev2dev. I’ll put my work related stuff there and continue to write about my personal projects and interests here.
The WLS 10.3 Tech Preview is available now. I worked on the WLS Console so I wrote about how best practices in web app presentation layer helped improve performance.
I have never been a fan of JavaServer Pages (JSP) but I have used them on a few projects. When JSP Documents (JSPs with XML syntax) were added in version 1.2 I thought if you had to do JSP then JSP Documents were the way to go. I prefer the uniform XML syntax to all the crazy syntax in JSP Pages.
Recently I’ve been focused on producing valid HTML. Perhaps too focused. A while back I bought into the XHTML is the wave of the future so we should all start using XHTML now hype. Now I see that serving good old HTML 4.01 is the best choice. See Sending XHTML as text/html Considered Harmful for why. My old habit of using XML style empty elements such as <br /> was getting me into trouble with HTML validators. The HTML Validator Firefox extension (using Tidy) will flag the slash in red even though it doesn’t give a written error. The W3C validator gives an error if the /> results in character data where it isn’t allowed. This can happen on the empty meta tag.
After reading about empty elements and what <br /> really means in HTML I wondered how is it even possible for a JSP Document to generate valid HTML.
Because JSP Documents must be valid XML an empty tag like meta must end with /> (or </meta> which doesn’t help) and this results in a validation error because character data is not allowed within the head tag.
This really surprised me. I looked and looked for a way to tell the JSP Document to output valid HTML but couldn’t find one. If you know of a way please tell me. The jsp:output action gives you control over the DOCTYPE and XML declaration. I was expecting it to also let you specify that the output method is HTML just like XSLT does. But it doesn’t.
Unless I’m missing something obvious JSP Documents should come with a warning – “Warning JSP Documents don’t output valid HTML by default”. I wonder why the oversight. Did the JSP designers buy into the XHTML hype as well?
There are two ways I know of to work around this issue. One is to use a CDATA section. For example:
<![CDATA[<meta http-equiv="Content-Type" content="text/html">]]>
The other is to use a tag library such as Struts HTML that knows how to output either HTML or XHTML. But this doesn’t help with the meta tag.
Even with this minor snag I still prefer JSP Documents to JSP pages but that isn’t saying much.
Sometimes things seem so obvious once you learn them the hard way that you wonder why there aren’t big signs everywhere making it clear from the start. The HTML button element is useless when used with a server side controller. I got my information on the button element from the HTML specification and was happily using it with Firefox as my client. (I have found Firefox with key extensions to be an indispensable tool in developing web applications.) When I tried my app with IE 6 I quickly found that my servlets couldn’t distinguish which button was pressed.
The thing that originally attracted me to the button element is that it allowed specifying the value of the button independent of the button label. The input element of type button has the problem that the label can’t easily be used to distinguish which button was pressed when the button label is localized. You could have the controller test the button value using the localized label string but yuck! In general internal tokens and display text should be kept separate.
The general requirements for using buttons are:
- Multiple submit buttons on a form and it must be possible to distinguish which was pressed.
- The button text must be localizable so you can’t rely on the button label to distinguish the button.
I canâ€™t use <button name=”submit” type=”submit” value=”v1″>Label</button> because IE returns the content “Label” rather than the value “v1″ and because all buttons of type submit are returned so you canâ€™t tell which button was pressed. I also canâ€™t use <input name=”submit” type=”submit” value=”Label” /> (where multiple buttons use the same name) because the buttons cannot be reliably distinguish. The value is “Label” in English but may be different when localized.
I see two options and both use the input element of type button. One is to use a different name for each submit button. The draw back is slightly messy code on the back end where you have to check for the presence of different parameters. The second option and the one I use is to encode the intended value of the button in the name.
For example: rather than
<button name=”submit” type=”submit” value=”v1″>Label</button>
I would use
<input name=”submit_v1″ type=”submit” value=”Label” />
In the controller servlet I have common code to look at the parameter prefix “submit_” and extract the button value.
Both approaches have their problems. To implement the first in a common controller servlet would require that the controller know about all the names that could be used on submit buttons. With the second approach the controller pollutes the namespace of form properties.
Developers accustomed to internationalizing Java [web] applications are very familiar with ResourceBundle, MessageFormat and property files. The articles Localization and Internationalization with StringTemplate and Web Application Internationalization and Localization in Action give a good introduction to how StringTemplate can be used to do i18n but they donâ€™t explain how to get the full set of benefits we derive from ResourceBundle, and MessageFormat. In this article I describe how StringTemplate can leverage ResourceBundle and remove the need for MessageFormat in the presentation layer.
For many years I enjoyed working on the Windows platform writing applications in C++, Win32, MFC and ATL/WTL. I was not an early Java adopter. I had taken a Java course but continued to work in C++. More and more of my friends had made the switch to Java and told me how much they liked it.
In 2002 I started programming in Java. In 2005 I took a course on C# and .NET as well as doing my own learning. I only got a little hands on experience with it because I was doing to much management.
There are many things about C# that I like more than Java:
- The verbatim strings: @”string that can span lines”
- Unsigned integers
- Structs for defining your own value types
- How types are unified so that value types can be used as objects (Boxing and Unboxing). Yes, Java has this now but the C# way seems more unified.
- The namespace concept is a little better than packages.
- Delegates and events
I can take or leave the C# preprocessor. I’m not too fond of attributes or annotations. They have their uses (and abuses) I just haven’t had a strong need for them. I didn’t work with the .NET library enough to say if I like it better than Java. I don’t like ASP.NET because it doesn’t seem as flexible as the Java layering of Servlets and JSP. I could be wrong about that.
The reason I like Java better, and it out weights all of C#’s advantages, is the perceived attitude of the Java community. When I look around at what is going on in the Java community I see many people working on all kinds of interesting things. There is an attitude of “Hey that would be cool, I’ll build it”. When I look around at the .NET community I get the sense that people are waiting around for Microsoft to provide all the infrastructure.
I know this is a gross generalization. I’m sure there are people doing interesting things with .NET and more importantly people who are happy to be working with .NET. This is just how I perceive things. As a data point there are about 5,000 C# projects on SourceForge and 23,000 Java projects. This could be because Java has been around longer or perhaps SourceForge is not the place to look for .NET projects.