Java Builders

The Swing JavaBuilder Book - Achieving maximum productivity with minimum code via declarative UI

2009-01-10T04:57:00.000-08:00

I've just release 0.3 ALPHA of the Swing JavaBuilder, whose aim is to dramatically improve the productivity of Swing development via declarative UIs in YAML (and thus give us a better option than that infernal JavaFX thingy).

One of the biggest deliverables of this new release is the first build of the Swing JavaBuilder PDF book that aims to provide a more thorough documentation of the project's goals and features.

Hope you will all find it useful:

http://javabuilders.googlecode.com/files/swing.javabuilder.0.3.ALPHA.zip

(the PDF book is in the root of the ZIP)

It is still missing the section on layout management using MigLayout
http://code.google.com/p/javabuilders/wiki/LayoutDSL

but that will be merged into the PDF soon.

More info at the JavaBuilders site:
http://code.google.com/p/javabuilders/

Enhancing Java: multiline strings and un-escaped strings

2008-12-10T06:34:00.001-08:00

Here's my initial proposal for enhanced String handling in Java that I would like to implement as part of the Kijaro project, which is an experimental fork of OpenJDK where Java hackers can try out new language features that they feel are missing.

Any comments are welcome!

Link to Google Doc with the specs:
http://docs.google.com/View?docid=d36kv8n_32g9zj7pdd

Quick teaser:


String sql = """
    SELECT col1, col2, col3
    FROM Table1
    WHERE col1 = 'Test'
    AND col2 = ?
    ORDER BY col1""";

Java 6u10: code your RIA in any language (Ruby, Scala, Python, Groovy)

2008-10-30T05:03:00.000-07:00

In what can only be described as an excellent move on the part of Sun Microsystems, the new Java 6u10 update (whose sole aim is fixing up all the applet issues to make them a worthwhile competitor to Flex and Silverlight) has full support for all non-Java languages that can run on the JVM: Ruby, Scala, Jython/Python, Scala...even JavaFX :-)

This includes the ability to script all of them using JavaScript from the browser page itself:

http://www.mail-archive.com/jvm-languages@googlegroups.com/msg01073.html
https://jdk6.dev.java.net/plugin2/liveconnect/#NON_JAVA_LIVECONNECT

This is excellent news that should surely increase the chances of applets against Flex, which currently locks you into the Adobe-only ActionScript language (even though admittedly, it is a JavaScript derivative)

More info here:
http://blogs.sun.com/theplanetarium/entry/java_se_6u10_some_things

Forget JavaFX: PulpCore is the real Java RIA

2008-10-22T06:08:00.000-07:00

Sometimes a little project out of nowhere comes along and delivers something that instantly grabs you and makes you say "this is it!".

Such was my experience when on the Swing links of the week I found a mention of PulpCore, a small framework that is an alternative to the whole JavaFX fiasco and delivers what we've wanted all along: fun, fast, great looking applets in pure Java (not some new questionable language being forced down your throat)!

http://www.interactivepulp.com/pulpcore/

Try these ones in particular:
http://www.interactivepulp.com/pulpcore/particles/
http://www.interactivepulp.com/pulpcore/sketch/ (Flash, eat your heart out on this one) :-)

The API seems very concise (the code for each of the applets is very short), yet the end results is light years ahead of any of the awkward ugly demos of JavaFX I've seen.

Maybe there is hope for applets to complete with Flash head on after all.

Java Swing fonts in Java 6u10 : B.E.A.U.T.I.F.U.L.!

2008-08-18T10:11:00.000-07:00

I've been known to make a few negative comments here and there about Sun's handling of Java recently, but I have to say they've really delivered on their Swing fidelity promises with the latest update.

The switch to using the native Windows font rasterizer for font rendering has made an enormous difference. It's just a pleasure to look at Swing applications now (and even though the Swing API is not perfect, I prefer it much more to SWT with its myriad of hard-coded SWT.* styles).

On the Linux front, the builds of OpenJDK 7 look really great on Ubuntu as well and have fixed most of the glaring GTK+ bugs.

Thank you Sun for a great job on this. It's good to see solid effort like this being put into maintaining Swing.

P.S. You asked for JDK 7 / GTK+ screenshots, so here they are:

Using JavaFX objects from within Java: a very bad joke from Sun

2008-08-13T06:36:00.000-07:00

So I read this article about accessing JavaFX objects from within Java, which is quite easy, it seems:

http://java.sun.com/developer/technicalArticles/scripting/javafx/javafx_and_java/index.html

Hidden lower in the article is the first public example I see of the opposite scenario: accessing JavaFX classes from Java.

I was (naively) expecting this would be done the way Groovy does it...as real JVM classes that are interoperable across all JVM languages. But, as usual JavaFX shows its "thrown-together-in-a-hurry-as-a-response-to-Flex" roots:

public class Main {

public static void main (String[] args) {
 ScriptEngineManager manager =
     new ScriptEngineManager();

 JavaFXScriptEngine fxEngine =
     (JavaFXScriptEngine) manager.getEngineByName("javafx");

 try {

   String param = "JavaFX object created in Java";

   String script = String.format (
       "MyJavaFXClass {property: \"%s\"}", param);

   Object o = fxEngine.eval(script);

   fxEngine.invokeMethod(o, "printProperty");

 } catch (Exception ex) {
   ex.printStackTrace();
 }
}
}

I mean, just beautiful, isn't it...who cares about type safety and static compiling, when we just expose a half-baked scripting interface.

The Silverlight/C# guys must be laughing their heads off looking at that sample.

Java SwingBuilder 0.2 DEV : added support for SWT-style menu API

2008-07-19T03:13:00.000-07:00

In my ongoing quest to maximize Swing developer productivity the latest version of the Java SwingBuilder introduces the SWT-style API for creating JMenuItems, which allows you to define the text, mnemonic and accelerator all in one shot, e.g.

JMenuItem(name=saveMenu, onAction=save, text="&Save\tCtrl+S")

Also, the visual layout Wiki has been updated to showcase how to implement John O'Conners Layout Manager Challenge:
http://weblogs.java.net/blog/joconner/archive/2006/10/layout_manager.html

using our visual layout DSL for MigLayout...piece of cake:

JPanel:
    - JScrollPane(name=scroll1): JList(name=list)
    - JLabel(name=lNameLbl, text=Last Name)
    - JLabel(name=fNameLbl, text=First Name)
    - JLabel(name=phoneLbl, text=Phone)
    - JLabel(name=emailLbl, text=Email)
    - JLabel(name=address1Lbl, text=Address 1)
    - JLabel(name=address2Lbl, text=Address 2)
    - JLabel(name=cityLbl, text=City)
    - JLabel(name=stateLbl, text=State)
    - JLabel(name=postalLbl, text=Postal Code)
    - JLabel(name=countryLbl, text=Country)
    - JTextField(name=lName)
    - JTextField(name=fName)
    - JTextField(name=phone)
    - JTextField(name=email)
    - JTextField(name=address1)
    - JTextField(name=address2)
    - JTextField(name=city)
    - JTextField(name=state)
    - JTextField(name=postal)
    - JTextField(name=country)
    - JButton(name=newBtn, text=New)
    - JButton(name=deleteBtn, text=Delete)
    - JButton(name=editBtn, text=Edit)
    - JButton(name=saveBtn, text=Save)
    - JButton(name=cancelBtn, text=Cancel)
    - MigLayout: |
       [grow]                       [grow]                 [grow]
       scroll1+1+*     >lNameLbl    lName       fNameLbl   fName                             
                       >phoneLbl    phone       emailLbl+2,email              
                       >address1Lbl address1+*                                 
                       >address2Lbl address2+*                                 
                       >cityLbl     city        postalLbl  postal              
                       >stateLbl    state                                         
                       ^|newBtn+*=1,^deleteBtn=1,^editBtn=1,^saveBtn=1,^cancelBtn=1  [grow]

Get the latest version from here:
http://javabuilders.googlecode.com/files/javabuilder.swing.0.2.DEV.2008-07-19.zip

More info as usual on JavaBuilders.org

Taking JavaFX head-on: Java SwingBuilder 0.1.RC1 is here!

2008-06-24T20:15:00.000-07:00

JavaFX is no more the only way to do modern declarative UIs on the Java platform. However, unlike JavaFX, the Java SwingBuilder allows you to do it today and in pure Java (using an external YAML file to define the layout, control definitions, data binding setup, event wiring).

The aim of the Java SwingBuilder is to make UI programming in Java more productive than in any other tool, without the need for any specialized UI builders. The Java SwingBuilder runs on Java 5 and is released under the business friendly Apache 2.0 license.

