SQL Data driven GUI

[anon]

Originally posted in comp.lang.java.gui, but it was suggested over
there that I might want to repost here. Here is the thread over there
in case you want to review what has already been discussed:

http://groups.google.com/group/comp...2d5e61e1d62/78c74b6bea22e0ab#78c74b6bea22e0ab

I have a working prototype of an SQL database driven GUI written in
another language. The other language is not OO. I have been tasked
with developing the application in Java.

The existing application has a series of tables that define the many
potential GUI's. A separate series of tables hold the actual user
input.

Given a specific GUI, I can fairly easily query the previously created
user input, if any, through a persistence layer (such as Hibernate).
Similarly, I can store newly created user input.

Hence, the existing application really consists of two applications.
The first is the collection and storing of information necessary to
present a specific GUI. The second is what might be called the "real"
application in that it presents a specific GUI and collects and stores
the data specific to that GUI.

My question relates to the "real" application. The presentation of
the relevant GUI is developed at run time based on data in the SQL
database. Does anybody know of an existing class that might implement
something like this, or am I stuck developing one on my own? (I
suspect the latter). Whether known or not known, does anybody have an
opinion as to whether developing the GUI in a dynamic fashion like
this will be hopelessly inefficient (i.e., slow)?

I know this is heresy, but it would seem to me that this might be the
exception that breaks the rule in that in this specific circumstance
(where the GUI is data driven) the absence of a layout manager might
be the best way to go, if for no other reason than the users are used
to precisely placing the widgets. That is, the data for each widget
presented in a GUI includes positional values (in inches, not pixels).
Please don't beat me up too badly for suggesting that my presentation
layer avoid layout managers. I recognize that exact placement is not
generally desirable. But unless I want to redevelop the application
that creates the specs for the GUIs to be layout manager sensitive
and,at the same time, train the users on how to run such an
application, I think I might be stuck.

I suppose it is possible to take the GUI data and develop a
GridBagLayout spec. I'm not chomping on the bit to go that route.

Thanks for any and all thoughts.

Jim

 

[Jon Martin Solaas]

Lots of scripting languages have gui packages and basically they have
the gui rendered at runtime too, only difference is that code to render
is read from a source file on disk and not from a database. HTML-based
guis are read from files, transferred over network and interpreted by
the browser all the time. Not as fast as a native app, but widely
accepted these days, and slowness is often due to slow network transfer
over the internet.

Many approaches to have gui's rendered from xml has been made, I don't
know them all, but Mozilla XUL comes to mind, but I've never tried it.
I googled a little, and found for instance http://www.swixml.org/
referenced from
http://www.leepoint.net/notes-java/GUI/misc/80gui-generator.html.

If you can transform the gui tables to xml and feed to one of those
frameworks you may be getting somewhere.

 

[Chris Uppal]

The presentation of
the relevant GUI is developed at run time based on data in the SQL
database. Does anybody know of an existing class that might implement
something like this, or am I stuck developing one on my own? (I
suspect the latter). Whether known or not known, does anybody have an
opinion as to whether developing the GUI in a dynamic fashion like
this will be hopelessly inefficient (i.e., slow)?

Since all Java GUIs are assembled dynamically anyway, you have all the bits you
need to create your own from the information in the DB. Naturally there won't
be anything pre-existing that understands your own meta-GUI data. Speed should
not be a problem -- or at least, your approach won't cause any new speed
problems.

I know this is heresy, but it would seem to me that this might be the
exception that breaks the rule in that in this specific circumstance
(where the GUI is data driven) the absence of a layout manager might
be the best way to go, if for no other reason than the users are used
to precisely placing the widgets. That is, the data for each widget
presented in a GUI includes positional values (in inches, not pixels).

I'm inclined to agree. With one proviso -- if your users' environment is so
tightly constrained that absolute co-ordinates don't cause them problems using
the existing app, then what benefit will they see when you re-implement this
stuff in Java ?

You might also consider developing a layout manager which used the absolute
co-ordinates as a hint (for initial positioning say), but allowed more
flexibility as the main windows are resized/shaped. (Actually you might be
able to use a GridBaglayout if you make the grid sufficiently fine-grained --
e.g. 1 pixel, or 1/100 inch, or similar.)

-- chris

 

