: Big specialized complex forms for ordering/signing up I sometimes get the offer to create these and it's always a maintenance hell. For example: a print shop wants a form so you can order

@Sims2060225

Generating forms dynamically is pretty easy. The harder part is designing a back-end that accommodates dynamic form data. But that too shouldn't be too difficult.

The most common approach is to use an EAV model (Entity-Attribute-Value), also known as an open schema model. This is a generalized form of row modeling, which is recording facts about something across multiple rows instead of multiple columns.

So instead of having a table called Orders with fields like size, paper, color, etc. and having to modify the table schema or create a new table in order to create a new custom form, you would simply have 3 tables (Entity, Attribute, Value) in which all form data can be stored, no matter what the form looks like. In this case, each order would be a new entity, each form field would be an attribute, and of course the selected options would be the values.

This might look a little confusing at first, but once you start to implement the system everything will start to fall in place. Usually this is done in the database abstraction layer or ORM. See Magento for an example of this in action, which uses EAV to allow custom product attributes to be defined by the user.

It should be noted that many (e.g. Bill Karwin—former project manager for Zend Framework) consider EAV to be an antipattern, but I can think of no better alternatives to EAV for these cases, so the benefits outweigh the costs IMO.

Vote Up Vote Down