Main site:
http://www.javabuilders.org [0.1.RC1 direct download]

Here are some screenshots from the samples app that is new to this release and showcases the power and productivity of the Java SwingBuilder.

And here are samples of the YAML files:
http://code.google.com/p/javabuilders/source/browse/trunk/org.javabuilders.swing/samples/org/javabuilders/swing/samples/ComponentsPanel.yaml

http://code.google.com/p/javabuilders/source/browse/trunk/org.javabuilders.swing/samples/org/javabuilders/swing/samples/BorderPanel.yaml

http://code.google.com/p/javabuilders/source/browse/trunk/org.javabuilders.swing/samples/org/javabuilders/swing/samples/MigLayoutPanel1.yaml

The only thing missing to really give JavaFX a run for its money is the desktop FX. We will do this in a two-step approach:

a) integrate JXLayer to provide desktop FX for "traditional" Swing panels (planned for 0.2)
b) integrate Scenegraph once it reaches 1.0 and changes license from pure GPL (no exact plans at this time)

Please see our wiki (which will be heavily updated with the missing details before 0.1 FINAL).
We look forward to seeing you at the JavaBuilders Google Group with any questions or bug reports:
http://groups.google.com/group/javabuilders

P.S. And last, but not least...the JavaBuilders engine is not Swing-specific. We will be starting development of the Java SWTBuilder shortly (hey, maybe we'll even do a PivotBuilder). Stay tuned.

New generation Java applet plugin: handles proxies like it's 1995!

2008-06-17T05:26:00.000-07:00

Every time, I believe Sun's hype on how they are going to bring applets back, I get a crushing dose of reality as to how unlikely it is (and don't get me even started on the colossal mistake in the making that is JavaFX).

So, I downloaded the latest beta of the new plugin and run via Firefox 3 some of the demos:
https://scenegraph-demos.dev.java.net/demo-applets.html

And voila! What greets me first (running this from work)? A beautiful proxy prompt/password!

Just like Flash/Flex and Silverlight pop up all the time...no, wait a minute...they don't!

Imagine what would the acceptance of Flash be if every flash animation forced the user to re-enter their proxy prompt/password. Well, it seems this "new generation" (but same old thinking) plugin can't seem to integrate with the browser properly enough to get its proxy login info correctly!

For crying out loud! To add insult to injury, there is a little checkbox that says "Remember password". You can check it as many times as you want, but you will still have to re-enter your proxy user name and password every time.

With QA like this on the "new generation" plugin...I'd better start learning Flex soon.

Java SwingBuilder : finally a 0.1 Beta release

2008-06-16T02:39:00.000-07:00

I am happy to announce the Java SwingBuilder project has reached 0.1 beta status and is available for download from:
http://javabuilders.org [Direct download link]

This is the culmination of many months of research and work, dedicated towards bringing the power of declarative UIs to Java Swing (and in the near future SWT), by utilizing the YAML file format (instead of XML or JSON) to define the UI and related functionality such as method handlers (no need to write action listeners, ever), support for long running background tasks, data binding, input validation, etc. All layout functionality is based around the amazing MigLayout layout manager and provides a simple DSL to it that makes creating UIs a breeze.

More info available at the Java Builders wiki:

http://code.google.com/p/javabuilders/wiki/Overview
http://code.google.com/p/javabuilders/wiki/JavaSwingBuilder

The 0.1 beta release also comes with optional integration libraries for SwingX and Jide Common Layer swing components.

Some highlights:

Data binding is performed using the standard Beans Binding library.
Layout management is performed using MigLayout and nothing but MigLayout (it makes all JDK layout managers obsolete and you owe a favour to yourself to learn MigLayout and forget about GridBagLayout and GroupLayout once and for all).
Early versions of integrated input validation is performed using Apache Commons Validators.
Support for long running tasks is performed using SwingWorker.

Runs on Java 5.0.

All you need to start using it in your project is a decent YAML editor, for Eclipse we recommend the Eclipse YAML editor.

Unfortunately, the JavaBuilders project is not usable with NetBeans due to a critical bug in their YAML editor, which at this point they have no plan to fix. We recommend you use Eclipse or IDEA IntelliJ instead.

For any questions, support, enhancements, etc. please join our
Java Builders Google Group

