Fog Creek Software
Discussion Board

Don't Define the Interface in the Database.

Has anyone worked on a project where the interface is defined and stored in the database?  Does anyone here practice this on a regular basis?

To further clarify:  The window and its controls attributes ( x , y ) ( left , bottom ) etc etc... are stored in tables in the database and then "dynamically" created/loaded when it is time to display the window.

It wreaks havoc on code readability and especially maintainability.  It also takes about a million percent more time to modify the interface than if you could just simply drag the control via the VB IDE (or what have you).

Hmm... I have to move this button to the left to make room for a button for a new feature we are adding.  I can't just drag it because it is dynamically created.  So I have to search through a plethora of tables in the database to find the one that holds it's values. I then have to play around with these values until I get it right.  Now, try resizing or (heaven forbid) adding a control...

The genius programmer who coded this had the foresight not to document any of it.

I hate looking through hundreds of tables in a database to change the location of some button on a window because some shmuck programmer thought they would be slick and "(encrypt)define the interface in the database" to make their code "tight".  Not to mention that there would'nt be hundreds of tables in the database if the interface was'nt defined in there.  Very poor programming practice in my opinion.

Lesson:  Don't define your Interface in the database.


Dave B.
Friday, January 31, 2003

I have worked on a few meta data driven applications, typically if you write a good administration application for allowing users to define the meta data in a meaningful way they should be shielded from the complexities of the application, they define what they want in a way they understand and the application delivers it to them.

Great for the user, harder for the developer, especially if the data can define a huge number of configurations.

I nearly pulled all my hair out on one particular application about 4 years ago that I developed to do this.

I feel your pain.

In hindsight though, it's probably my proudest achievement.

Saturday, February 1, 2003

This was perhaps the output of some junior developer who felt that he was being "high level" by representing the GUI layout in the database. Also, we don't know what the developer may have been told to do by his management or the tech lead.

IE: some development groups develop a cargo cult mentality of replacing common platform or user interface objects with their own layer of code. I once worked in a group that developed their own VB code to replace the existing VB data aware component logic... with their *own* (slightly different) data aware component logic. It ran MUCH slower than native VB data aware components.

Actually, you have the opportunity in hand to correct this issue. You could simply write a piece of code generation logic that walks through the database and writes out the form layouts to resource or layout form files given the parameters in the database. Then you could load these forms into a new project and eliminate the databased form layouts for once and for all.

Bored Bystander
Saturday, February 1, 2003


Check this out. 

Forget the example framework he lets you download - I've spent most of the day trying to understand it and get it to work, but I like the idea a lot.

I'm sick and tired of doing UI stuff - and then the user wants that control moved over a millimetre, "oh, and it has to be in the Trebuchet MS font, and it needs to be this really garish green colour." (Forget what the textbox content is *actually*displaying - Mr Customer, is it displaying the correct content in context? It is? Oh good.)


Anyway, I wrote a form designer that lets you add controls and move em around, so storing the locations etc in the database isn't such a big deal - just getting them out and building the form at runtime is a performance hit.

Here's another form designer:

I haven't tried it yet.

There has *got* to be a better way.

Saturday, February 1, 2003

This is an area in which I am extremely interested.

I have created several web applications where the interface is defined in the database to varying degrees (although there are not hundreds of tables for the UI - that would truly be nightmarish). 

The first application worked out really well, because the goal was to abstract out the complexity of building a form.  So the user just enters in each line of the form into the database and creates the form on the website. Since the form has a rigid function and look, although the specifics on the form change each time, this was easy to automate.

The next application used the defined interface on a limited basis not only to add new fields, but also to create the SQL necessary to update the database with the values for the code to work.  In other words, if we decided to add a new field to the search form, I can add it to the UI table and not only will the field now show up, it will also work.  That was pretty cool (and has saved lots of maintenance time), but as you can imagine, somewhat limiting, since the logic for the search had to be autogenerated.  It also means that some forms are much more fun to change than others (as this was only implemented on a limited basis across the application)

