Category Archives: Software Development

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.

Implementing a domain specific language

I have been so busy at work lately that since wrapping up the climbing robot I haven’t had time for any substantial personal projects. What I’ve been working on is a declarative DSL for implementing a web application based on ideas I previously wrote about. Like I said its a work project so I can’t go into any details. I will say that I’m working with ANTLR v3 and jQuery, which are technologies I really like. My point in mentioning it is that if you read that post and wondered, like I did, if those ideas would work I believe the project is far enough along that I can say that they do.

What I think I know about making accessible widgets

I mention Oracle in this post so as a reminder: my views are my own and do not necessarily reflect the views of my employer.

One nice thing about working at Oracle is that they take accessibility seriously. I have worked on web apps before that were supposed to be accessible but this is the first company I have worked for where I could actually get my hands on a (non-demo-mode) JAWS screen reader to do my own testing. You can try to follow all the best practices but you really do need to test with a screen reader to know how well you have done.

I have found that keyboard accessibility and screen reader accessibility are somewhat at odds.

If you do the right thing for keyboard accessibility (i.e. managing focus) and don’t use WAI-ARIA at all then you have a chance of being accidentally partially accessible in JAWS and probably other screen readers. This is assuming that you follow best practices for being accessible to screen readers (use label correctly, use native form controls – links, checkboxes etc. in semantically appropriate ways).

The problem is that all your keyboard/focus management logic is in vain since you are probably going to use arrow keys and JAWS is not going to give them to you (JAWS uses many keys for itself). The reason you have any chance of success is because the normal screen reading behavior of the arrow keys may be close enough and using native form controls will allow JAWS to access them in a reasonable way. How well it works will depend on the details of your rich control. The best you can do is to try to find the right balance between normal use and screen reader use. This should work OK with older browsers and screen readers depending on the various bugs and odd interactions between various browser and screen readers.

The other option is to go the full WIA-ARIA route. By using the appropriate ARIA roles and states and properties you can get JAWS version 10 (and presumably other new ARIA aware readers) to give you the keyboard keys you need. For this to work you need very recent versions of browser and JAWS. I have had some initial success with JAWS 10 and FF3.5. It looks like this approach will provide the very best functionality for all users. I have not yet tried the combination of JAWS 10 and IE8. The trouble is that the combination of JAWS 10 and IE7 works quite badly when you use ARIA. JAWS seems to get some of the ARIA information like roles but doesn’t get enough to work correctly. It gives up the keyboard keys but then doesn’t handle the ARIA based changes and therefore the normal JAWS arrow key functionality doesn’t work either. This is the worst possible behavior. Presumably older versions of JAWS that don’t know anything about ARIA will work fine with IE7 even if the rich control uses ARIA provided the ARIA support is on top of non-ARIA techniques mentioned previously. I have not yet tested this combination.

To me this means that if you are adding on to an existing app that must support older browsers or screen readers then using ARIA probably isn’t worth it yet. But if you are starting a new app that wont be released for a while then using ARIA is the way to go. You can still support older browsers but you would have to require that for screen reader accessibility an ARIA aware browser and reader must be used.

Another possible solution is to have an option to turn WAI-ARIA support on or off. I don’t like this because of the added complexity of implementation and testing.

Here are some resources that I found very useful in my recent accessibility work: Improving Accessibility Through Focus Management, WAI-ARIA Best Practices, and Delegating the focus and blur events.

A declaritive language for web applications

In a couple of recent posts I have argued that a higher level language is needed to
provide a significant boost to programmer productivity in the area of web applications. This is a topic I have been thinking about for many years. I’ve worked out some aspects of what I think the language should be. A little over a year ago I even started implementing a parser for the language in ANTLR. I worked on it for a few weeks before moving on to other higher priority projects. Higher priority simply means something more interesting caught my eye. It’s finally dawning on me that I’m not going to get a big enough block of free time to work on this any time soon. I guess I prioritize the smaller projects that have a better chance of getting finished.

Instead of mothballing the project completely I’m going to share some ideas from it. This his may be of interest to others and who knows, I may get back to it from time to time.
Continue reading A declaritive language for web applications

Writtten language already the best tool for software

Tools, languages or frameworks — which will have the biggest impact on developer productivity? I previously said that I thought languages could do better than frameworks in this regard. Now I’ll talk about at least one class of tools.

A good deal of focus around developer productivity is on visual editing tools. I think these efforts are misguided and unlikely to produce major benefits to developers. Clearly tools are useful. Humans are natural tool makers and users. Written language is arguably the most important tool invented by humans. Programming languages are tools.

So what do I mean by visual editing tools? My definition may be a little fuzzy but here it is: I’m talking about tools for creating software that don’t have an underlying text based language or completely hide it. They usually involve working with pictures, diagrams, or forms. Some examples:

  • Business Process Workflow editors
  • Property editors
  • Visual UI layout editors

These are some of the general problems I have found with visual editors. Not all of them have all these problems and I’m not signaling out a specific tool.

  • Scale — Sometimes the visual editors don’t take scale into consideration. They work well for small programs but break down when used on larger programs. The breakdown may be due to implementation details or a more fundamental limit in ability to comprehend the visualization at large scales.
  • lock in — This is when a tool requires you to use a particular platform, IDE, tool set, library or framework. The same lock in is possible with languages but it tends not to be; at least not for the more popular languages. Perhaps that is what makes them popular. As a developer I’m very skittish when it comes to lock in. It is much easier to share (and reach agreement on) a language specification than it is a GUI specification.
  • Poor source control integration — Being able to track changes to software source over time is very important. Some tools make arbitrary text changes that confound source control systems. The worst example I have seen is a visual work flow editor that changed all ids in its XML format source file every time you saved it. Binary formats are a definite no-no.
  • Lack of flexibility — When writing software in a text based language you are free to write in whatever order your thoughts come to you. Tools that force you to translate your thoughts into specification in a fixed way will end up frustrating users.
  • Inefficient — I tend to find that visual editors get in the way after a while (if not right away). They tend to require a lot of mousing around. Once I know what I’m doing typing is much faster.

Good editing tools assist you while working with a text based language. The most basic editing such as random access to the text, insert, delete, cut, copy, paste etc. is sufficient to get the job done and has the benefit of working equally well for all text languages. Advanced features such as syntax coloring, unobtrusive flagging of errors and warnings, context sensitive completion, access to language and API help, type based searching and navigation, refactoring, template insertion/completion, bracket pair matching, indenting etc. are very useful and don’t replace or get in the way of the text.

Diagrams can help visualize aspects of programs but programs are too complex and multidimensional to be fully represented in any picture or diagram so it is a mistake to think that the visualization is the program and can be edited directly. Being able to draw (or even edit) diagrams is a nice add on for a language but the language must come first and stand on its own.

Some tools claim to have an editable underlying text format when in fact it is just the tool’s internal model serialized as XML. This doesn’t count. Not because its XML but because it tends to favor ease of serialization and the needs of the tool over the ease with which humans can read and write it. XSLT is a good example of a language that uses XML syntax. It was clearly designed to be edited directly by humans. The fact that it can’t be fully described with XML schema is probably a good indication of this. I like XSLT but I also agree with Terence Parr when he says “I implore everyone to please stop using XML as a human interface!” (see his excellent book “The Definitive ANTLR Reference”) .

The best development productivity tools help the user write in a given language not replace language.