Long term plans are to provide a full-blown alternative to JavaFX, so that developers can use declarative UI and provide desktop FX in pure Java. Our next step on that path will be to integrate the amazing JXLayer library as a standard means of providing FX to your Swing app.

Scenegraph support will be added once they write up some documentation and change the license from pure GPL to something more business-friendly.

Java SwingBuilder: help me integrate Scenegraph and take on JavaFX before it even arrives

2008-06-04T09:58:00.000-07:00

As part of my Java Builders project (in particular the Java SwingBuilder) I am introducing powerful declarative UI building to pure Java using a separate YAML file to define all the layout, data binding, event wiring, layout management, etc., thus saving the Java programmer countless lines of boring, repetitive code.

As part of this effort I would also like to integrate Project Scenegraph:
https://scenegraph.dev.java.net/

which is the underlying engine behind most of JavaFX's power, but available in pure Java.

Unfortunately, Scenegraph is one of the most poorly documented OSS projects out there, despite its importance. It has some minimal FAQ, some slides with API examples that are out of date compared to the latest download, etc, etc. In short it's really hard to understand all the functionality this engine provides without spending countless hours trying every little piece.

Hours, which unfortunately, I do not have. But, if someone were willing to chip in and do the Scenegraph research and document clearly:

- how do I add components to a scene?
- how do you handle effects? how do you chain them together?
- how do you handle animations? how do you define them? how do you transition from one state to another?
- how do you do layout management for components within a scene?

then armed with that documentation I could integrate it into the Java SwingBuilder.

Thus we would have a tool that would have all the power of JavaFX (and more), but available to pure Java...actually available to any VM language that generates Java-compatible classes. We could do RIAs without being forced to go to a different language, especially one such as JavaFX with some very questionable design choices.

Please use the thread on our discussion group to post any findings:
http://groups.google.com/group/javabuilders/browse_thread/thread/f5b006b83dee6431?hl=en

Thank you very much in advance to anyone who is willing to contribute and participate (and maybe submit some working code samples). It will be very much appreciated.

Cheers, Jacek

LICENSE

P.S. Danno Ferrin has brought up the interesting issue of Scenegraph licensing, which right now is GPL v2 only (the license is pretty hidden, not mentioned on the site, youhave to open the actual source code to see it). This means it is illegal to use it in any non-GPL project (including mine, since I use Apache 2.0)
I started a thread on this in the Scenegraph forum, let's see what the Sun guys have to say:
http://forums.java.net/jive/thread.jspa?threadID=41965&tstart=0

Java SwingBuilder: support for JScrollPane, Border, Icon + new discussion group

2008-05-31T04:58:00.000-07:00

New version up at Java Builders:
http://javabuilders.googlecode.com/files/javabuilder.swing.0.1.2008-05-31.zip

Mostly lots of work under the hood, but also plugged in some missing holes:

Border
Icon
JScrollPane

We also hava a Java Builders group now, please join if you have any questions, need an enhancements, run into a bug, etc:

http://groups.google.com/group/javabuilders

Gregg Bolinger has been putting the SwingBuilder through some tests and been able to create a nice panel such as this quite easily (after some initial learning curve and bug fixing on my part):

Java SwingBuilder: our first bug fix release

2008-05-27T04:51:00.000-07:00

http://javabuilders.googlecode.com/files/javabuilder.swing.0.1.2008-05-27.zip

The Ant build was not including all the required resources in the generated jar file, and runtime exceptions could occur. Please update.

Many thanks to Gregg Bollinger for pointing this out and submitting the first defect as well (although on an unrelated issue). Defects are good (well, not for my ego, they're not...but it's good to get some feedback).

Swing/SWT programmers: discover the power of MigLayout

2008-05-26T05:23:00.000-07:00

I am happy to announce a DevX.com article I wrote about Mikael Grev's amazing MigLayout layout manager:
http://www.devx.com/Java/Article/38017

If you are doing any UI development in either Swing or SWT, you deserver to give this layout manager a try. After getting familiar with it, I would find it painful to go back to anything else.

I used one of the samples the readers have sent me on the complex UI challenge post from a few weeks ago as the base for the most complex screen in the article...I can't even imagine how convoluted the code would have been in any standard JDK layout manager.

Don't forget to vote on the RFE to get MigLayout included in the base JDK:
http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=2532262642c44ffffffffa36083a3bd0096c?bug_id=6530906