We've since tried various other ways of defining the interface in the database, with varying degrees of success.
I've certainly run into the problem of too much abstraction, as well as difficulties handling sequences of screens (ie you start with a single field, based on the selection of the field, the UI will behave differently).  But, for what it's worth - I still think it is a goal worth achieving if the problems can be overcome, because it makes it much easier to make the application entirely bilingual (important here in Canada) and because it makes it possible to put a UI manager on top of the database so that the client could then edit their own UI to a certain degree (I too think there has to be a better way <g>).

Saturday, February 1, 2003

I suspect that the implementation described in the original post was seriously flawed. There's no reason why you'd have loads of tables to represent the UI.

In general, I believe that it is a good idea, for reasons already mentioned. I'm just embarking on an  ASP.NET application for one of my clients that will be done in this way.

The way I see it, is everything in the application is "task-based", i.e. you can view the data (Insurance policies and claims, etc in this case) and then select a "task" to perform. A wizard then guides you through the various stages to complete the task.

This seems to work quite well, although I've only done some early prototyping so far. The read-only screens and the steps of the task wizards are easily defined in the database, as well as the rules, etc for permissions, inter-dependencies between objects, etc.

I am intending to build a maintenance sub-system too, so that certain Users can go in and amend or add to the existing functionality. This will, of course, be task-based and use the database-defined UI rendering system.

Steve Jones (UK)
Saturday, February 1, 2003

The problem is the lack of a tool to modify the user interface not where the data is stored. Without the IDE it would not be any fun to design a screen in Vb either.

One area where the database design makes some sense is with fat clients that are installed on a lot of systems. Changing the client means installing the change on X machines. Changes to the data base affect everyone without touching the client machine.

John McQuilling
Saturday, February 1, 2003

"The problem is the lack of a tool to modify the user interface..."

Yup, that is obviously a part of the problem in maintaining this program.  The other part is lack of documentation.

"...not where the data is stored."

I disagree.  If the user interface information had not been placed in the database to begin with, the program would be much easier to maintain.  If there was a tool that would change the values in the database for you, that tool would only work in and be specific to certain situations/modifications within the program.  It seems to me that this "tool" would also simply be a reinvention of the wheel.

If I could observe a well written application that makes use of this concept without negative side effects, I would consider changing my view.  Until that time, I will not practice nor will I recommend the practice of defining the interface in the database.

Dave B.
Saturday, February 1, 2003

There is absolutely zero problem with the user interface being defined in a database.

What the heck do you think a VB form is? It is a bunch of objects on a screen. The position and attribute for each control is stored in a file. That file for purposes of arguments is simply a data structure. There is ZERO REAASON AS TO  remove this setup and store the GUI in code?

This is complete miss-understanding here.

While there are a lot of 4th GL programs that generate code such as the older FoxPro, they all stored the screen designs in a database.

In fact, I have OFTEN wished that VB worked this way (it creates the meta code in place of using a bunch of x,y values stored in a database). The meta code was used since it allows the design to be extended in a easier fashion then data strictures being written to a database, or stored in some array. (my forms package I wrote did use arrays, and I now understand why VB uses meta code to solve this problem).

I have also used a good many 4th GL systems and systems that are template driven. However, the real key here is to provide good tools that let you built the GUI. (and more importantly modify the GUI).  4th GL systems fall on their face if you start modifying the code they generate. (since then, you can’t go back to the original database that defined the are toast in that case).

So, lets not confusion the great and good idea of storing the GUI in a database with some stupid person who does not provide the tools to edit that GUI.

Storing the forms and templates in a database is about the best way one can go.

The most popular GUI builders out there use some type of database to store the position of controls on a screen.

The use of 4th GL systems to actually generate coded an compile it have gone the way of the do do bird.

I hate to burst everyone’s bubble, but modern development systems all use a data structure to store the screen, and not actually c++, or VB code!

Without question the software industry as a whole has been, and is moving in the direction of storing apportion data (the GUI and position of controls) in a database.

Why do you think all of  the game builders now use some script engine? Why does virtually every modem GUI development tool in the market store the GUI as data, and not code? 

    You can add new features to a screen (or a game script) and not have to re-compile the whole application. You can move a text box on a screen, and not have to re-compile 100,000 lines of code.

Do any of the modern screen builders, and especially the report writers store the results in code today? Anyone, please correct me here!

Delphi, Kylix, VB, ms-access, etc etc etc and the list goes on an on ALL STORE THE GUI stuff in a data structure that is retrieved. These data structures are then used (interpreted) to produce the final application screen, or report. NO ONE stores the GUI layout in code anymore. The industry did that 20 years ago.

Surly one is not suggesting that we through out this concept of storing the GUI in a data structure and go back to the 4th GL code generators of yesterday?  (they certainly were popular with products like dbase, and FoxPro was a 4th gl).

Since every modern development system has adopted this idea of storing the GUI in a database (template), then should not we all do this also?

Of course we should!!

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Sunday, February 2, 2003

"What the heck do you think a VB form is? It is a bunch of objects on a screen. The position and attribute for each control is stored in a file. That file for purposes of arguments is simply a data structure. There is ZERO REAASON AS TO  remove this setup and store the GUI in code?"

A VB Form is not stored in a relational database.  What do you mean store the GUI in code?

"However, the real key here is to provide good tools that let you built the GUI."

Point out a user defined tool that is not specific to one problem or that does not only allow modifications of certain parts/features of an interface.

I am not talking about Access, Fox Pro or any other database specific Forms. I am talking about an application coded in Visual Basic 6.0 talking to an Access 97 database via DAO 3.51.

"So, lets not confusion the great and good idea of storing the GUI in a database with some stupid person who does not provide the tools to edit that GUI."

I agree a tool would make it a lot easier to edit the GUI, but why re-invent the wheel?  Why not simply use the VB editor to begin with?

I do realize that the GUI configuration has to be stored somewhere, but that place is not in the relational database.  Let VB store the information so you don't have to store it again in the database. VB is in fact the original tool.  Why build a tool on top of a tool?

The fact is every GUI based program has to store it's interface information somewhere.  One of the best implementations of a GUI system is in the MMORPG game Everquest.  It uses XML to define and store it's interface.  If you want to modify the interface you edit the XML, but it surely does not store that interface information in the relational database of game specific information.

Even reducing compile times or making somewhat of a "thin" client are not good enough reasons to convince me that storing interface information in a relational database is worth it.  You simply duplicate and re-invent things needlessy.

Dave B.
Sunday, February 2, 2003 should also point out that dynamically creating and positioning controls in VB is very buggy.

I once did this for a very large application that consistent of many long forms.  It was a very large data collection application and the amount of information needed to be filled in by the poor users was incrediable.  The forms were in scrolling windows w/ tabs.

I didn't want to code and position all those form fields by hand (especially since the information that needed to be collected changed daily on the project) so I built a system that dynamically built the forms.

The app could only be run about 5 times on a Win98 machine before it ran out of resources and the computer had to be rebooted.  Further, I had to "cache" the created form elements and reuse them rather and create and destory or you couldn't get through more than a few screens before it ran out of resources.  VB, it seems, likes to allocate resources but it doesn't like to return them!

I highly recommend against it.

Wayne Venables
Sunday, February 2, 2003


Don't get me started about MS VB forms and controls. In MS Word they have the "fast format button" that works wonders. If they had the same button in VB6 it would be a miracle worker. Yes, with some effort I could probably design something like this, but Aggggg, I have several projects I must  complete first! I can think of a million little things about designing a UI in VB that makes me want to destroy things.

I hate it that the pre-packaged data linkage controls don't work better. You end up coding all your data connections over and over again...

That is unless you've learned a quicker way to do it, which I have not.

Sunday, February 2, 2003


You mentioned XML - something like this? (my creation, copied from IE 5.5 - no indentation)

etc etc

Then, use some XPath to get the values....

    sXML.async = False
    sXML.setProperty "SelectionNamespaces", "xmlns:xsl=''"
    sXML.setProperty "SelectionLanguage", "XPath"
    On Error Resume Next
    sXML.loadXML ControlValues
    If Err.Number <> 0 Then
        MsgBox Err.Description
        lngType = 0
        Dim txt As TextBox
        Dim strValue As String
        For j = 1 To colIDs.Count
            Set iNodeList = sXML.selectNodes("/OBJECTS/OBJECT[@ID='" & colIDs(j) & "']/PROPERTYLIST/PROPERTY")
            Rem now, get the CTRLTYPE node (because we have to know that first)
            For k = 0 To iNodeList.Length - 1
                If iNodeList.Item(k).nodeName <> "ID" Then
                    If iNodeList.Item(k).Attributes.getNamedItem("NAME").Text = "CTRLTYPE" Then
                        lngType = Val(iNodeList.Item(k).Attributes.getNamedItem("VALUE").Text)
                        Select Case lngType
                            Case 1          'textbox
                                Load txtData(txtData.Count)
                                Set txt = txtData(txtData.Count - 1)
                                txt.Text = ""
                                txt.Visible = True
etc etc

and then go set properties...

                    Select Case iNodeList.Item(k).Attributes.getNamedItem("NAME").Text
                        Case "VB_LEFT", "VB_WIDTH"
                            strProperty = iNodeList.Item(k).Attributes.getNamedItem("NAME").Text)
                            strValue = Format(Val(iNodeList.Item(k).Attributes.getNamedItem("VALUE").Text) * Screen.TwipsPerPixelX)
                            If strProperty = "VB_LEFT" Then
                                txt.Left = Val(strValue)
                            ElseIf strProperty = "VB_WIDTH" Then
                                txt.Width = Val(strValue)
                            End If
etc etc

It works fine - just really slow on my box. I've also tried CallByName as in:

CallByName txt, strProperty, vbLet, strValue

setting strProperty to the actual property name ie: VB_LEFT becomes simply LEFT.

BTW - the XML is being pulled from tables in a database that specifically support the concept. (1 row per property, just like in the VB .frm file), but I'm thinking seriously of removing all the form/control property stuff out of the DB, and perhaps just maintaining the XML file on disk.

Alternatively, a .frm file parser would probably be even better - the .frm file format is a published interface - design the form in the VB IDE, and save it with the app. App starts up, reconstructs the form from the .frm file at runtime.

You could even include remarks in the .frm file that the app could read to set certain things up, like populating picklists etc as its building the form (an idea from the URL I posted)

Sunday, February 2, 2003

Bradzo >> "You mentioned XML - something like this?"

The problem that I see with that Bradzo is that you are still dynamically creating the interface and are doing so using VB, which is, in and of itself a RAD design tool.  As Wayne mentioned his application is memory and data intensive and brings windows to it's knees.  This happens with the application that I am working on also, and I am convinced that it is because of the silly interface in a database thing.

When a form is called for, a recordset with interface information is loaded and then parsed and the interface elements are dynamically created, positioned and displayed through VB Code.  Sounds good in theory, but when you have one event handler for each type of interface element created using this method, it results in long "case" or "if" statements that become sloppy with an increasing number of situations that must be handled.  You are also increasing memory requirements.  On top of that the author of the program found his "ingenius" solution did'nt cover every situation and coded "around" his own interface code, did'nt write an interface manager or document any of it.

So, Instead of simply loading the form you designed in VB via the VB "Load" statement, you have created a monster that uses many times more memory and system resources by needlessly accessing a database, and dynamically creating these elements.  All of this is to avoid the use of the original tool (i.e. VB).

If there ever is a need for such a beast, it would probably be best to use a systems language such as C++ to build it and even at that it would be very specific in nature.

As for XML; In my open the Everquest XML defined interface works well for several reasons. 

1.  The code for the interface is written in C++, a systems language, which is not garbage collected and so resources are managed by the programmer. 
2.  XML is easily distributable over the internet (EQ is an online game) and has a natural hierarchical structure.
3.  It is "relatively" easy to modify the interface to suit your needs.

Would I go out and design an interface defintion in XML for a VB project, absolutely not.

Dave B.
Sunday, February 2, 2003

If you're really determined to do this why not write a parser that generates .FRM files out of XML? Actually if you look at the .FRM files they already contain pretty much what you're trying to recreate here...

Joel Spolsky
Sunday, February 2, 2003


So it seems the general consensus is that creating forms dynamically at runtime is a bad idea.

