How to build configurable forms?

Question

I'm working on two separate projects now that are essentially just CMSs -- a bunch of forms for recording various bits of information. Each project is built to serve many clients, and each client seems to want to record slightly different information.

In one project we've handled this either by copying and pasting all the logic surrounding that form for each client so that we could make the changes without affecting the other clients, or we build a master form containing all possible inputs and then programmatically remove the inputs that the client doesn't want (our framework allows us to remove inputs (essentially from the 'controller') before the final template rendering). Neither solution is really clean and causes the forms to be riddled with "if" conditions based on which client we're serving.

The other project I'm just starting, and I don't want to run into the same pitfalls again, but I'm having trouble coming up with a good way to solve this problem.

I could list out all the input IDs for each form element in the database and then create a mapping between them and the clients, and then in my form template wrap each widget rendering with a check to see if the input is enabled for the current client. On the backend -- when the form is submitted -- I could save only the data that is submitted and forgo the conditionals for the most part. This creates a dependency on the IDs used in the template must match those recorded in the DB -- I don't want to create the entire form programatically as that wouldn't give me enough customizability. That's the best I can come up with.

Has anyone dealt with this sort of problem before? How did you approach it? What worked, what didn't?

---

For comparison, you might consider sites like Freshbooks, or Trello, or a bug tracker, or Facebook -- if any of those apps let each user customize his or her page to add or remove inputs so that they could record only the stuff they care about -- how would they manage this complexity from an architectural point of view?

Answer 1

There are several different approaches you can take to solve this.

Have static form pages for each client

This is the easiest to build. You can define pages and fields that are unique to the client. Each page can have the client's unique look. Common code will be a little bit more difficult as things like event handlers for different fields will have to be replicated on all of the appropriate pages. You can minimize some of this by using a client framework.

Have a series of fields on each page that determines which field is shown based on the client

This sounds like what you have now. One page to rule them all. And a huge mess if the logic or application flow changes between clients. Common code won't have to be replicated as all of the code will be common to the page that it is on. You can use a client framework to help with the page production, but then you introduce the frameworks limitations on top of your monolithic page.

Build a system that allows for configurable questions based on any criteria you desire

This would be the most difficult to build. You still have one page to rule them all, but from the server you would determine what fields need to be placed on the page. A lot of logic on the page will be simplified, almost to the same point as the static form option above. Common code would be heavily used, but more from the building of the page rather than on it. You would have the option of building page completely on the server, essentially serving a single page to user based on your client's options. You could use a client framework to dress up the browser with a more responsive application page. This system may also require using the dreaded EAV style of data storage, not that there's anything wrong with this technique. There are some caveats associated with getting data from an EAV data store.

Answer 2

You need a structure to contain what inputs they want and how they go on the page. No "if" blocks or conditionals -- it needs to be set based, you have this list of elements, this is where they go, this is what they mean, this the validation for a particular element...

This shouldn't prevent you from customizing, it should in fact make it very flexible, but it will be a bit complex to work out.