BTW, what's wrong with this picture? The RFE is in the top 10 RFEs, but Sun marked the priority as "5-Very Low". Earth to Sun, Earth to Sun...listen to your users. 90% of the layout manager tutorial could have been redone with nothing but MigLayout.

Pretty much all layout managers in the JDK (outside of FlowLayout) could be marked as @Deprecated and replaced with MigLayout.

Java SwingBuilder : first support for validations, inching towards 0.1 release

2008-05-24T03:42:00.000-07:00

I just committed the first working code that has some integrated validator logic. Latest code drop available as usual on javabuilders.org.

Just like with binding, it is a new root node in the YAML file:

JFrame(name=frame,title=Binding Frame,size=packed):
content:
   - JLabel(name=fnLbl, text="First name:",labelFor=fName)
   - JTextField(name=fName)
   - JLabel(name=lnLbl, text="Last name:", labelFor=lName)
   - JTextField(name=lName)
   - JButton(name=ok, text=OK, onAction=(validateInput,save,cancel))
   - JButton(name=cancel, text=Cancel, onAction=cancel)
layout: |
   []      [grow,200px]
   >fnLbl  fName
   >lnLbl  lName    
   >ok+*=1,cancel=1      [grow,bottom]
bind:
- firstName: fName.text
- lastName: lName.text
validate:
- fName.text: {label: First Name, mandatory: true, minLength : 5}

Right now it only supports "mandatory" and "minLength", but shortly I will be adding all the validator routines supported by Apache Commons Validators:
http://commons.apache.org/validator/apidocs/org/apache/commons/validator/routines/package-summary.html#package_description

In the above example, if the First name field is missing or less than 5 characters,

it will display a nice error dialog to inform the user:

At this point, the validation logic still needs to be called manually from the Java side:

private final BuildResult result = SwingBuilder.build(this);

public boolean validateInput() {
return result.validate();
}

but I will be looking into automating this soon.

You can see the full YAML and Java here:
http://code.google.com/p/javabuilders/source/browse/trunk/org.javabuilders.swing/samples/org/javabuilders/swing/samples/binding/BindingFrame1.yaml
http://code.google.com/p/javabuilders/source/browse/trunk/org.javabuilders.swing/samples/org/javabuilders/swing/samples/binding/BindingFrame1.java

Happy building! Once this is done, an official 0.1 release will finally arrive.

Java SwingBuilder: now with proper Wiki

2008-05-22T11:49:00.000-07:00

One of the biggest shortcomings of this project was the lack of documentation, outside of this blog. I have been working on getting the Wiki complete, and although it is still not 100% done, it should give newcomers a good introduction to what this project is all about:

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

Java to get a new WebKit-based browser component

2008-05-16T07:40:00.000-07:00

Exciting news for all Java developers that plugs in an outstanding hole in the stack.
Buried deep in the sometimes heated discussions about JavaFX on javalobby.org there was a statement from one of the core Swing developers at Sun:
http://java.dzone.com/articles/paying-price-javafx#comment-3252

"BTW, I was forgotting it: we're also going to have JWebPane, an embedded Swing/JavaFX component based on WebKit. It's another huge, historical gap that it's going to be closed."

This is great news! Kudos to Sun for making it happen...I'll be first in line to play with JWebPane when it arrives.

Also, all the new media stuff (video codecs, etc) will be integrated right into Java 7.

All I can say is great work Sun. Would it be better if it was a year earlier, but I'll take it anyway without asking any questions. :-)

Java SwingBuilder: turbo-charging YAML with virtual constructor flow

2008-05-16T02:52:00.000-07:00

I *was* supposed to look into integrating Commons Validators into the JavaBuilder concept, but occasionally one had that flash of inspiration where for a moment you cross into "mad scientist" territory...and this week had one of those. I've added a new concept to YAML that I call "virtual constructor flow" that basically compacts the file format to the maximum level allowed by natural law. :-)

OK, but let's start from the beginning. Let's say we have a typical builder file like this in YAML, with the traditional YAML white-space indentaton to indicate hierarchy:


JFrame:
     name: myFrame
     title: My App Frame
     state: max

YAML supports the concept of alternate flows, hence the same data can be expressed in-line, which basically turns a portion of it into JSON:


JFrame: {name: myFrame, title: My App Frame, state: max}

This is very cool and it helps to reduce the number of lines in a file. However, it does not work if the node in question has additional child nodes. In Java SwingBuilder, by convention children are grouped under the "content" list node (same name as in JavaFX...not a coincidence, obviously):


JFrame:
     name: myFrame
     title: My App Frame
     state: max
     content:
        - JPanel:
            name: mainPanel
                content:
                    - JButton: {name: okButton, text: OK}

The limitation / design (?) of YAML is that once you escape into the JSON format the entire child node has to be expressed in it, even if it has children of its own. This unfortunately would lead to many nested "{", "}", "[", "]" brackets (if you've seen any serious JavaFX code, you will see it often has lots of secton with 10 or more levels of nested brackets of various type).

So, if I wanted to cut down on the number of lines in a file and do it all inline it loses all the nice, clear YAML whitespace indentation and descends into JSON closing bracket hell:


JFrame: {name: myFrame, title: My App Frame, state: max, content: [
     {JPanel: {name: mainPanel, content: [
          {JButton: {name: okButton, text: OK}}
     ]}
]}

In other complex file very soon you will have multiple levels of nested "}]}" type closing brackets, which makes it very unreadable IMHO. That's why I opted for YAML instead of JSON.

What I would like to do is to use the in-line formats for the properties belonging to the current node and then go back to regular white-space YAML for its children, e.g.:


JFrame: {name: myFrame, title: My App Frame, state: max}
 content:
     - JPanel: {name: mainPanel}
          content:
              - JButton: {name: okButton, text: OK}

However, this is not allowed in YAML and the YAML parsing library will exit with an exception. It's all whitespace or it's all JSON-style brackets, but you can't mix and match them.

So, this is where the mad scientist mode entered. I decided to add a new flow type to YAML via a custom preprocesor that I call "virtual constructor flow" and it looks like this:


JFrame(name=myFrame, title=MyAppFrame, state=max):
    content:
        - JPanel(name=mainPanel):
            content:
                 - JButton(nam=okButton, text=OK)

This is still valid YAML (it gets processed without errors), but obviously the child properties are now embedded directly into the YAML node definition, so it does not know about them, it just sees a node defined as JFrame(name=myFrame, title=MyAppFrame, state=max)

The JB pre-processor will take the YAML Object and do a second pass through and "explode" those properties embedded int the virtual constructor flow and create at run-time the exact same "pure" YAML hierarchy as seen at the beginning.

Also, the pre-processor does some nifty stuff such as if a node is defined right off the bat as a list (e.g. "JFrame: " with "- JButton", "- JLabel" nods underneath it) it will property "move" the list one level down to the default "content" node.

Therefore all we have left is:


JFrame(name=myFrame, title=MyAppFrame, state=max):
    - JPanel(name=mainPanel):
        - JButton(nam=okButton, text=OK)

A lot less than the original input:


JFrame:
     name: myFrame
     title: My App Frame
     state: max
     content:
        - JPanel:
            name: mainPanel
                content:
                    - JButton: {name: okButton, text: OK}

but at run-time the pre-processor will "explode" the compressed format to exactly the same thing.

Now you are wondering, "well OK, this is cool, but is it really worth it to bastardize YAML with some sort of custom extension?". And the answer is YES, it is worth, 'cause it brings amazing reduction in the size and levels of indentation when defining UIs via Java SwingBuilder.

Let's say we have a simple JFrame with 3 main menus and some child menus underneath them:

The pure YAML version of the build file for this looks like this:

http://code.google.com/p/javabuilders/source/browse/trunk/org.javabuilders.swing/samples/org/javabuilders/swing/samples/menu/FrameWithMenu.yaml

but the compressed version is WAY smaller less verbose:

http://code.google.com/p/javabuilders/source/browse/trunk/org.javabuilders.swing/samples/org/javabuilders/swing/samples/menu/FrameWithMenuCondensed.yaml

Basically, this allows you across the board to define an entire object and all of its properties in one line of "enhanced" YAML using the virtual constructor flow.

The latest build of Java SwingBuilder with support for this enhanced format is up on javabuilders.org.

P.S. Here's another form converted to the new format with before/after samples:

Before:
http://code.google.com/p/javabuilders/source/browse/trunk/org.javabuilders.swing/samples/org/javabuilders/swing/samples/binding/BindingFrame1.yaml?r=150
After:
http://code.google.com/p/javabuilders/source/browse/trunk/org.javabuilders.swing/samples/org/javabuilders/swing/samples/binding/BindingFrame1.yaml?r=157

Less code and less lines to type = good! :-)

NetBeans 6.1 : no go for YAML development

2008-05-15T09:20:00.000-07:00

I've tried doing some YAML work in the new NetBeans 6.1 to see how it stacks up against Eclipse for JavaBuilder development.

Unfortunately, a few things out the bat went wrong:
a) the YAML editor is not part of the base IDE, nor is it a stand-alone plugin. You have to download the entire Ruby support bundle to get it. Minor, but a little annoying.

