× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I was hoping to get a little input into this project to support user defined fields because I'm venturing a little into unchartered territory and therefore defining requirements as I go, but that's one thing that makes software development interesting. I hope I'm heading in the right direction. At least nobody replied saying that I was headed in the wrong direction.

I've worked with a number of green-screen applications that had limited support for user defined fields. In some cases the label on the screen was something generic like "User Defined 01, User Defined 02, ...", and the data entry area for each field was a fixed length, and character data type. In other cases, users could assign their own field labels but not change the data type or length.

It seems to me that a browser interface could be a lot more robust; enabling users to assign not only their own field labels, but also the type of input element displayed on the screen (Character, Numeric, Date, Text Area, Checkbox, Lists, Image, etc.), and not be limited to predefined data types and space in physical or display file records. I hope to figure out how to implement it, which may be a bit of a stretch.

Nathan.

On Fri, Mar 14, 2008 at 11:42 AM, Nathan Andelin wrote:

It seems that no matter how well you plan your database, you'll have some users that want to track additional data in user defined fields.

For example, in your employee record you may have fields for first, middle, and last names; but one of your users may want to track an additional set of attributes for some or many employees that weren't included in your initial database design. Perhaps the data is not generally applicable to most users.

So I'm planning on writing a utility to enable the maintenance of data elements that users define themselves, and wondered if list members would be willing to share their input to help me define requirements for the utility.

The user interface will be browser-based. My general idea is to attach a tab to standard maintenance screens to evoke the utility which would display the additional attributes that users may define for any given subject (employees, customers, products, ...).

When the tab is clicked, I envision the utility generating a screen that displays input elements, scrollable text areas, drop-down lists, check boxes, popup selection lists, popup calendars (for date fields), according to the data types and other parameters pertaining to each field.

I've begun defining table to store user defined field definitions and have so far come up with the following layout:

Subject ID (employee, customer, product, and so forth) (a key)
Sequence Number (to enable the user to order the fields when displayed on the screen) (a key)
Attribute ID (each attribute would have a unique ID within the subject) (a key)
Field Label (the field label displayed on the maintenance screen)
Data Type (character, number, date, boolean, stream file, etc.)
Data Length
Number of Decimal Positions (for numeric data types)

I may also need to define a few basic data validation stuff:

Required Flag (must be filled in Y/N)
From Range (numeric data values)
To Range (numeric data values)

Formatting:

Uppercase Flag (Y/N)
Output Edit Mask (###-##-####, for example)
Input Edit Mask ((###) ###-####, for example)

Lists:

Popup List ID (refers to a popup definition - a separate definition)
Dropdown List ID (refers to a dropdown list ID - a separate definition)

Any other thoughts? If there's interest, I could provide a hyperlink after I've completed the utility.

Thanks,

Nathan.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.