Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Help with HTML code generation 1

Status
Not open for further replies.

ByNary010101

Programmer
Joined
Nov 22, 2004
Messages
16
Location
US
I am building a customizable Work Order screen for a local company. They want to have the ability to create a new Work Order type (i.e. Desktop Install, Laptop Install, Printer Install, etc.) and then they want to define the criteria that the form should display when a Manager or a Technician goes to fill out a new Work Order of this type. For Example:

Page will display: "New Work Order Name:" user will input, for example, "Desktop Install"

Below this there will be:
"Criteria:" user will input the Criteria description, for example, "Multi User Id"

Next to this will be a drop down list populated with different HTML tags asking how the input should be collected from the user "Input Type: Text, Dropdown, Multiline Text"

If the user selects Input Type of Dropdown, he/she is presented with a way for him/her to enter in all the options that should be inlcuded in the dropdown for this criteria (ex. Yes, No, Maybe)

After the user inputs all his/her criteria he/she clicks an "Add Item" button and it adds this info to something (not sure yet what I want to add it to) and then can proceed to enter all other criteria requirements for the Install Type.


I need advice on how I should store the HTML tags and attributes in the Database. I have been toying with doing something like this in my Field table:

Field_Id: 1
Field_Desc: IP Address
Field_Html: <input type="text" name="IPAddress" id="IPAddress" />

What would be the best way to store a Select tag (dropdown) with all of its options with a way that would allow the Work Order creator to go back and add, remove, and edit the options?? I hope this makes sense. Thanks.
 
I suggest that you do not store HTML in the database, but rather just the information about the form. That way you'll have lots of flexibility in writing it out (imagine, for instance, that you later wanted to add style sheets to the output: hard to do if you have HTML in the database). Plus it will make it very hard to edit later.

My first thoughts are a database something like this:
Code:
[b]Form[/b]
-------------------------
FormID                    'Primary Key
Name                      'Ex: Desktop Install

[b]FormField[/b]
-------------------------
FieldID                   'Primary Key
FormID                    'Foreign Key, pointing to [b]Form[/b]
FieldOrder                'Number to indicate order on the form
Type                      'Numeric, 1=Text, 2=Select, etc.
Name                      'Ex: IPAddress
Description               'Ex: IP Address
Size1                     'One size dimension (see below)
Size2                     'Second size dimension (see below)
Status                    'Boolean (true/false) (see below)

[b]Option[/b]
-------------------------
OptionID                  'Primary Key
FieldID                   'Foreign Key, point to [b]FormField[/b]
OptionOrder               'Numeric, order to display options
Name                      'Visible name of the option
Value                     'Value of the option
Default                   'Boolean (see below)
This isn't perfectly normalized, but it should work.

Obviously Form is data about each form. Add more fields (like creator, date, etc.) as needed.

FormField has one row for every form field in a form. The FormID points back to the Form table. FieldOrder would be used to indicate the order of the fields on the form. Type is the type of field, be it text, select, textarea, radio, etc. Name is the name of the field on the form (in the tag, not visible to the user). Description is the visible text for the user. Size1 and Size2 are size dimensions. For a text field they'd be for size (width) and maximum size. For a textarea they'd be width and height. Status is a true/false flag that serves two purposes: for selects, if true then the user should be able to select multiple options, and if false, no; for checkboxes, if true then it should be checked by default, if false then not. One possible additional field would be Mandatory, a true/false field to indicate that data entry is mandatory for this field (for checking after submission)

Option is for options of various types. FieldID points back to a field in the table. If the field was a Select then there'd be one row for each item that can be selected, and if it's radio buttons then there's one row for each radio option. OptionOrder is a numeric field that indicates the order to display the options in. Name is the visible name of the choice, and Value is the invisible associated value. Default is a true/false flag: true if the option (in a select) should be selected by default, or true if this is the default radio button.

Something like that would give you a pretty flexible database that could hold all kinds of forms. And again, this is just off the top of my head, but should give you a starting point.
 
Wow, I think I wrote a whole bunch of stuff for nothing. I hate that when it happens.
 
I gave you a star for effort Genimuse ;)

www.sitesd.com
ASP WEB DEVELOPMENT
 
LOL, thanks. :-D I just hope it's of assistance to the OP.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top