YAML != Ruby on Rails
YAML > Ruby on Rails

b) the editor seems to only support a small subset of YAML syntax (probably just what is needed for Ruby on Rails) and in particular it does not recognize YAML block literals:
http://en.wikipedia.org/wiki/YAML#Newlines_preserved

which I use all over the place, especially for the "layout" definitions.

I've filed two issues for this, please vote on them and help to get them fixed in a future update:
http://www.netbeans.org/issues/show_bug.cgi?id=135165
http://www.netbeans.org/issues/show_bug.cgi?id=135166

Trolltech makes Qt run as GTK+

2008-05-15T07:10:00.000-07:00

Great news for us Linux fans. One of the pain points is the different look and feels of GTK+ and KDE/Qt apps.

It seems the fine folks at Trolltech are working on making this go away by allowing Qt apps to use GTK+ for all the rendering (not imitated, real GTK+).

Thank you Trolltech, this is a great idea. I would love to see Amarok and KTorrent blend seamlessly into my Ubuntu GNOME desktop.

http://labs.trolltech.com/page/Projects/Styles/GtkStyle

Java SwingBuilder: binding done, SwingWorker done, fat trimmed

2008-05-12T19:52:00.000-07:00

Latest code drop on javabuilders.org has the latest and greatest.

The binding support comes in two basic flavors:

a) straight bean-style property, e.g:

bind:
- this.lastName : firstNameTextField.text

This is a straighforward command to bind the text field's Text property (the source) to the "lastName" property of the backing Java class.

b) EL-style property that allows binding to multiple properties, e.g.:

bind:
- this.fullName: "${this.firstName} ${this.lastName}"

Since "{" and "}" are reserved characters in YAML you have to break out into quoted string to put it in. Note that when dealing with multiple properties like this it is NOT POSSIBLE to bind to properties from a different object (e.g. get the text from one text field and then one from another and combine them). This is just a limitation of how Beans Binding works.

As I mentioned before, the support for running background methods via @DoInBackground is done and it automatically pops up a nice progress dialog with an optional cancel button, if required. See the code in the sample's save() method to see how you can interact with it from the Java code:
http://code.google.com/p/javabuilders/source/browse/trunk/org.javabuilders.swing/samples/org/javabuilders/swing/samples/binding/BindingFrame1.java

In another node, I removed all the Log4J logging code and switched to regular Java logging API (even though it is sucky compared to Log4J). Thanks to this I cut nearly 500KB in the download size (for the actual JB jar and its dependencies). We are now at a total of 1.1 MB...an overhead of 50% seemed a lot for something like logging, hence Log4J had to go.

I like to keep it lean. This ain't .Net with a 30MB download forced upon you in the background via Windows Update :-)

Next up: validations. Stay tuned.

Java SwingBuilder: latest updates on binding, SwingWorker and validations

2008-05-09T07:16:00.000-07:00

It may seem quiet in JB land, but deep in the underground bowels of the Furmankiewicz Laboratories, things are churning nightly.

There's a lot of unstable code right now that needs to be finished, hence no new updates, hopefully more next week.

Priority is to complete a 0.1 release which will have finished support for:

a) binding (Bean and EL) e.g.

bind:
- this.lastName : lastNameTextField.text
- this.fullName: "${firstNameTextField.text} ${lastNameTextField.text}"

b) support for running long running methods via SwingWorker

- first, all the event handlers now support executing multiple methods in sequence, so you can do:

onAction: save
or:
onAction: [validate, save, close]

On the Java side you can use an annotation to flag which method is to be run in background:

private void validate() {}

@DoInBackground(progressMessage="Saving customer data...")
private save(BackgroundEvent evt) {}

private close() {
//will only be executed AFTER the background method finishes successfully
}

