3

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?

2 Answers 2

4

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.

1

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.

3
  • You mean I'd build these structure in the controller and then iterate through it to render it out? That's similar to what we've been doing in the first project I mentioned, but invariably the set of widgets we've built do not cover all the use-cases. We keep having to add more and more and it gets unwieldy, which is why I'm not fond of this approach. I'd like to 'design' it mostly in the template so I can get a nice layout going and not be confined to a rigid structure.
    – mpen
    Mar 12, 2014 at 1:02
  • No, I mean you have to build a data structure that is capable of holding your form design. Basically Adam Zuckermans third option (although I'm not sure it would require a EAV data store).
    – jmoreno
    Mar 12, 2014 at 6:38
  • I'm not sure I follow. Are you stuffing bits of HTML into your data structure, or just the attributes needed to render it?
    – mpen
    Mar 12, 2014 at 6:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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