[anon]

Lots of scripting languages have gui packages and basically they have
the gui rendered at runtime too, only difference is that code to render
is read from a source file on disk and not from a database. HTML-based
guis are read from files, transferred over network and interpreted by
the browser all the time. Not as fast as a native app, but widely
accepted these days, and slowness is often due to slow network transfer
over the internet.

Many approaches to have gui's rendered from xml has been made, I don't
know them all, but Mozilla XUL comes to mind, but I've never tried it.
I googled a little, and found for instance http://www.swixml.org/
referenced from
http://www.leepoint.net/notes-java/GUI/misc/80gui-generator.html.

If you can transform the gui tables to xml and feed to one of those
frameworks you may be getting somewhere.

Interesting. Thanks for the link and the thoughts.

Jim

 

[anon]

Since all Java GUIs are assembled dynamically anyway, you have all the bits you
need to create your own from the information in the DB. Naturally there won't
be anything pre-existing that understands your own meta-GUI data. Speed should
not be a problem -- or at least, your approach won't cause any new speed
problems.



I'm inclined to agree. With one proviso -- if your users' environment is so
tightly constrained that absolute co-ordinates don't cause them problems using
the existing app, then what benefit will they see when you re-implement this
stuff in Java ?

Cross platform capability.

You might also consider developing a layout manager which used the absolute
co-ordinates as a hint (for initial positioning say), but allowed more
flexibility as the main windows are resized/shaped. (Actually you might be
able to use a GridBaglayout if you make the grid sufficiently fine-grained --
e.g. 1 pixel, or 1/100 inch, or similar.)

I'm not sure I'm up to developing my own layout manager. And as I
inidicated, I'm not chomping at the bit to take my existing specs and
create a routine that uses GridBagLayout.

Thanks for the thoughts.

Jim

 

[Jon Martin Solaas]

anon wrote:
ained that absolute co-ordinates don't cause them problems using

Cross platform capability.

I do not know the nature of this app at all, but how about rendering the
gui in html and make a web application of it? You can write the
serverside in java (or any other lang) and on the client the
cross-platform problem is gone (only cross-browser ...

 

[anon]

anon wrote:
ained that absolute co-ordinates don't cause them problems using

I do not know the nature of this app at all, but how about rendering the
gui in html and make a web application of it? You can write the
serverside in java (or any other lang) and on the client the
cross-platform problem is gone (only cross-browser ...

I'm sure that is a course of action that would work. As would any
number of potential implementations. I don't have control over the
selection of the implementation, though. It has to be a pure java
solution.

The only purpose of the post was to inquire as to whether this concept
might make "those who generally state that pixel placement of widgets
is evil" accept pixel placement as being, if not preferable, at least
logical.

Well, I suppose an alternate purpose was to see whether an existing
class could be used, at least for a starting point.

I looked through the information at the link you posted and didn't see
anything which jumped out at me as being preferable to creating my own
set of classes to implement this. I'll take another look later, just
to see if something pops out at me the second time around.

The idea I'm toying with at the moment is to change the interface for
building the GUI specs from table based to GUI based. Essentially,
right now, the users input the GUI information into tables and then
they ask the system to render the GUI. Then they change the table
information, and re-render. Repeat until they like it. With java,
something tells me that I could fairly easily implement a class to
render the GUI in what might be called "design mode", along with
drag-and-drop on the widgets. Think of a Microsoft Access form in
design mode, where the users can drag and resize the widgets, as per
their preference. Another way of looking at this is that the users
would have their own mini-GUI-IDE.

As with most things, though, I have to worry about project creep. If
the above proves too challenging, at least for me, I end up with a
2-year project instead of a much shorter one. I don't think that
would be viewed as a good thing.

Thanks again for your insight.

Jim

 

[ducnbyu]

BTW regarding the comments I made in the .GUI group about speed and
calling native code to build the UI... I have been working with
Eclipse's (or IBM's) SWT GUI which builds a native UI. I'm impressed
with the speed of SWT and general graphics (arbitrary drawing)
performance. I don't know which GUI you are considering, but I only
have an introductory experience with Swing. So I can't compare
directly, but from what I read SWT has a smaller footprint and is
faster... because of the native calls for UI and graphics. The only
downside to SWT that I have read about is that for Macintosh it is only
supported for Mac OS/X has to do with the older version of the JVM that
will run on older MAC OS's. Don't want to suggest looking into SWT if
older macs are in scope. I am also using Eclipse's IDE which has the
Visual Editor that supports SWT, AWT, Swing and RCP and liking it.

 

[ducnbyu]

And here's info in SWT if you are interested

http://www.eclipse.org/swt/

 

[Chris Uppal]

The idea I'm toying with at the moment is to change the interface for
building the GUI specs from table based to GUI based. Essentially,
right now, the users input the GUI information into tables and then
they ask the system to render the GUI. Then they change the table
information, and re-render. Repeat until they like it. With java,
something tells me that I could fairly easily implement a class to
render the GUI in what might be called "design mode", along with
drag-and-drop on the widgets.

An intermediate stage, which would probably pay for itself as a useful test-bed
for your GUI building code, would be a simpler tool that allowed the user to
enter the table data and immediately rendered the resulting GUI (updating
dynamically). Going beyond into drag-drop and other direct manipulation of the
GUI elements sounds like feature creep to me. Don't do it until /after/ you
have secured the funding for that enhancement ;-)

