The IBM Reflexive User Interface Builder (RIB), a new technology available from alphaWorks, is an application and toolkit for building and rendering Java AWT/Swing and Eclipse SWT GUIs. RIB specifies a flexible and easy-to-use XML markup language for describing Java GUIs and provides an engine for creating them. You can use RIB to test and evaluate basic GUI layout and functionality, or to create and render GUIs for an application.

Here we see another example of using XML to declaratively setup GUIs (a la XAML, XUL, and co.).

Introducing the Reflexive User Interface Builder

Though I did'nt get into the details of RIB, it seems to be like another XML based UI framework amongst many. I'm not sure why there are so many yet so little talk about them. I know Macromedia is having their own XML based Flash scripting language.
Finally the question is can these XML based GUI scripts really replace make things easy for anyone? I beleive a very good IDE would serve better and improve productivity. So everyone is going to ask what about portability..what if I want to create the same interface on the web...and I don't what to code any more or any less..well I guess the web is not mature enough to handle things like drag and drop and with them numerous browsers making a thing work in 1 browser is an arduous task. Unless I see the true need to externalize UI I see these frameworks as great research projects never seeing the light of day for practical applications.

-Anand

You're yet another "to-much-choice-and-diversity" whiner. To tell you the truth, I do not care about the number of frameworks attacking a given problem space. The more, the better: I have more chances of finding what really suits me.

The "yet-another" attitude is too common, and somewhat contradictory: you problably dissaprove of the M$ monopoly, do you - as most Java people do? Deep inside, you WANT choice and diversity.

>>Finally the question is can these XML based GUI scripts really replace make things easy for anyone?

If you are asking the question, it's probably because you don't have the answer yourself: you have probably not tried the approach. So why are you judging?

Get my answer: yes, the approach works; it makes things easier. I've tried, I know. It's about time we get into rich clients. Others have: http://www.rebol.com/prod-view.html

>> I see these frameworks as great research projects never seeing the light of day for practical applications.

What's a "practical application" ? What's it to you? What's it to me? Isn't this highly subjective? Couldn't I build a "practical application" whose user interface is built with XUL? I mean: isn't "practicability" about functionality first and foremost (and not about UI)? You might answer that the UI plays some role; ok then: aren't rich clients more "practical" than you're standard HTML jsp/asp page, in terms of user experience, interactivity, responsiveness?

Open yourself.

guess I'm trying to open myself but there's too many open doors out there that I find it tough to choose which on to go.

I agree to the fact that diversity is good and choice is even better. However, my point it in the enterprise world, a lost of businesses are around a single delivery medium and do not expect the same thing in multiple mediums(Swing, Web etc.).

Though a lot of these frameworks do add they own 2 cents, I've not seen too many of them being used in a enterprise/business world.

Lastly I defintely think Rich UI Clients are the next generation and if all these frameworks converge towards that single goal then I see a lot of prospects in these. However today Rich UI Clients are still only a buzzword and not a standard. I'll wait till then.

-Anand
PS: I do disapprove M$ monopoly but I do think about how smart they are in doing so...

As a Java developer I always wanted to have a decent front-end. What good is a smart & powerful back-end if your user struggles with the interface? Your customer should have a very pleasing experience using your application and this starts with UI usability. As an extreme example I've seen people buying into applications that just look great without even doing something useful.

JFC, AWT, Swing were nice at some point in time (when were no alternatives). These days SWT allows you to smoothen user experience even more.
On the server side, (D)HTML and JSP provide the means to create simple interfaces for our web-based applications.

Building complex screens in Swing or SWT requires sometimes considerable effort. Adding extra RIA features (e.g. desktop integration or transparency) would make the development even harder. Implementing even simpler RIA requirements like drag &drop, in HTML can cause browser compatibility problems.
On the other hand the declarative way of defining user interfaces in HTML and the potential of SWT gives us some hope.

So, combining the best of two worlds seems to me the next step in UI. If your presentation layer is capable to generate an XML representation of a screen then the problem is half solved. And it should be since all it has to do is to send a set of parameters to a stylesheet to be applied to an XML template. Or prepare some presentation beans to be used in a JSP. Or simply build an XML stream on the fly. Or ...

For the second part you shouldn't do anything. Today you build your Swing hierarchy of classes and the Java runtime does the rendering. Or you create a set of JSPs and the browser renders them. It shouldn't be harder than that.

