Skip to main content

Wicket + JavaFX?

Posted by timboudreau on July 11, 2009 at 11:29 AM PDT

I've been trying some experiments with embedding JavaFX applets into Wicket components. The results look promising...

Basically, for testing purposes, I've got a JavaFX applet that shows text entry fields - basically a simple format where you see

_______________________________________
|                ___________________   |
|  Your name     |__________________|o |
|                                      |
|                ___________________   |
|  Something     |__________________|o |
|                                      |
|                                      |
|                ______  ______        |
|                |Prev | | Next|       |
|                |_____| |_____|       |
|______________________________________|

where the number of pages, their contents and IDs are provided by applet parameters which the applet interprets. And yes, it's got some unobtrusive but cool looking fades and and other JavaFX sexiness.

Neater still, it has a provision for server-side validation of the components. This took a little doing (some Java code that starts a background thread, and a Java interface for running it and performing callbacks which is implemented over a JavaFX class) - so when the user stops typing into a field for a few seconds, the applet can communicate with the server (presumably using the same mechanisms as Wicket's built-in AJAX support); the little "o" you see beside each text field shows whether the data is good or not, and while the background part is running (currently just a Thread.sleep() - I wanted to see if I could get this working at all).

But while what I've got is a really rough prototype, it proves you can do it (yes, you can do similar things with AJAX, but well, it's AJAX :-)).

Now, whether the world has any use for this is another question - but it could be interesting to make generic data entry applets with lovely UIs, which could simply be embedded in a Wicket component (and skinned with your site's own CSS - though this actually seems to be a little broken in JavaFX at the moment). Drop the component on your page, and, voila.

Now, of course, the hard side is the server<->client communication - that's next. Or maybe I'll take the weekend off...that would be unusual :-)

Related Topics >>

Comments

Thats a nice timing :-) I searched the web and stumpled ...

Thats a nice timing :-) I searched the web and stumpled over http://www.slideshare.net/jcompagner/wicket-and-swing-from-one-codebase and later on I found http://weblogs.java.net/blog/2006/02/01/wicket-swing-hmmminteresting ... and clicked 'Main' on your blog ... So, do you know other projects which have done wicket+jvmOnClientSide? Regards, Peter.

Thinking about it some more, there are some real possibilities here. The JavaFX guys demo'd some Adobe Illustrator plugins at JavaOne. They generate "declarative" (no logic) JavaFX files from Illustrator (so you can do animation paths, the whole ui design in a real graphic design tool). The result *is* JavaFX code; the elements that matter to the programmer are given string IDs (Wicket folks, does *that* sound familiar?). In short, there's a very small impedance mismatch between JavaFX + FXD (I think that was the file extension for those declarative files) and Java + HTML in Wicket. So, you write a generic JavaFX applet. It implements Wicket's wire communication for AJAX. On the server side, you have a Wicket panel that instantiates that applet. You add forms, labels, whatever to it just like you would to a normal Wicket component (only the IDs have to match up to the FXD file IDs because there is no HTML for it). On the server side you're writing plain Wicket code. The client communicates to the server just as if it were wicket components on a web page communicating with the server via AJAX or a form submit. As long as you have a designer to do the FXD, you could make embedding slick, sexy JavaFX components into a Wicket web page completely transparent to the server-side programmer - they're just adding labels and text fields and such to a panel like they would any panel (the component, instead of rendering its children, renders them to applet startup parameters). If you had an FXD that matched up its ID hierarchy to an existing Panel's html, you could just swap the superclass and it would work. This seems so too good to be true, there's got to be something wrong with this idea.

well done go ahead i really suprised it!!

I think this will be really cool, good job man.

For instance, in Wicket contributions there is a component to render graphs based on Flash... now that JavaFX 1.2 has got specific APIs for graphs it would make sense that somebody made a JavaFX version. BTW, the Flash component works great: but if you don't know Flash, like me, you can't extend it.