 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / April 2006SQL Data driven GUI
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.lang.java.gui/browse_thread/thread/957bb2d5e 61e1d62/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 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. >Lots of scripting languages have gui packages and basically they have >the gui rendered at runtime too, only difference is that code to render [quoted text clipped - 12 lines] >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 > 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. [quoted text clipped - 4 lines] > 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. [quote] 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. [/quote]  Signaturemonique Ask smart questions, get good answers: http://www.catb.org/~esr/faqs/smart-questions.html > The presentation of > the relevant GUI is developed at run time based on data in the SQL [quoted text clipped - 3 lines] > 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 >> The presentation of >> the relevant GUI is developed at run time based on data in the SQL [quoted text clipped - 21 lines] >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 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 ... :-) >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 [quoted text clipped - 6 lines] >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 > 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, [quoted text clipped - 4 lines] > 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 > 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. Signaturemonique Ask smart questions, get good answers: http://www.catb.org/~esr/faqs/smart-questions.html > > 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 >> > I'm inclined to agree. With one proviso -- if your users' environment >> > is so tightly constrained that absolute co-ordinates don't cause them [quoted text clipped - 5 lines] >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 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. And here's info in SWT if you are interested http://www.eclipse.org/swt/ > 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. Signaturemonique Ask smart questions, get good answers: http://www.catb.org/~esr/faqs/smart-questions.html > 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. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.