Well, I dare to say that it could be easier if you use the right rendering engine for your XML layout.

Smart layout engines should allow you to send only the modified parts of the layout (delta mode), so you don't have to embed scripting in your XML.
A decent layout engine should be able to communicate withe the back-end directly via TCP/IP.
A good layout engine should allow you to specify the behavior of the interface in a declarative way.
Your layout engine should use (existing third party) components to build a screen.
Ideally, the layout engine would run as a standalone desktop application or it could be embedded in a browser without any changes in your code.
And if this rendering engine would be available on any platform, that would be just great.

Well, I think Flash is a very good candidate here.


Just my 2c

Ovi Comes
http://zulu.netspedition.com

I have been using the Swing tool from www.jformdesigner.com. Coupled with the JDNC project from javadesktop.org, you have a quick and powerful way to develop solid Swing apps.

I have been using the Swing tool from www.jformdesigner.com. Coupled with the JDNC project from javadesktop.org, you have a quick and powerful way to develop solid Swing apps.

JFormDesigner is not released at this time. How have you got a beta?

I have been using the Swing tool from www.jformdesigner.com. Coupled with the JDNC project from javadesktop.org, you have a quick and powerful way to develop solid Swing apps.

JFormDesigner is not released at this time. How have you got a beta?

Indeed. I think there are a lot of people interested in JFormDesigner. Can anybody get a status, when it will be released and if it will, and when it will, be available to the 'unwashed mases' ?

Indeed. I think there are a lot of people interested in JFormDesigner. Can anybody get a status, when it will be released and if it will, and when it will, be available to the 'unwashed mases' ?

JFormDesigner is currently in beta state. The first (not public) release candidate will be available in about 2 weeks and the first public RC early in September. Stay tuned ;-)

Karl Tauber
www.jformdesigner.com

Why not use a scripting language like Groovy for GUI component creation and layout? Groovy, with it's easy and succinct syntax can make the job less tedious than either Java or XML and provide all the power you need. Of course, I'm only talking about Swing apps, not browser code...

I am glad that JFormDesigner mentions support for long-term persistence (JSR-57). But still only as a possible future development, which is kind of disappointing.

Overall it is very strange that long term persistence standard never got adopted IDEA supports its own flavor of XML so does Eclipse now. I personally thought that JSR-57 standard was well thought out. Moreover it is strange that companies in the expert group did not provide support for this.

In general storing UI description in UML is very convenient both from the point of writing a UI designer and from the point of comparing versions in a change control system.

Borland Delphi has a very nice support for visual inheritance and visual composition. I would like to see the same features implemented in Java.

Artem

Look at the listing. A HUGE mishmash of XML and code and to generate a two-field/two-button dialog?!?!?

The date is not April 1, so I'm not sure what is going on.

It adds HUGE amounts of code and noise you have to write, doesn't seem to save you from the layout managers and is a complete mess of unnecessary crap. No one in their right mind would touch this with a 10 foot pole.

And if you look at the XML, they immediately bastardize it with "@" and "%" all over the place instead of using a real f**king language.

If only there was a robust, object-oriented language one could use to implement this? Say...Java!?!?!?

head.explode();

I haven't used the XML UI frameworks myself but I think they would be hard to use without some sort of Editor. That said, I could see some project use it as an easy way to dynamically create a ui based on xml data using XSLT or Velocity or similiar. The resulting XML may be verbose but it wouldn't be created by hand.

This isn't the first XML UI framework so there may be others that do it better. There is something cool about a ui that is rich and dynamically created (not hard-coded in java). That's why HTML sites are so popular but they aren't feature rich (unless you like to use a lot of messy javascript). Look at how much HTML gets spit out just to render one page but note that for dynamic sites most of this is generated at runtime.

Now imagine the same idea but being able to render a rich ui (drag & drop), MDI interfaces, menus, etc.

There's nothing stopping you from creating a dynamic user interface in Java right now. It would be way easier to understand and easier to modifiy and have the benefit of having full and complete access to the Java API, not what some XML-lover thought you should have.

And when is this needed so much that we have to have multiple frameworks to do this?

I'm no genius, but coding up a Swing interface by hand isn't terribly difficult. Yes, GridBag is a pain in the ass, but there's other LayoutManagers that can help you and once you learn GridBag, it's easy enough to deal with.

Things like this XML crap seem so inappropriate and seem to solve a problem that is not difficult to solve.

