A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
In many web applications, we usually need (or at least wonder if we could have) custom input fields. In case of an open-source web application, it's possible to hack around and code the required stuff yourself (although most of them, especially PHP code is badly organized).
In case of a hosted web application, things start getting a bit trickier. What if you wanted to allow your users to provide input through a certain form but also allow them to specify what input they would like to provide? For example, if the users want to keep track of their customers. For some, it might only be the full name and email address of each customer. For some, it might also include postal address, telephone, etc. For some, it might contain any other information they might want to keep track of (demographics, etc.).
So, in simple terms. Each user of the hosted web application starts with a base-form. Then each user start adding fields of his own (with appropriate validation logic, etc.).
There can be two (or more) half-baked solutions:
1. Provide a set of "stock" fields
2. Create separate tables for each user
1. is a bit akward, it can work for some but not in this scenario. You never know what and how many fields the user might end up using.
2. can be even harder to manage. What if you want to add something to the base-form? What if you want to analyze data for ALL the users?
Is there any better way to do so? What about exploring an ORDBMS like PostgreSQL? I think PostgreSQL has some sort of table-inheritence. Is there any better way to store data in a relation database?
I want the user to customize the form, before entering data. So each form will have:
a) a base set of pre-defined fields
b) optional sets of pre-defined fields (which may be turned on or off)
c) custom fields
The web application would do analysis on (a) and in some cases (b) and would display (c) only for the users' records.
Zope with its 'acquiring' structure is perfect for this kind of thing.
Create a Product with your base properties and give the User some kind of admin interface which lets them add properties as they wish.
Add some DTML or ZPT for the properties form that lets walk through all of the properties and present them in whichever format makes sense for the type of property.
I'm just finishing off a Product for a Client that does this.
If you want some fields to be queriable (searched on) then you will have to put those fields in the table. These would the stock fields that all users have. Some of them could be optional or hidden.
Then, in your data table, provide a single large text field. This will hold all the custom user field data. You just serialize the custom user data into and out of this table field.
You'll also need a table to store the layout of your user's customization. This is relatively simple. You generate your form page from this information.
For validation, I'd provide a series of stock field types: just text, phone number, email address, website, text area, etc as well as required or optional. Then validate the input data based on rules for those field types.
I do something like this on a grand scale for one of my applications.
I'll grant you the undocumentedness of Zope, I almost feel a book coming on. It can be run on a hosted server, one that gives you a virtual root.
Oh this is entirely what Plone is about, btw.
I'm not sure if I get you right.
If you want the user to choose from a set of predefined fields, AA is right. Put them all into the table and store the information about which user uses which fields somwehere else.
If you want the user to define arbitrary new fields, however, you need an appropriate logic behind. We did this once and called it "Custom Properties".
A custom property consists of a name, a description, a value type (an enum, e.g., indicating if this is string, int, float, date...) and a value (a string in database). You should provide formatting and conversion functions for each value type to and from string. This can be done by subclassing for each value type. You may even extend the concept by adding validation, for example min or max values.
Instances of custom properties then can be linked to whereever they are needed.
The UI code reads the linked properties and generates the according HTML input widgets.
Note that searching becomes much more difficult, because you need to take the linked custom properties into consideration. Better be a SQL junky ;-).
If you use scripting languages like PHP another approach can be to modify both source files and tables at runtime. This may be suitable, if there are modifications done on customer level/per installation. I don't have any experience with this, however.
Friday, November 19, 2004
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz