SQL Data driven GUI
anon
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
duc...@aol.com
except for maybe some up front time building the interface. That would
be a style issue. I don't think it would be inefficient as long as you
aren't using large case statements and write good SQL that the DBMS is
able to recognize (that the same basic statement was used before so it
can avoid reparsing and optimization after the first time) when the
user hits "save". For instance if the DBMS were Oracle you want to
make sure you use bind variables instead of embedding data within the
string that contains the statement.
If you have a large number of users, I would side with you on giving
them what they are used to. If your users are external to your
organization especially if they are customers of your company who paid
for your company's product I would also side with you on giving them
what they are used to. Unless you can show them a reason why a layout
manager will be of great value to them worth the expense and effort of
retraining. Which I doubt unless they are also java programmers.
Is the presentation global? In other words if a button is currently at
0, 0 and a user says to move the button to 3.5 inches from the left and
3.5 inches from the top, will all users see that change? Does the user
write any kind of code or scripts for handling business logic? You
might be able to gain marginal efficiency if you generate and compile
java code based on the user's presentation data. But then you would
need to manage version control which might not be a bad thing if
presentation is global to all users since it would insulate the
ultimate end user from half-done presentation changes being made by the
"presentation developer"... unless each user in your prototype has his
own presentation entries which doesn't seem likely since you'd have a
difficult time reconciling one user's data with another's.
anon
>Efficiency wise it wouldn't matter how you end up placing the widgets
>except for maybe some up front time building the interface.
That is precisely what I'm worried about.
> That would
>be a style issue. I don't think it would be inefficient as long as you
>aren't using large case statements and write good SQL that the DBMS is
>able to recognize (that the same basic statement was used before so it
>can avoid reparsing and optimization after the first time) when the
>user hits "save".
Hmmmmm...not sure about the order of things here. The user hits
"save" when defining the GUI. That stores information in the
database. At a later time, perhaps by a different user at the same
location, the "real" application builds a specifically requested GUI
by looking into the database for definition of widgets, widget
placement and widget-to-database binding.
I can certainly limit the database hits that the "real" application
makes to no more than a handful; and those hits would use complete
indexing. So, it isn't the database round trips I'm worried about.
It is the concept of iterating a recordset and building and placing a
widget during each iteration that concerns me. Especially if I have
50 or more widgets on a screen.
The more I talk this out, the more I think that efficiency in building
the GUI at run time will be acceptable.
>If you have a large number of users, I would side with you on giving
>them what they are used to. If your users are external to your
>organization especially if they are customers of your company who paid
>for your company's product I would also side with you on giving them
>what they are used to. Unless you can show them a reason why a layout
>manager will be of great value to them worth the expense and effort of
>retraining. Which I doubt unless they are also java programmers.
They are definitively NOT java programmers.
>Is the presentation global? In other words if a button is currently at
>0, 0 and a user says to move the button to 3.5 inches from the left and
>3.5 inches from the top, will all users see that change?
I would say regional. Each client organization can define as many GUI
interfaces as they like. Those interfaces will almost always remain
local to their organization, though. So, yes, USER1 may define a new
GUI and USER2 may actually use the new GUI - at the same client
organization. And while client organizations may share some GUI
development, it would be adhoc so there would be no need to
synchronize.
> Does the user
>write any kind of code or scripts for handling business logic?
With the exception of handling widget defaults, which are set during
the GUI specification phase, absolutely not.
>You
>might be able to gain marginal efficiency if you generate and compile
>java code based on the user's presentation data.
I'm afraid that would defeat the purpose of having the GUI's be data
driven. This system is meant to empower the user to create their own
interfaces (I provide basic templates), but with the possibility that
any one organization might have 100's of separate GUI's, I don't think
it makes sense for me to go down the route of compiling them. I hope
that makes sense.
> But then you would
>need to manage version control which might not be a bad thing if
>presentation is global to all users since it would insulate the
>ultimate end user from half-done presentation changes being made by the
>"presentation developer"... unless each user in your prototype has his
>own presentation entries which doesn't seem likely since you'd have a
>difficult time reconciling one user's data with another's.
Thanks for bringing that up. The actual data (not the GUI
specification data) is well defined and, in fact, the schema has been
stable now for 5 years. It isn't expected to change. And if it does,
it would still be global for all users at all client organizations.
Of course, while the schema is the same for all users, the data at
each client organization is not.
However, for my purposes, the widget-to-database binding is well
defined.
This sounds more restrictive than I intend it to sound. In fact, the
schema is self-expanding through a recursive structure. Hence, if
Client Organization A wants to add a data element to its data store,
it can do so via the application itself without changing the schema.
The database maintains tables which provide something like a table of
contents to the User data. If the user wants to add an element, the
application updates the table of contents. Once that is done, a GUI
widget can be specified to expose it. I'm not worried about this end
of the application.
The only thing I'm still on the fence about is how my application
should build the presentation layer. After reading scores of articles
telling me that pixel placement of widgets is EVIL, I need to convince
myself that there is an exception for my application's specific design
before I start laying down code.
I would guess that you don't know of a class that implements this sort
of thing, huh? <g,d&r>
Thanks again.
Jim
duc...@aol.com
>"save" when defining the GUI. That stores information in the
>database. At a later time, perhaps by a different user at the same
>location, the "real" application builds a specifically requested GUI
>by looking into the database for definition of widgets, widget
>placement and widget-to-database binding.
Not that it really matters to the problem you are wrestling with, but
the second user doesn't have to hit some type of "save" to send the
"real" application data to the DB?
>It is the concept of iterating a recordset and building and placing a
>widget during each iteration that concerns me. Especially if I have
>50 or more widgets on a screen.
and
>In fact, the schema is self-expanding through a recursive structure.
Just to see if I'm following you: you are concerned about bringing up
on the user's display an existing recordset containing perhaps 100's or
1000's of "rows" each containing 50 or so fields from 1 or more tables
that need to be displayed, maybe even some recordsets that are
subordinate to that recordset and so forth (the recursive part)
containing some number of fields from 1 or more tables. And you want
to display the entire recordset and all children thereof for the user
to be able to change what ever they want and at some point the "real"
application decides when the changes should go to the database (this is
where I thought maybe there was a "save" button of some sort for the
real application).
>The database maintains tables which provide something like a table of
>contents to the User data. If the user wants to add an element, the
>application updates the table of contents. Once that is done, a GUI
>widget can be specified to expose it. I'm not worried about this end
>of the application.
Right, metadata is stored in the database in the other set of tables
along with the UI specifications.
>The only thing I'm still on the fence about is how my application
>should build the presentation layer. After reading scores of articles
>telling me that pixel placement of widgets is EVIL, I need to convince
>myself that there is an exception for my application's specific design
>before I start laying down code.
I think maybe the articles you were reading were not considering GUI
builders for end users such as that subset of your application. If you
were building a static application then definitely you would not want
to get involved in pixel placement so that you can make changes here
and there and everthing else will adjust. And you can set your user's
expectations accordingly from the start each time you roll out a new
version. Just as long as the user can live with that text field that
moves below the line that it used to be on, for example. In most
internal development IT can justify such things on the basis of cost
savings as long as there is some kind of rollout demo. But when you
say client I'm picturing people that are paying real money to you or
your organization. Correct me if I'm wrong but I'm reading into your
post that the "prototype" is already being used and your clients have
much already laid out. If so, these people already have their
expectations set and spent time/money putting things in a particular
place or at least are used to them being there. The last thing you
want is for them to see the java re-write as a take-away. You don't
want them getting frustrated over trying to adjust the size of one
field just to keep another field where it's at. Perhaps at a later
time you can present to the customer base the real advantages they will
see by losing their static positional lay outs in favor of layout
manager with a poll. If they like it then roll it out in version 1.1.
Look at MS Acess or something and notice there are wizards that will
lay a record out on a form but then you can drag your fields around and
it remembers where you left it. Looks like pixel placement to me. I
think that's a pretty good example of what a real-world end user is
going to expect. So ask yourself if an end-user GUI builder deserves
the exception you are looking for.
>I would guess that you don't know of a class that implements this sort
>of thing, huh? <g,d&r>
Right, I'm not aware of a publicly available class though I would tend
not to look for one because that would be the fun part (I know, I know,
supposed to re-use where ever possible).
It's the same thing that Oracle (Forms), PeopleSoft (Pages), MS ACCESS
(Forms), etc do maintaining UI info in a catalog. They have the exact
same problem (with large "recordsets") and they probably each approach
it with different philosophies on what needs to be optimized and
compromising in other areas. Just because you are working in JVM with
emphasis on the VM I wouldn't write your application off as
automatically being slower than these guys. Unless you are using custom
widgets (which I doubt you would want to) JVM is or should be just
making a lot of calls to native code for building all this stuff. Your
code (the interpreted part that you are concerned with) will be
insignificant compared to the amount of code that is being executed
natively behind the scenes. Besides JVM is pretty darn quick in my
opinion. So I would suggest that you are only negligibly handicapped
by JVM and recommend you look at some of these other or similar
applications and see their approach.
I know PeopleSoft (now owned by Oracle) gives the users options: do
they want to see just the top entry or all. The reason they do that is
because they don't want to make the user wait for all that rendering.
Same problem.
In the old text terminal days we'd bring up whatever we could cram on
the screen and then have an "F" key to bring up the next set or the
previous set. Much like you see on a search engine to see the "next 10
results". See its the same problem that text terminals had back in the
black art days and modern search engines have today that potentially
qualify 10,000's or 100,000's results yet not wanting to render it all
for the user at one time. Of course on a text terminal there was no
choice whereas now we can put however much we are willing to because we
have scroll bars... but sometimes our scroll bars put navigation
buttons out of reach, like search engines typically do (I don't know
why perhaps something to do with making sure we see the display ads).
I always find that frustrating when I just want to click the next
button. So I guess what I'm getting at is that perhaps you can present
some amout of data like a screen full at a time and give the user a
button to see the "next 10 results". I wanted to point out that this
is not a problem you are facing just because you are working in a VM.
MS Access gives the user the alternatives of the form view (basically
one record[set] with pixel placement if so moved by the user) or the
Datasheet view which is basically using a layout manager. The
Datasheet view off course looks just like a spreadsheet which gives the
appearance of having rendered all recordsets just a scroll click away.
In reality it is just showing you what can fit on the screen (boy
doesn't that sound familiar) and renders only what becomes visible by
the user's scroll action or goto record or VCR buttons.
Perhaps you could give your users a similar choice and avoid rendering
too much at one time.
anon...@gmail.com
duc...@aol.com wrote:
> >Hmmmmm...not sure about the order of things here. The user hits
> >"save" when defining the GUI. That stores information in the
> >database. At a later time, perhaps by a different user at the same
> >location, the "real" application builds a specifically requested GUI
> >by looking into the database for definition of widgets, widget
> >placement and widget-to-database binding.
>
> Not that it really matters to the problem you are wrestling with, but
> the second user doesn't have to hit some type of "save" to send the
> "real" application data to the DB?
Not that it really matters, but the way the application currently
works, the widgets are "live" in the sense that merely changing the
data within the widget and exiting the widget causes the application to
fire an update event. This is expected behaviour and the users are not
upset with the "auto-update" feature.
> >It is the concept of iterating a recordset and building and placing a
> >widget during each iteration that concerns me. Especially if I have
> >50 or more widgets on a screen.
>
> and
>
> >In fact, the schema is self-expanding through a recursive structure.
>
> Just to see if I'm following you: you are concerned about bringing up
> on the user's display an existing recordset containing perhaps 100's or
> 1000's of "rows" each containing 50 or so fields from 1 or more tables
> that need to be displayed, maybe even some recordsets that are
> subordinate to that recordset and so forth (the recursive part)
> containing some number of fields from 1 or more tables. And you want
> to display the entire recordset and all children thereof for the user
> to be able to change what ever they want and at some point the "real"
> application decides when the changes should go to the database (this is
> where I thought maybe there was a "save" button of some sort for the
> real application).
Hmmmmm, no. Although what you have typed is an interesting concept.
In fact, none of my widgets are tables. They are all text boxes, check
boxes, radio buttons, labels, buttons, comboboxes, listboxes, etc. I
have not had any need for table-display to date as everything is
drilled down to its appropriate level with combo boxes. I suppose I
could just as easily display tables for certain data elements such as
listboxes. So, while I am using 50 or so fields from 1 or more tables
to populate the widgets, they each control the population of a given
widget. And no widget contains long lists. Perhaps 5 data elements in
a listbox might be tops. Comboboxes may have more, but not too much
more. In fact, the combobox for selection of state probably has the
most (a bit more than 50).
(snip)
> >The only thing I'm still on the fence about is how my application
> >should build the presentation layer. After reading scores of articles
> >telling me that pixel placement of widgets is EVIL, I need to convince
> >myself that there is an exception for my application's specific design
> >before I start laying down code.
>
> I think maybe the articles you were reading were not considering GUI
> builders for end users such as that subset of your application. If you
> were building a static application then definitely you would not want
> to get involved in pixel placement so that you can make changes here
> and there and everthing else will adjust. And you can set your user's
> expectations accordingly from the start each time you roll out a new
> version. Just as long as the user can live with that text field that
> moves below the line that it used to be on, for example. In most
> internal development IT can justify such things on the basis of cost
> savings as long as there is some kind of rollout demo. But when you
> say client I'm picturing people that are paying real money to you or
> your organization.
Indeed.
> Correct me if I'm wrong but I'm reading into your
> post that the "prototype" is already being used and your clients have
> much already laid out. If so, these people already have their
> expectations set and spent time/money putting things in a particular
> place or at least are used to them being there.
Indeed.
> The last thing you
> want is for them to see the java re-write as a take-away.
Indeed squared.
> You don't
> want them getting frustrated over trying to adjust the size of one
> field just to keep another field where it's at. Perhaps at a later
> time you can present to the customer base the real advantages they will
> see by losing their static positional lay outs in favor of layout
> manager with a poll. If they like it then roll it out in version 1.1.
> Look at MS Acess or something and notice there are wizards that will
> lay a record out on a form but then you can drag your fields around and
> it remembers where you left it. Looks like pixel placement to me. I
> think that's a pretty good example of what a real-world end user is
> going to expect. So ask yourself if an end-user GUI builder deserves
> the exception you are looking for.
Well, *I* think they do, but I don't have enough experience with Java
GUI under my belt to be comfortable with the decision all on my own.
I'm becoming more comfortable, BTW.
Unless somebody else chimes in with an alternate opinion, I'm getting
ready to pull the trigger.
> >I would guess that you don't know of a class that implements this sort
> >of thing, huh? <g,d&r>
>
> Right, I'm not aware of a publicly available class though I would tend
> not to look for one because that would be the fun part (I know, I know,
> supposed to re-use where ever possible).
With enough constructors I think I could develop a pretty neat class to
do it. I just didn't want to go down this path if there was already
something out there that did this.
One of the main problems with pixel placement of widgets is moving the
widgets around. Having to recompile every time you want to move a
widget can be a real pain. I suppose if I create a data abstraction
layer just for this purpose there are some that would relax the "pixel
placement is evil" mantra. Not all, though. Those that have invested
substantial time and effort into understanding the layout managers
(especially those that can put together a GridBagLayout in their sleep)
would still think this concept evil, I presume. No matter. I'm not in
any danger of publishing the magic class that renders layout managers
moot.
> It's the same thing that Oracle (Forms), PeopleSoft (Pages), MS ACCESS
> (Forms), etc do maintaining UI info in a catalog. They have the exact
> same problem (with large "recordsets") and they probably each approach
> it with different philosophies on what needs to be optimized and
> compromising in other areas. Just because you are working in JVM with
> emphasis on the VM I wouldn't write your application off as
> automatically being slower than these guys. Unless you are using custom
> widgets (which I doubt you would want to) JVM is or should be just
> making a lot of calls to native code for building all this stuff. Your
> code (the interpreted part that you are concerned with) will be
> insignificant compared to the amount of code that is being executed
> natively behind the scenes. Besides JVM is pretty darn quick in my
> opinion. So I would suggest that you are only negligibly handicapped
> by JVM and recommend you look at some of these other or similar
> applications and see their approach.
>
> I know PeopleSoft (now owned by Oracle) gives the users options: do
> they want to see just the top entry or all. The reason they do that is
> because they don't want to make the user wait for all that rendering.
> Same problem.
I hadn't thought about structuring the GUI with an overview/detail mode
selection. That might be what I want to do *IF* the GUI builder turns
out to be too inefficient to show all by default. Thanks for the idea.
(snip)
> So I guess what I'm getting at is that perhaps you can present
> some amout of data like a screen full at a time and give the user a
> button to see the "next 10 results". I wanted to point out that this
> is not a problem you are facing just because you are working in a VM.
Yes, that would also be a potential course of action if I were
displaying such large amounts of data. Thankfully, I'm not.
(snip)
Thanks for your insight. It is appreciated.
If there are any "pixel placement is evil" proponents out there that
want to beat me up, now is the time!
Jim
Monique Y. Mudama
>
> If there are any "pixel placement is evil" proponents out there that
> want to beat me up, now is the time!
>
For every design rule, there is a time and place where it actually
makes more sense to break the rule than to follow it.
The trick is recognizing when that is really true, and when you're
just fooling yourself.
So far, it sounds like pixel placement is probably fairly reasonable
for what you're trying to do.
--
monique
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
duc...@aol.com
>works, the widgets are "live"
If traffic is not an issue, I'm sure they like that a lot.
>Hmmmmm, no. Although what you have typed is an interesting concept.
>In fact, none of my widgets are tables.
I was just talking about the DBMS tables not presentation.
>One of the main problems with pixel placement of widgets is moving the
>widgets around. Having to recompile every time you want to move a
>widget can be a real pain.
I'm confused, I thought you were rendering the interface at runtime.
>Thanks for your insight. It is appreciated.
You're welcome. Just curious, what was wrong with the "prototype"?
Why the java re-write? Needed to support cross-platform?
anon...@gmail.com
> >Not that it really matters, but the way the application currently
> >works, the widgets are "live"
>
> If traffic is not an issue, I'm sure they like that a lot.
>
> >Hmmmmm, no. Although what you have typed is an interesting concept.
> >In fact, none of my widgets are tables.
>
> I was just talking about the DBMS tables not presentation.
>
> >One of the main problems with pixel placement of widgets is moving the
> >widgets around. Having to recompile every time you want to move a
> >widget can be a real pain.
>
> I'm confused, I thought you were rendering the interface at runtime.
Right, but I thought you suggested having the classes compiled. Sorry
if I misunderstood. I thought you were suggesting that the user define
a GUI, which I then use that information to build a class, which I then
compile so that instead of me building the GUI at runtime based on the
database, it is pre-built and compiled. That would work if the GUI's
were non-volatile. They aren't. They change frequently based on user
preferences (which can flap like a flag in the wind). Again, sorry if
I misunderstood.
> >Thanks for your insight. It is appreciated.
>
> You're welcome. Just curious, what was wrong with the "prototype"?
> Why the java re-write? Needed to support cross-platform?
In a word: yes.
Thanks again.
Jim
duc...@aol.com
Oh ok, no you didn't misunderstand. I see now you were just addressing
that alternative one final time.
duc...@aol.com
comp.lang.java.programmer? I know this a GUI item but there's more
action over there than here.
anon
I shall do so.
Thanks
Jim
duc...@aol.com
>works, the widgets are "live" in the sense that merely changing the
>data within the widget and exiting the widget causes the application to
>fire an update event. This is expected behaviour and the users are not
>upset with the "auto-update" feature.
Thanks for satisfying that curiosity... if traffic is not a problem I'm
sure they like that a lot.
>So, while I am using 50 or so fields from 1 or more tables
>to populate the widgets, they each control the population of a given
>widget.
Yeah, when I mentioned tables I was speaking of the underlying DBMS
tables not presentation.
>One of the main problems with pixel placement of widgets is moving the
>widgets around. Having to recompile every time you want to move a
>widget can be a real pain.
I'm confused now, I thought you were rendering the UI at startup based
on the current contents of the UI tables and not need recompilation?
But back on that subject by the time a layout manager is done, doesn't
each widget have x, y, width, height properties? Since you aren't hard
coding pixel placement any more than a layout manager, essentially
there is a part of your code that is itself a layout manager letting
users put things where they want. So in the end doesn't your layout
manager have just as much right to give a widget x and y as any other?
>I hadn't thought about structuring the GUI with an overview/detail mode
>selection. That might be what I want to do *IF* the GUI builder turns
>out to be too inefficient to show all by default. Thanks for the idea.
Well, that's not what I was talking about, I was just talking about the
most recent row when I said top.
But its always interesting when one idea is interpreted with an
unintentional meaning and a better idea comes out of it.
Good luck and I do hope that you get an alternative viewpoint to keep
things in perspective.
anon
>>One of the main problems with pixel placement of widgets is moving the
>>widgets around. Having to recompile every time you want to move a
>>widget can be a real pain.
>
>I'm confused now, I thought you were rendering the UI at startup based
>on the current contents of the UI tables and not need recompilation?
I must have been imprecise in my description. I was, with the above
words, re-iterating why I wanted to retain my current program flow.
So, you are correct, I am rendering the UI at startup based on the UI
tables and there is no recompilation involved.
>But back on that subject by the time a layout manager is done, doesn't
>each widget have x, y, width, height properties?
Certiainly.
> Since you aren't hard
>coding pixel placement any more than a layout manager, essentially
>there is a part of your code that is itself a layout manager letting
>users put things where they want. So in the end doesn't your layout
>manager have just as much right to give a widget x and y as any other?
I suppose that is the point.
Let me elaborate. The purpose of layout managers is to allow
cross-platform idiosyncrasies to be properly handled. Once an
idiosyncrasy can be handled locally, one of the main functions of the
layout manager evaporates.
Since each user can reposition a widget and resize the widget with my
program, if, for example, a label ends up being too narrow to hold the
text, it is a simple matter to fire the UI modification routine and
save a wider width for the label in question.
So, theoretically speaking, as long as the users have enough control
over the UI to prevent problems and/or fix problems, should they
arise, the need for a layout manager is lessened.
This is not to say that a layout manager might not still be helpful in
some circumstances.
But the more we talk about it the more I'm convinced that, in my
circumstance, using pixel placement is fine, because the user can
overcome any problems and since the UI definitions are persistent,
once they are overcome, they are overcome for future executions as
well, without requiring modification every time.
>>I hadn't thought about structuring the GUI with an overview/detail mode
>>selection. That might be what I want to do *IF* the GUI builder turns
>>out to be too inefficient to show all by default. Thanks for the idea.
>
>Well, that's not what I was talking about, I was just talking about the
>most recent row when I said top.
>
>But its always interesting when one idea is interpreted with an
>unintentional meaning and a better idea comes out of it.
Indeed.
>Good luck and I do hope that you get an alternative viewpoint to keep
>things in perspective.
I would welcome other input.
Thanks again
Jim