Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

closed as primarily opinion-based by MichaelT, durron597, Snowman, Blrfl, GlenH7 Sep 2 '15 at 17:34

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the 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

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

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

I consider the dynamically creation of forms a anti-pattern for tailor-made softwares, but for COTS or package softwares that user can't decide about the behavior or appearance, could be a good choice. Although it's important to consider the rigidity brought by dynamic forms.

The reason is that for tailor-made sw a simple change request for a form could become a nightmare.

share|improve this answer

It has advantages and disadvantages.


  • Changes in forms go live without waiting for deployment or any downtime.
  • Non-programmers can edit the forms using a friendlier UI.


  • It's easier to break the forms and / or make them incompatible with the backend code.
  • It requires special custom tools to maintain (though these tools are the whole point).
  • It may be harder to see the system as a whole (depends on your tools).
  • It's hard to create a really flexible form editor.
  • A really flexible form editor becomes as hard to use as code-based editors, or harder.

So I see a few niches where this approach should do well:

  • When users need to edit forms, but significant constraints are in place (so flexibility is limited, and it's harder to break stuff);
  • During rapid prototyping, esp. by non-technical users;
  • When quick dynamic changes to the forms are very important (can't easily invent a case for that, but it may exist).

Everywhere else, I'd take a different approach.

share|improve this answer

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