-- chris

 

[Monique Y. Mudama]

Many approaches to have gui's rendered from xml has been made, I don't
know them all, but Mozilla XUL comes to mind, but I've never tried it.
I googled a little, and found for instance http://www.swixml.org/
referenced from
http://www.leepoint.net/notes-java/GUI/misc/80gui-generator.html.

If you can transform the gui tables to xml and feed to one of those
frameworks you may be getting somewhere.

That reminded me of this one:

http://glade.gnome.org/

I've also never used it.

Glade is a free user interface builder for GTK+ and GNOME, released
under the GNU GPL License.

The user interfaces designed in Glade are saved as XML, and by using
the libglade library these can be loaded by applications dynamically
as needed. (Glade can also generate C code, though this isn't
recommended for large applications.)

By using libglade, Glade XML files can be used in numerous programming
languages including C, C++, Java, Perl, Python, C#, Pike, Ruby,
Haskell, Objective Caml and Scheme. Adding support for other languages
is easy too.

 

[Monique Y. Mudama]

The only downside to SWT that I have read about is that for
Macintosh it is only supported for Mac OS/X has to do with the older
version of the JVM that will run on older MAC OS's. Don't want to
suggest looking into SWT if older macs are in scope.

There used to be the claim that SWT, while faster, had a lot fewer and
less full-featured widgets than Swing.

I don't know if that's still the case.

 

[Monique Y. Mudama]

Cross platform capability.

Are you talking about not having to recompile, or not having to write
platform-specific GUI code?

I'm wondering because there are a number of, say, Gnome-based apps
that work on both Linux and Windows. You just have to have the right
libraries installed. That's C++ I think.

 

[Chris Uppal]

Cross platform capability.

Hmm... If you are serious about going cross-platform, then absolute layout
specifications suddenly look a lot less workable.

-- chris

 

[anon]

Hmm... If you are serious about going cross-platform, then absolute layout
specifications suddenly look a lot less workable.

Certainly presents another constraint that the users will have to live
with. I am thinking, for now, that the GUI's will be specified "per
client" and that there will therefore be an assumption that each
client utilizes a specific platform. As long as a given client
doesn't use multiple platforms, then all should be well.

In the event that:

1) a specific client utilizes multiple platforms; and,

2) the GUI renders acceptably on one platform but not on another

the client must effectively maintain two GUI's.

Note that this still leaves the client with the ability to render on
any platform, but it does introduce a complexity/inefficiency that I'd
like to avoid.

Thanks again.

Jim

 

[ducnbyu]

There used to be the claim that SWT, while faster, had a lot fewer and

less full-featured widgets than Swing.

I had made mention of things being done in native code in his original
thread over on comp.lang.java.gui. I wanted to clarify that I was
thinking about SWT when I made those comments.

True, by nature SWT must, for speed, natively support all of the same
widgets so there is going to be a lowest common denominator. All of
the widgets the OP made mention of are supported by SWT, and he was
concerned about rendering speed so it seemed like a good fit for SWT.
But he did say "...etc." so it is possible that he might have something
that can't be done natively on all platforms.