Cees Hek wrote:
Quoting Tim Howell <[EMAIL PROTECTED]>:
Do any of you ever create applications that present forms to a user
based on information entered by a different level of user? For example,
in an event registration system I'm writing, a user is required to enter
different information when registering for an event depending on the
event specifics. The event specifics aren't known until the event is
entered into the system by an administrative user.
If you don't mind looking at PHP code, the open-realty package at
http://www.open-realty.org/ does something like this. An agent is allowed to
create new form fields for their listings. These custom form fields are then
dynamically rendered when a user is ading a new listing.
The way I've handled this is by including fields named Custom1..CustomX
in the database, and then inserting names in those records if needed.
If the names are found when the sign-up display screen is shown then
that information is required for the sign-up.
I usually use a key/value table which allows for an unlimited number of extra
fields to be entered. The biggest limitation of this is that it makes searching
using SQL much more difficult.
I've done things like this in the past and here is how I solved. I
would have a form type and an element type. The form in one table
and the elements in another with foreign keys pointing to the form
they belonged to. Elements would have these properties/columns (you
could have more or less, but these worked for me..)
* id - unique auto-increment usually
* name - this is supplied by the user, could be anything but i
would translate spaces, etc into '_' for the actual name of the input
* type - like date, paragraph, number, drop down menu, checkbox,
single text line, address, state, email, etc... something easy for
the user to understand which you could then convert
* required ? - just a boolean
* default - whatever the default is
* order - what order they're in...
From this it's pretty easy to generate a form with the elements and
then be able to validate it. Obviously you couldn't do very
complicated validation, but if you give the user enough 'types' then
it should be pretty easy (especially using something like
Data::FormValidator which has some built in validation types).
Then to retrieve the answers you would just need an answer table
which might have the following columns...
* id - unique
* input_element - the id of the input element
* answer - usually has to be a blob to accomodate for the biggest
type of element (paragraph). Blobs are flexible enough to hold
anything although you loose some speed, etc.
Then you can display the answers to the form creator based on their
input element's type.
HTH
This works pretty well, but it is a bit limited. For one thing, it
currently only allows text field inputs to be entered, and no restraints
are placed on what data is considered a valid entry.
I'm thinking of extending this, at least in part by including regexen in
the database to validate input. I'm trying to figure out a good way for
administrative users to be able to edit these, though, as they certainly
aren't familiar with the regexen.
There is always need for compromise when providing the most flexibility while
still keeping the complexity at a minimum. You should easily be able to allow
for size constraints with numbers and strings, and constraints for dates. Also,
limiting the input to a given set of values should be easy enough as well (see
the open-realty package for examples of doing this). However, allowing the user
to enter constraints that are more complex may provide a challenge...
You might/should have built in regexes for different types, but I
agreee that it might be too much to have the user learn regexes.
--
Michael Peters
Developer
Plus Three, LP
--
Michael Peters
Developer
Plus Three, LP
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
