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?
1
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.
2
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.
5
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.
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.
It has advantages and disadvantages.
Advantages:
- Changes in forms go live without waiting for deployment or any downtime.
- Non-programmers can edit the forms using a friendlier UI.
Disadvantages:
- 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.