SQL Data driven GUI

Discussion in 'Java' started by anon, Apr 5, 2006.

  1. anon

    anon Guest

    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
    anon, Apr 5, 2006
    #1
    1. Advertising

  2. 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.
    Jon Martin Solaas, Apr 5, 2006
    #2
    1. Advertising

  3. anon

    Chris Uppal Guest

    anon wrote:

    > 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
    Chris Uppal, Apr 5, 2006
    #3
  4. anon

    anon Guest

    On Wed, 05 Apr 2006 10:21:05 +0200, Jon Martin Solaas
    <> wrote:

    >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, Apr 5, 2006
    #4
  5. anon

    anon Guest

    On Wed, 5 Apr 2006 11:33:13 +0100, "Chris Uppal"
    <-THIS.org> wrote:

    >anon wrote:
    >
    >> 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 ?


    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
    anon, Apr 5, 2006
    #5
  6. anon wrote:
    ained 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.
    >


    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 ... :)
    Jon Martin Solaas, Apr 5, 2006
    #6
  7. anon

    anon Guest

    On Wed, 05 Apr 2006 19:36:44 +0200, Jon Martin Solaas
    <> wrote:

    >anon wrote:
    >ained 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.
    >>

    >
    >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
    anon, Apr 5, 2006
    #7
  8. anon

    Guest

    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.
    , Apr 5, 2006
    #8
  9. anon

    Guest

    , Apr 5, 2006
    #9
  10. anon

    Chris Uppal Guest

    anon wrote:

    > 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
    Chris Uppal, Apr 6, 2006
    #10
  11. On 2006-04-05, Jon Martin Solaas penned:
    >
    > 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.


    --
    monique

    Ask smart questions, get good answers:
    http://www.catb.org/~esr/faqs/smart-questions.html
    Monique Y. Mudama, Apr 6, 2006
    #11
  12. On 2006-04-05, penned:
    > 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

    Ask smart questions, get good answers:
    http://www.catb.org/~esr/faqs/smart-questions.html
    Monique Y. Mudama, Apr 6, 2006
    #12
  13. On 2006-04-05, anon penned:
    >
    > 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.

    --
    monique

    Ask smart questions, get good answers:
    http://www.catb.org/~esr/faqs/smart-questions.html
    Monique Y. Mudama, Apr 6, 2006
    #13
  14. anon

    Chris Uppal Guest

    anon wrote:

    > > 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.


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

    -- chris
    Chris Uppal, Apr 7, 2006
    #14
  15. anon

    anon Guest

    On Fri, 7 Apr 2006 09:13:03 +0100, "Chris Uppal"
    <-THIS.org> wrote:

    >anon wrote:
    >
    >> > 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.

    >
    >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
    anon, Apr 7, 2006
    #15
  16. anon

    Guest

    > 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.
    , Apr 7, 2006
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stephan Bour

    DataGrid-driven SQL updates

    Stephan Bour, Dec 8, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    337
    Stephan Bour
    Dec 8, 2003
  2. Theo Harlauch

    porting curses driven to gui application

    Theo Harlauch, Sep 12, 2004, in forum: C Programming
    Replies:
    2
    Views:
    346
    Theo Harlauch
    Sep 12, 2004
  3. Tim Daneliuk

    Table Driven GUI Definition?

    Tim Daneliuk, Aug 5, 2011, in forum: Python
    Replies:
    9
    Views:
    474
    Dennis Lee Bieber
    Aug 6, 2011
  4. Jozef
    Replies:
    1
    Views:
    109
    Bob Barrows [MVP]
    Jan 22, 2006
  5. Replies:
    1
    Views:
    72
Loading...

Share This Page