Pivot: A Practical Example, Part 2 - Event Handling

The event listener logic is still pretty similar to Swing's. Maybe you could consider defining a straight Java method name in the XML file and hooking up the event listener automatically when the UI is loaded?

GTK+ libGlade (which is very similar conceptually to your solution) allows you to define method names in the XML file. If I remember correctly, it even handles finding the proper method name, regardless of the language (e.g. libGlade works with C/C++/Ruby/Python). They call it simply "signals" (I believe Qt has a similar approach). We can always learn something new and different from non-Java tools. :-)

See here for some info:
http://delirial.com/archives/tutorial-building-guis-for-ruby-programs-with-glade/

E.g. in the Glade XML file they define a signal for an event, e.g.:

Now, we need to add a signal (event) for quiting our program.

• Go to the Signals tab in the Properties window.
• Expand the GtkWidget node.
• Select delete-event and type on_quit in the Handler column.

 and then on the Ruby side they just need to define a method called on_quit:

def on_quit(widget, arg0)
    puts "This is me leaving."
    Gtk.main_quit
end

You bypass the whole event listener paradigm this way and just hook up a 'signal' directly to a method (possibly with a pre-defined signature).

This would go some way towards differentiating Pivot from Swing and giving it some real edge as compared to its older brother.

I adopted the same approach in my SwingBuilder project, see the Wiki and maybe you can pinch some ideas for your solution:

http://code.google.com/p/javabuilders/wiki/JavaBuilderEventHandling

http://code.google.com/p/javabuilders/wiki/SwingBuilderEventHandlers

Just the amount of code that is required for clicking a button to call some Java-side method. 3-5 lines may not seem much, but once you add all the buttons you have in an app, it's a fair amount.

The 'signals' approach reduces it to a simple property value. And it's not really embedding code, think of it more of as defining a signal that can be used to map to a method when the file gets loaded.

The method would have to live in the object that is loading the layout file...I presume the loading engine has a way to get a reference to the object that called it?

Just a suggestion...if it doesn't fit with your philosophy of how the toolkit should work, that's fine. After all, it's your project :-)

You're welcome.

I don't want to troll pushing my own project (which relies on YAML instead of XML), but just to give you a quick sample of how simple and productive signals can be:

 JButton(text=Save, onAction=save) 

would execute directly on the calling class without any other code needed:

private void save() {

   //save logic goes here

} 

You could easily do something like this in your XML markup. Does it handle all scenarios? No. Does it handle 80% of the most common ones...probably yes. If you have a good solution that follows the 80/20 rule then it's a valuable addition IMHO.

Well, it's really a GTK+/Qt solution...I just pinched it from them and made it Java-specific. Gotta give credit where it's due.

P.S. The tricky part is passing event-specific arguments to the method (e.g. FocusListener vs ActionListener), since it may be needed sometimes. You can't always assume everyone will want a zero-arguments method. But if you manage to figure it out in the context of your project, it would be well worth it.

P.S.S. If I have the time (which unfortunately I don't) I may be able to write a PivotBuilder for you using the same reusable engine I have for the SwingBuilder, since I already handle most of these issues in a domain-generic way...ah, if only the day had 30 hours instead of 24.

P.S.S.S. Beg Mikael Grev to write a version of MigLayout for Pivot. :-)
MigLayout is worth its weight in gold.

Ah, if Java only supported embedded free-form text in .java files (no need for external XML or YAML files then). I hear something like this was coming in Java 7, but who knows what will make it in there since all the senior Sun engineers seem to be wasting their valuable time on JavaFX instead.

 It kills me that Java is missing such basic things as integrated data binding and properties (Beans Binding blows, I know...I've implemented support for it...you need more code to support bindable properties than the code they supposedly replace)...and yes JavaFX was able to get it added with Chris Oliver working on it in his spare time. To make it worse, the main guy in charge of new Java 7 features is moving away from properties:

http://blogs.sun.com/abuckley/en_US/entry/properties_in_java

Wake up, Alex...properties NEED to be added to Java, but instead of simple get/set replacements they need to have automatically integrated support for firePropertyChange(), so no one should ever need to call it manually. And binding should be integrated right into the language instead of being a clumsy separate library.

 Look how simple data binding is in Flex with their annotated variables (even less than properties):

[Bindable]
private var labelText:String = "This is a label";

<mx:Label text="{labelText}"/>

That's literally 1 line of code for an annotation ([Bindable]). In Java to support Beans Binding JSR 295 it's nearly 20 lines, since you need to add PropertyChangeSupport to every bindable class and property.

And Sun is wasting valuable limited resources on JavaFX and moving away from enhancing the core Java languag to keep up the competition? This is one of the most illogical things I've ever seen done by an IT corporation.

[quote=gbrown@vmware.com]It requires some glue code to map property keys to getters and setters[/quote]

That's exactly the issue I have in general...glue code needs to be added to each getter/setter and potentially even the class. I would love it just to work out-of-the-box without the need for extra glue code...I'm dreaming in technicolor, I know...