Category Archives: Java

JavaFX’s FXML a big step backwards

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.

What FXML shows is the importance of having a literal representation for data. It looks like FXML could be used to build arbitrary heterogeneous object trees which is generally useful. What I think is really needed is an object literal syntax for Java similar in concept to what JavaScript has. The syntax used by JavaFX Script would make a great starting point.

JSP Documents and valid HTML

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:

  <head>
    <![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.

HTML button is not useful

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.

My testing shows that in IE 6 all <button type=”submit”> values are submitted any time the form is submitted. In addition the content is used as the value rather than the value attribute. I searched for more information to see if I was missing something. I wondered how could IE get it so wrong and if it was wrong how could I have not heard about this problem before. Most of the articles I found about button talked about how great it was because it gave so much control over the content and style of the button. The best evidence I found that button was indeed broken in IE came from comments to the article “Push my button”. Standard vs. quirks mode makes no difference. I have not tested IE 7 yet. I did notice that some articles say that the button element is just for use with JavaScript but they don’t say it is because of the IE bug.

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.
  • The solution must not require JavaScript. This would break the principal of progressive enhancement.

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.

The main thing you loose out on is the styling ability of the button element. Progressive enhancement can be used to swap input for button and add the needed JavaScript to submit the correct parameters. This will give correct behavior for clients without JavaScript and provide a nicer look for clients with JavaScript

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.

I18n With StringTemplate

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.

Continue reading

Why I like working with Java more than .NET

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.
  • Properties
  • 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.