So, how does everyone manage changes that come back from the customer? ie: move this textbox over 1 millimetre, oh, and we need an email field too. Can you bung that in and have it back to us this afternoon?

Hello change management.

I suppose I could do all that, and then charge them for my time, but I guess, like me, you have had "arguments" with the customer about what you charge for adding that one field (because they have absolutely no idea of what is involved in adding that one field)

Besides, I have a life too, and I want to enjoy it, not stay up till midnight coding.

Hell, I've even had customers say that they don't like the font I used on a report - regardless of whether the report is actually correct (*that* doesn't seem to matter). Ignore also for the moment Mr Customer how much time went into creating the report in the first place. All they see is how it looks. Ok, I understand that, but don't whinge at me about how much I'm charging you when I'm up till midnight changing your application because you needed it last week.


I think I'll just go mow lawns for a living.

Sunday, February 2, 2003

>>>A VB Form is not stored in a relational database. What do you mean store the GUI in code?

This is exactly my point. It could have been! The fact is that VB stores the layout of the form some where (why do you care where? Why is this a big deal?). You are NOT the one who stores and manages this data!!! The forms designer in VB6 deals with this. Why would it be bad if that data was stored in a database? Why would you care?  You would still never have to look at  the actual layout data anyway!

My whole point here is that every development system (and that includes VB6) stores the frm data in a structure. Of course that structure in VB6 is not a database, but it well should have been, and further it  COULD HAVE BEEN. Fact is, if it was stored in a database, you would have incredible increased flexibility here. You would be able to do queries and search/replace attributes and proerties of each contorl (further, you could modify several forms, or even all forms in the system with one command!).  You would also be able to view/edit the controls in a datasheet view like excel. The advantages of storing layouts in a database are far too long to explain here. You then can even generate reports based on screen data for documentation etc.

Thus, the systems that I have used are just fabulous in this regards.

The only down fall in the original posters issue is that storing “GUI” interface code is ONLY A BAD idea if proper tools don’t exist to edit that data after words!.

Since every single major development system today in fact stores the form layout data in some structure, it is silly to state that one should not store the GUI form layout data in a database?. This is EXACLTY HOW most applications SHOULD work.

What I am saying to don’t shoot the concept of storing the positions of controls and their behaviors in a database. That is certainly the way to go. The fact is the VB6 does store the position of the controls in a data structures OUT SIDE of the code. That is what I mean by saying that the forms are not simple straight code, but a bunch of values storied away some where.

So, I am simply saying that the idea here is that is is a very good idea to store application data such as forms layout in some data structure rings true. Every single major development platform in fact does this.

Of course, since we already have a form builder in VB6, then it is stupid to create your own. Unless of course that new one is better or provides features that the existing one does not have!!. Again, this whole concept only falls on it’s face when the proper tools ARE NOT included with the approach!

If the original comments are don’t re-invent the wheel when it is not needed, fine. If the original comments are placing screen layout stuff in a database is dumb WHEN tools are not provided again, then I have no beef here.

However, I totally disagree with the concept that screen layout stuff should not be stored in a database. It most certainly should. However, if the GUI designs tools that create the interface forms don’t work with that database then you have a hug without the kiss! It is a half solution, and then of course we have some debate here.

The debate is thus now not storing the GUI layout in a database as one should, but the debate is what tools, and what benefits occur when you do this.

If you have the right tools and the forms layout are stored in a database, then the concept wins hands down every time.

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Sunday, February 2, 2003

Also, just to save few people jumping in here.

Joel mentioned the idea of driving xml from the frm layout meta code.

There is no reason why that form layout stored in the database cannot produce the meta code that you now get in a vb6 form. Don’t make the assumption that the code at run-time must interpret the data from the database.

In fact, you could even write code to generate the VB6 form, and compile/distribute that with your application. . This of course is what 4th GL systems do anyway.

A mentioned, I have used many 4th gl systems, and they fall down if you have to edit, or tweak the resulting reports/forms from that system.

You ALWAYS need to be able to go back to the original source definition (in my point, that means the original database).

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Monday, February 3, 2003

Albert, your premise is wrong, and so is your conclusion.  But you're close.  The .NET Framework way of doing things accomplishes what you want, without the disadvantages of a database-driven approach.

First, a little background.  Yes, VB's .frm files store a little "database" of the form's elements.  Here's an actual VB 6 .frm file:

Begin VB.Form Form1
  Caption        =  "Form1"
  ClientHeight    =  3090
  ClientLeft      =  60
  ClientTop      =  450
  ClientWidth    =  4680
  LinkTopic      =  "Form1"
  ScaleHeight    =  3090
  ScaleWidth      =  4680
  StartUpPosition =  3  'Windows Default
  Begin VB.CommandButton Command1
      Caption        =  "Command1"
      Height          =  615
      Left            =  960
      TabIndex        =  0
      Top            =  720
      Width          =  1815
Attribute VB_Name = "Form1"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = False

But in all versions from VB 4 on, a form is nothing but a class module plus a designer.  It's just an object with a user interface.  VB doesn't iterate over the contents of a .frm file at run-time.  Forms are translated at compile-time into a series of calls to many many Windows API functions.  If these API calls were re-generated each time the form was displayed, it would be unnecessarily inefficient, which is what would happen if it were database-driven.

The argument about "everyone is moving away from code-driven UIs and towards database-driven UIs" falls apart even more when you look at how VB.NET does forms.  Here's the equivalent section from an actual VB.NET form:

Friend WithEvents Button1 As System.Windows.Forms.Button
<System.Diagnostics.DebuggerStepThrough()> Private Sub InitializeComponent()
  Me.Button1 = New System.Windows.Forms.Button()
  Me.Button1.Location = New System.Drawing.Point(88, 80)
  Me.Button1.Name = "Button1"
  Me.Button1.TabIndex = 0
  Me.Button1.Text = "Button1"
  Me.AutoScaleBaseSize = New System.Drawing.Size(5, 13)
  Me.ClientSize = New System.Drawing.Size(292, 266)
  Me.Controls.AddRange(New System.Windows.Forms.Control() {Me.Button1})
  Me.Name = "Form1"
  Me.Text = "Form1"
End Sub

Note this is straight VB.NET code.  There is no other "UI database" hiding somewhere that holds this information.  This code is produced by Visual Studio .NET, and it cautions you not to modify it, but there is no other database for this to get out of sync with if you do.

You mentioned the increased flexibility that would come from storing the UI in a database, including being able to "do queries and search/replace attributes and properties of each control, modify several forms or even all forms in the system with one command, and view/edit the controls in a datasheet view like Excel."  This kind of flexibility is available in the .NET Framework using reflection.  It uses the metadata in the .NET assemblies to look at any object/class (not just UI elements) in any level of detail.  So in a sense this metadata is the "database" that you feel should be the main representation of UI elements.  But in the .NET Framework, this metadata is just supplementary info, while the real implementation is stored in compiled, executable code.  If you need the metadata, it's there, but we're not going to sacrifice performance by always using the metadata to generate controls at run-time.

In the end, it comes down to a trade-off between flexibility and performance.  If you want additional flexibility, you must sacrifice performance.  In most cases you don't need the flexibility that reflection provides.  You'd rather have performance.  So you turn the UI into inline code for performance purposes.  But if you do need to make an exception, you can always to to the metadata using reflection, taking a performance hit.

If instead your default representation of the UI were in a database, you would automatically get the flexibility of "reflection" through SQL-like queries, but at the cost of decreased performance.  I suppose you could then generate and cache "inline" UI code from this database at run-time if you needed better performance ("reflection emit" lets you do this), but since you rarely need this level of flexibility as much as you need performance, it makes more sense to start with inline code and move to metadata in special cases than it does to start with metadata and move to cached code generation in special cases.

I wish I had the skill with words to have said this with a shorter post, but hopefully this makes sense.

Monday, February 3, 2003

Oh, to hell with it.

I think I *will* go and mow lawns for a living.

Sunshine, fresh air, smell of cut grass...... ahhhh


Monday, February 3, 2003

Hmmm, there appears to be some confusion.

If the interface (the UI layout and behaviour that is) is not abstracted from the code then you have a maintenance problem.

Just about all user interfaces are abstracted, whether its in resource files, FRM files or in Visual Fox tables or a UI syntax like XUL.  The actual form that the UI is stored in is, on the whole, irrelevant.  You could separate it so far as to make it inefficient but stupidity is not a measure of reasonableness.

The efficiency of separation at runtime can be surprisingly good as well.  XUL, for instance, is entirely interpreted at run time.

Quarrels about whether its stored in a database or not are specious.  A database does not necessarily mean a relational structure held on a server somewhere, a database is any structured data.  So its a bit of a tautology.

If the question is whether to store UI on some remote server and access it every time the application runs then that comes down to implementation.  If its an extremely efficient structure and the client has the necessary power in its rendering then there's no reason why not.  Again, XUL is a prime example of this.

Simon Lucy
Monday, February 3, 2003

Funny how I added my 2nd post right after my first, since I realized that many would state the issue of performance.

I think one other point there is some are pointing out that one should not build the screens at runtime. (in fact, this really what the original poster is stating, more so then the issue of a database driven system).

Remember, storing the representation of the screen layout in a database does NOT mean that we HAVE TO build the screen at runtime from this data. (no more so then what VB6 does with the current frm file). Most (in fact all)  4th GL systems are code generators. So, those screen defs could build C++ or VB or whatever code the 4th gl system likes to generate. Hence, the issue of performance is a non issue if you use a code generator here. (again, the original poster was specifically talking about run-time creating of forms here, so I want to be the most fair, and point that fact out)

Further, while VB6 obviously takes the frm file and compiles it down to some series API calls, it still is represented in some data structure (other wise, you could not change the location of a control at runtime could you?). So, just what does the complied code for a screen look like? Hum?  In fact, what does a active screen data structure look like? Just what does a frm file get compiled down to?

Simon is correct that we are splitting hairs here. A data structure is a data structures. We can abstract this as much as we like here. It does not break or beg the issue of a data structure can represent the screen. What code, or even if you interpret after is not a big deal.

However, that meta code from .net sure looks like directly executable code. Does this have any remafications when you re-position a text box on a screen at run time?

When you edit a .net screen, does it re-create the layout from that meta code as above? If that is the case, then we are looking at a 4th gl system here!

We are getting off topic here, but the VB6 forms are not them selves execute code, but that .net sure does look ok.

While most of the 4th gl systems I have used are database driven.

Having a code system that interprets and re-creates the screen from the actuall source code generated by the screen builder is most certainly a leap forward, and that does seem to be what does here.

Anyone, is the screen def code in .net actual true source code?

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Monday, February 3, 2003

Yes, the form code is actually source code.

Yes, if you were masochistic enough you could write it yourself without the designer.

The question is, what difference does it make?

It doesn't make any difference as far as run time positioning of the controls.  You can still move 'em around if you need to.  They're just objects (like everything else under .NET)

Actually spent the weekend going through "Programming Microsoft Visual Basic .Net" (Microsoft Press) and I gotta  So far it looks as if all the things that really annoyed me with VB6 have been fixed. 

I'll be doing my next project on .NET (a call center app), so I'll get to find out all the things about .NET that are really annoying, but so far, from just reading and trying out a few samples, I have to say that it looks like MS did this one right.

To get the thread back on track...Dave B., you have my condolences, but remember...just about everybody has done the same thing at least once.  I did, because the damn data requirements changed daily.

I'm sure that developer went on to kick himself in the rear at some later point just as I did.

If you really want to get rid of it, try writing a piece of code to pull all the form stuff out of the database for you and write it back to the files.  It may or may not be worth the effort , only you can say for sure.

Steve Barbour
Monday, February 3, 2003

To further the on-track ratio, I have a situation where I'm about to design something like this.  The reasoning is basically the flexibility issue -- we want to provide a way for administrators and superusers to build and save queries to our index server.

I had originally envisioned this as a thin layer on top of ADO parameterized queries, where the "build" process involved them putting together a ADO Command object (eventually in some kind of yet-undetermined pretty GUI) with parameters, and the "use" process involved getting that ADO Command back out and filling in the parameters.  Basically my GUI concept for "use" was something like, present a column of boxes in paramter order, with each box having the parameter's name for a label, and data validation based on type information.

Apparently my coworkers want to supply more type information than an ADO Parameter, and they want to make the interface editable at the "change the font, move this box one pixel to the left" level rather than just dynamic.  Ack!!  I don't entirely see the benefit of it myself.  Those of you who do, tool/standard recommendations??  The backend of this system is in C++, the frontend is expected to be mostly VB6, if that helps.  Oh, and people here luuuuuv XML far more than a verbose data file standard with some code libraries deserves ;) so if you know some kind of XML-based thingy be sure to mention it.

Monday, February 3, 2003

separating the UI from code/data and how/where that UI is sorted are two different things.

keeping the UI separate...yes..done Albert says '20 years ago'  (let's leave html out of this for now)

how/where it's stored?  fle system or  db? relational or other db.  the answer....yes, those are all good candidates. Your application may vary.

I think the questionis really, 'assuming that my UI is clearly defined separatley from my data and code, what are the advantages/disadvantages of the various storage options?'

fool for python
Monday, February 3, 2003

oops.....sorted = stored

fool for python
Monday, February 3, 2003


Monday, February 3, 2003

Interesting comments here. We're about to start just such a system. We already do this for reports, we supply an editor for the report and it works well.
We're planning on storing the screen layouts in a database, because that way we get the ability to define shared readonly access with a high level of granularity for security purposes.
Initially we're currently planning on doing form designs in XML with some form of "crude" editor until we've gotten enough UI written to be happy with the data formats. It should remove a large class of bugs we sometimes get (usually related to users hitting a button and validation code in lost focus events not being run) which are often difficult to track down without exact key stroke sequences.
It should allow us to have only bit of code to change rather than multiple cut'n'paste versions of the same bug.

So far reflection in .NET allows us to validate form layouts and self describe simple databound fields. It will probably make the initial design process slightly slower, however we're planning on using interfaces so that "master/child" and "plain record at a time browsing" code becomes trivial to implement.

The whole idea is in response to many users requests for moving stuff around or bigger (or non proportional) fonts etc. It should also allow our end (paranoid) users to hide pricing or other sensitive information from users whose security levels are insufficent.

In part this is also a reaction to one of the guys in our office who works support for us, he's registered blind and has some vision but needs to use a second monitor in "zoom" mode to work. For him I want to be able to give him the ability to define his own forms using bigger fonts for fields etc rather than the out of box stuff we provide at the moment.

Since we're already doing this for reports and for most lists in our system (right click on top to change format or column order etc) where the ability to have the end user change the display is useful selling feature and saves us endless arguments about changing column widths or order to make stuff fit on screen, I don't think the pain from the development point of view is oppressive (Simple text file editing for the programmers to define a field, drag 'n' drop UI for end users). However without a good editor this will not be true and if you have to hand edit a database table then you have my sympathies.

VB4/5/6 is not a good language to try to do this in, only with .NET has it become even feasible as an idea. VBs event model and hidden form definition code make it extremely awkward (Although not impossible as we have done this for small portions of system).

Since we develop for a "near-shrink wrap" market but with customisation for individual sites it makes sense for us. However we will be producing that editor fairly quickly into our development process and using a database to store the UI definition.

The whole thing is flawed if you don't produce that editor, and I suspect that many programming shops won't just to save time. Since we intend for our end users to have this ability we have to (and I have to say the report editors we produced are pretty good) so for us its pain up front while we start out, getting better as we have to do less field munging later on, reflection should also help us keep everything in sync.

Peter Ibbotson
Monday, February 3, 2003

>> "I think the questionis really, 'assuming that my UI is clearly defined separatley from my data and code, what are the advantages/disadvantages of the various storage options?'"

The question being asked here is, 'Why are you storing your own GUI definition when the RAD tool does it for you?' Let the RAD (i.e. VB) development tool do it's job.

I think people are introducing needless complexity in their systems by implementing and storing their own GUI definition along with a GUI Editor/Interface Manager/Report Designer/What have you.

Dave B.
Tuesday, February 4, 2003

*  Recent Topics

*  Fog Creek Home