From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,a875d9649dde34e3 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!HSNX.atgi.net!cyclone.bc.net!news.uunet.ca!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Coupling or not coupling database and GUI libraries References: <10lr18i6h426o82@news.supernews.com> <87vfdutlg2.fsf@insalien.org> <87mzyglzkm.fsf_-_@insalien.org> In-Reply-To: <87mzyglzkm.fsf_-_@insalien.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <1CVdd.27477$J16.1594687@news20.bellglobal.com> Date: Thu, 21 Oct 2004 17:11:20 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1098393085 198.96.223.163 (Thu, 21 Oct 2004 17:11:25 EDT) NNTP-Posting-Date: Thu, 21 Oct 2004 17:11:25 EDT Organization: Bell Sympatico Xref: g2news1.google.com comp.lang.ada:5600 Date: 2004-10-21T17:11:20-04:00 List-Id: Ludovic Brenta wrote: > As a backgrounder on my experience: a few years ago, I wrote a 120 > kSLOC application in Java that did just that - an interface to a > database. The front-end started as Swing but changed to HTML and a > bit of Javascript. There was an abstraction layer over the database > that supported Oracle, DB2 and DB2/400 and provided the database > schema metadata to the visualisation layer. There were a connection > pool, several caches of metadata and data, and application-level > permission settings (authentication was delegated to the database > server, authorisation done in the application). Ah, but you had to _build_ something, which is fine. I am not suggesting an _implementation_, but I do think it needs to be handled somehow. To do this elegantly, I believe that GUI and database packages need to at least plan for the possibilities. > I have several concerns with tight integration of GUI and database > libraries. > > 1. If every widget can be attached to a database query, will every > update to a widget not cause an SQL query? This should be avoided. No of course not. This is configured at the point of building the application (whether by GUI in Delphi or by some other means). > 2. If every widget is attached to a query, is it possible to update > several widgets with one query, i.e. that several widgets be > attached to the same query? Again, widgets are not hardwired to any database "concept". But yes, it is possible in MFC for example, to associate multiple widgets with column data. Someone with a better memory help me out here: there is some kind of xfer event or API call. > 3. Is it possible to perform arbitrarily complex, application-specific > formatting to the data as it goes back and forth between the > widgets and the database? Complex cases always tend to be a "do it yourself" approach (no surprise there). The there are many mundane cases that can be handled elegantly. The simplest case is perhaps like the Dbase case of a form matching a row of data (not using Dbase terminology). > In the application I mentioned, we would routinely do queries that > joined 5 or 6 tables, and we had lots of heuristics to help speed that > up. In one of the screens, we would present a tree structure > constructed from oh, perhaps 10 different queries. Joins by themselves are not a problem if you're only presenting data. Doing updates are a bit different of course. What you want to do is eliminate most of the grunt work. You won't eliminate it all, but you can do a lot of it. Out of a large application where you might have 200 screens, most of them will be stupid and simple, and I see no point in handcrafting it all ;-) > I have not really had a deep look at either Delphi, MFC, Delphi and MFC had ways to make your life much easier with databases. MFC fell down when it came to handling NULL values in calendar widgets etc., but it tried. > or GWindows, > but I suspect that coupling the GUI and the database libraries is only > useful for quick-and-dirty work when you want to create forms where > one form=one record in the database. I have to disagree. > But for anything more complex, such coupling just gets in the way. Much of the necessary coupling is grunt work. We have more creative things to be doing. > In > fact, it is the job of any non-trivial database GUI to perform the > "grunt work" you mentioned, and I cannot think of a useful way the > library could ease that. Well, you admit to not having tried it. Try it first, and then you might see that there is at least a partial solution. > Or perhaps you were only thinking of > marshalling and unmarshalling of individual database fields to and > from the database? Nope. Column X must have its data populated in a control. WHen a save occurs, you must do the reverse. Grunt work, plan in simple. Multiply that by the number of column-widget pairs. More grunt. It is also easy to automate this kind of stuff, with the right kind of organization. > Java's JDBC is not tightly coupled with Swing or AWT. Both APQ and > GNADE are similar in concept to it, or the ODBC API which is also not > coupled with any GUI. APQ is not currently linked to any GUI. I would like to perhaps make a change on that score someday, but I haven't had much time to plan it yet. > I do not think it is wise to have a GUI-dependent database library. Think in the larger sense of solving the problem, rather than its implementation. How it is solved is unimportant to me, but it does need to be solved. GUI and databases are frequently cousins. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg