Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I'm sure you've seen it. The database has a bunch of tables called Forms, Controls,FormsControls, ControlSets, Actions and the program that queries these tables has a dynamically generated user interface. It will read all the forms, load a home page that has links to them all, or embed them in some tabbed or paged home page, and for each of those forms it will read the various text boxes, check boxes, radio buttons, submit buttons, combo boxes, labels and whatnot from the controls and form-to-control join tables, lay those elements out according to the database and link all the controls to logic according to other rules in the database.

To me, this is an anti-pattern. It actually make the application more difficult to maintain because the design of it is now spread out into multiple different systems. Also, the database is not source controlled. Sure, it may make one or two changes go more quickly, after you've analyzed the program anyway to understand how to change the data and as long as you don't stray from the sort of changes that were anticipated and accounted for, but that's often just not sustainable.

What say you?

share|improve this question
If you're talking of having a visual design tool to create UIs, than that's definitely a good idea. Whether it persists the designs in a DB or spits out code matters little (and is in fact an implementation detail). But people entering this into tables directly sounds to me like a special case of the inner-platform effect. –  back2dos Oct 19 '12 at 0:14

3 Answers 3

It is definitely not an anti-pattern: when this is done correctly, it lets you complete very complex applications in very short time. I worked for a company that built all its products that way, and it was very successful at what it did*.

The only problem with this approach is that it is extremely difficult to get right. For example, it took a team of some fifty highly skilled programmers, mostly from MIT and Caltech, about three years to build the platform. Once built, however, the platform delivered handsomely: we were able to put complex applications in production in a matter of months.

The biggest benefit behind this approach is that it lets business analysts with very little programming knowledge build reasonably complex applications. Programming such systems is often only slightly more complex than programming Excel, so people with knowledge of the domain could be trained at making the forms, their backing storage, and the business rules controlling the data flow.

* The company collapsed because of failures in its business model.

share|improve this answer
To me it seems like this is the definition of an Anti-Pattern. It's something that's hard to do right and for the right reasons and shouldn't be a commonly applied pattern –  Segfault Oct 19 '12 at 0:22
@Segfault Not all patterns are created equal. This particular one is very similar to creating a powerful domain-specific language. In a very broad sense, it is a domain-specific language, whose domain is form-based applications. The only caveat is, this language has no syntax. Creating domain-specific languages for complex domains is hard, but it is not an anti-pattern. One has to think twice before trying it, though: if you are building one project, building a language for it is an overkill; if you are attempting ten similar projects, a DSL is a great thing, if you can pull it off. –  dasblinkenlight Oct 19 '12 at 1:50
How would one architect such a system and keep separation of concerns in mind? There's been such a push in the past several years to distinctly separate data from presentation, that from that perspective, this would seem an "anti-pattern" but I also know from experience (we built something similar inside a corporate intranet that lasted for years, and was highly favored over corp-IT "solutions") that there is a place for such systems. I'm just curious what the best way to do something like this would be, keeping in the separation of data and view? –  Jason M. Batchelor Oct 19 '12 at 13:38
@mori57 "this would seem an "anti-pattern" from the perspective of separating data from presentation" Absolutely not: the data describing the forms, AKA "metadata", is placed in a different database, in a separate read-only instance, often on a separate physical box. –  dasblinkenlight Oct 19 '12 at 13:44
Ah, ok, thanks for the explanation. That makes a lot of sense, considering how we had our form-builder system set up, too. (It's been a few years since I worked on it.) –  Jason M. Batchelor Oct 19 '12 at 13:53

I think every time I've tried to do something like this I've ended up scrapping the system and starting over. For me it was creating a tree in a db and having a type field. That type field mapped to various models. I mean yes, technically relational db type stuff is like defining a customized tree, but querying one giant table ends up causing performance issues. Commonly there are exceptions to various rules which end up causing your db schema to be non-acid compliant or just ugly as well. It is much easier to plainly define your architecture using tangible model names. Moral of the story: don't over generalize a problem.

That being said there is another paradigm that states your code is data. In that thought process one might say that saving your applications in a DB does make sense... I suppose...

Doing revs aren't easy, but I suppose it is no different than how systems like wordpress or drupal do revs on their documents.

As @dasblinkenlight said this sounds hard. I'd say it is overly complicated. Sometimes you do need to provide a mechanism for admins to create forms. In those cases you might better off just saving the entire HTML of the form itself. Then saving the filled in form data separately and let admins sift through it however they please.

share|improve this answer

It's not an anti-pattern in general. It's no different from how programming languages, browsers and report generators work.

Can a particular implementation of this method be or become an anti-pattern? Yes, just like any other program. As always, the devil is in the details. Also, as others have noted, complexity is perhaps the biggest challenge when creating this kind of program.

I've written several programs like this, mostly report generators and content presentation systems, and I've tried to keep them as simple as possible. I try to use kind of a "fast food" method to provide mass customization. The idea is to limit user choices to a set number of base items and the way to put them together while allowing the user to have limited control over certain elements.

Where the over-complexity comes in, it's usually a result of programmer "gold plating" and/or excessive user demands. In some cases, it's better to use an off-the-shelf power user oriented product (like SSRS, Access or Hyperion Reporting suite) than trying to reinvent the wheel.

share|improve this answer
"no different from how programming languages, browsers and report generators work" -> I agree, which makes me wonder, why don't we use a programming language, browser, or report generator? Is this custom DSL or meta-form (a form for making forms) really that much easier than HTML markup? –  Segfault Oct 20 '12 at 1:09
@Segfault - The reason to create a custom system was to handle specialized needs of a business. For example, one such system I wrote was to handle the aggregation of medical reports in a way that would please picky doctors/customers. It allowed the staff to construct these without having to involve IT. However, in another case, a client wanted an HTML generator written for them. The ultimate/best solution was to teach them how to use a few simple CSS and HTML templates with a WYSIWYG web page editor. –  jfrankcarr Oct 20 '12 at 14:42

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.