Look at the listing. A HUGE mishmash of XML and code and to generate a two-field/two-button dialog?!?!?

If you look closer at the XML, you'd see that it is not just window, buttons and layout. It also accelerators, mnemonics, listeners. It has Java code inside. What we see here is a resource file plus Java code to process that stuff. Why not to port XAML then, like Mono ports the .Net. Then we would have .Net for Linux and would forget about Java.

I don't know who got the bright idea of designing Java UI with Java code only. Very often a simple dialog would do, and resource files work quite nicely here. But Java does not have resources for anything but strings. Was it another not-like-others idea? So now we see a bunch of UI designers totally incompatible with each other.

Michael, you are right about lack of resources sans String. Actually, ResourceBundle lookups return Object, it's just that you're support to write code to implement these Objects.

I've been trying to revive the late Galaxy Application Environment in Java.

UNDER CONSTRUCTION

http://jutland.kgbinternet.com/galaxy/whitepaper.jsp

// UNDER CONSTRUCTION

I give this link mainly to get you to read the white paper explaining why we think all these frameworks need to exist.

Why rag on XML in this context? It's just the right language for expressing human-readable, tool-friendly, hierarchical information.

If enough people want something like this, I'll make it O/S.

Gary

Many old 4GLs (many still in prodn) used some sort of database to drive a UI, allowing business users to create form definitions in a database, and at run time convert these into usable forms. Sometines these were compiled into some intermediate format. I work with one of these and am interested in the existence of a tool to convert such SQL based data into a swing form (mainly fields and buttons)

Anyone know of a tool which could perform this kind of task - conceptually similar to the XML driven form - which could form the basis of some forms generation engine - using not XML (too hard for business types to code up) but a database - they are all familiar with SQL. Even better would be a little gui to maintain these SQL definitions.

PRO-IV was an example of such, there are others gradually sinking into obscurity now, but there are still apps out there which require hundreds of forms (ours has 800 odd, maintained by end users and business analysts)

I am looking for a tool which could plug in at this layer , adapt the database form definitions (Form and Field attributes) and at runtime splash up a (very simple) swing based form instead. Ideally such a tool would include hooks to call blocks of (user definable) code as well. At this stage I envisage blocks of java - but many of these old 4Gls had their own specific lingo - usually something script or basic like - ie simple - which was compiled down to C or something similar.

The XUL, Luxor and other tools rely on XML - not maintainable by the average business person/end user.

Any Ideas along this line where I might look?

David Tuke
Javabarista.com.au

I once used Oracle JDeveloper. That IDE, given a Table, using it's wizard will comfortably churn out a easy Swing based form to view/insert/update the data.

Using Infobus DAC (Data Aware Controls) makes the task of writing Swing+DB applications a Zap. These controls are available in Jbuilder and I belive should be available in Latest JDeveloper also (as they were there in JDeveloper 3.2)

In nutshell, look for Infobus DAC controls from your favorite IDE and get going, it should be really simple to get what you seem to be wanting.

cheers.

Can you provide an example of the "database driven UI" queries?

What would the tables look like?

Gary

A correction, it is Soyatec builds XAML for java. The product is eFace. For more information, please visit eFace pages

Thanks for this interesting link.

I used SwiXml on a recent project and was very happy with it. I find defining an interface in XML much more intuitive than using Java code. If you look at the SwiXml example on the link, you can immediately see that you have a panel, containing two further panels, one of which has three buttons .... My project had a moderately complex interface including split panes and several tables, but was very easy to define without any graphical editor.

I think the main importance with these frameworks (not this one in particular) is that you can have a graphic artist make the UI and have the code seperate from the markup. However, if that's the whole goal of these frameworks, then you need to be able to link them together in some fashion as part of the language and XAML does this with the partial class concept. Since Java doesn't really have that concept, I would imagine that code-like features creap into these XML specifications and that's not a good idea. I think these frameworks will really fly when someone figures out how to seperate concerns properly

Can RIB build thin clients with rich functionality like flash or xwt?

We've been using Digital Harbor to develop a RIA database-driven presentation layer in front of legacy databases and processes. With Digital Harbor you build the UI using drag-and-drop (like in Visual Studio) and bind to data and processes using a drag-and-drop MDA builder. No 3g coding is required to produce some highly functional user interfaces! Check it out at www.dharbor.com
Graeme Harker
www.searchspace.com