c) integration with Commons Validations (or JSR 303 if there was a reference implementation), e.g.:

validate:
- firstNameTextField.text : {mandatory : true. minLength: 5, maxLength: 40}

etc, etc.

This is the dev plan for next week and once it's done and stable, 0.1 will be released and then maybe JB will get some notice. Wish me luck in my late night coding endeavours.

P.S. Update for May 12: binding and background task support is done!
Get latest code drop from javabuilders.org to see it.
Working example of both:
http://code.google.com/p/javabuilders/source/browse/trunk/org.javabuilders.swing/samples/org/javabuilders/swing/samples/binding/BindingFrame1.yaml
http://code.google.com/p/javabuilders/source/browse/trunk/org.javabuilders.swing/samples/org/javabuilders/swing/samples/binding/BindingFrame1.java

I need to do some more work on binding to allow binding a target to multiple elements, but that can come later.

JavaBuilder for Swing : more binding updates

2008-04-30T21:28:00.000-07:00

I think my initial instinct to put the bindings on the YAML side were right after all. But, this requires much larger changes.

I think I have the right approach though...I will define bindings as a totally stand-alone separate root node, after all the UI elements have been created. Unlike JavaFX, I will not put the binding definition directly into the property value (since that entails an ugly hack like "bind: binding expression"). This way we will have a very clear separation of concerns, just like with the "layout" component (i.e. not putting layout info at the control level, but in a separate node of its own).

Here's a sample of what it *may* look like on the YAML side:
(see the "binding" node at the end):
http://code.google.com/p/javabuilders/source/browse/trunk/org.javabuilders.swing/samples/org/javabuilders/swing/samples/binding/BindingFrame3.yaml

I did major updates to the core engine to support multiple root nodes, so major instabilities in the code right now (probably)...will continue on this.

And now for something completely different: the new Agile baritones

2008-04-30T11:02:00.000-07:00

Time to take a break from all this JavaBuilder madness and remember my other great passion: guitars!

I already own the amazing black Agile AB-3500 baritone (perfect for those brewtal riffz tuned to B), but Rondo Music has shown up the new model, in amazing tribal green flame maple finish:

http://www.rondomusic.com/product931.html

Man, if I didn't only have all those bills to pay I would get this beauty in a second...

JavaBuilder for Swing : now with two-way binding support!

2008-04-29T21:09:00.000-07:00

I am happy to announce the first working support for binding in JavaBuilders, with full support for two way binding!

I realised I had the wrong idea initially (i.e. putting binding info in the YAML file). Instead in belongs on the Java side. This is especially important once I start adding support for EL binding (that's scheduled for later this week).

Here's the sample YAML build file:
http://code.google.com/p/javabuilders/source/browse/trunk/org.javabuilders.swing/samples/org/javabuilders/swing/samples/binding/BindingFrame1.yaml
and the corresponding Java file:
http://code.google.com/p/javabuilders/source/browse/trunk/org.javabuilders.swing/samples/org/javabuilders/swing/samples/binding/BindingFrame1.java

And here is the resulting window when it opens:

The initial field values get populated from the Java side via the two-way binding (see the constructor code).

We modify it on the screen, press OK (the OK button is wired from YAML to execute the save() method) and we get:
Voila!

This is starting to make Swing programming look really a lot like JSF where the YAML file has all the layout/creation info and the corresponding Java class looks like a JSF backing bean, with just the relevant properties and event methods.

New code drop with this features to celebrate this:
http://javabuilders.googlecode.com/files/javabuilder.swing.0.0.2008-04-30.zip

In other news, the @Name annotation was changed to @Alias to more clearly indicate what it really does.

Plans for the next short future:
a) support for EL binding, e.g.

@Bind("{fName.text} {lName.text}")
private String fullName;

although this would be read-only of course (from YAML to Java, not two-way).

b) initial investigation of integration with a validation framework (maybe Hibernate Validators, if it's not JPA specific)

c) finished the MouseListener handler to provide support for the following events:

onMouseClicked
onMouseDoubleClicked
onMouseRightClicked
onMouseEnter
onMouseExited
onMousePressed
onMouseReleased

See sample:
http://code.google.com/p/javabuilders/source/browse/trunk/org.javabuilders.swing/samples/org/javabuilders/swing/samples/TestFrame.yaml

Stay tuned!