It’s the New Year already.

It’s the New Year already. Just don’t know where the last one went. I had great intentions with regards to this blog. Like writing entries every day. Each was to witty and on point about various development issues. Didn’t start to bad, just never stuck with it…. just too many other things got in the way. In keeping with the traditions of a new year, one of my resolutions is do a better job of regular and meaningful blog entries.

I am currently involved in a rework of a eForms system. This is a web-based application. It provides means to complete and submit various company forms. The current system is a mixture of ASP and .NET. It works most of the time but changes are a nightmare. Seems like the current system is actually nothing more then a wrapper for some very convoluted ASP. The eForms system simply presents a form, which a user completes. Upon submission the form data is inserted into a database and an email with a link to the form is sent to the users supervisor. The form initiator is responsible for entering the supervisors email address. When approved by the supervisor, the record is updated in the data base and copies sent to the appropriate individuals for notification and action.

One set of eForms deals with system security. It requires multiple forms per individual to get needed system access for given position. For example a help desk position requires 5 different forms to secure the necessary job permissions. Redundant data is required on each form and results in multiple emails to the same individual for review and approval’

eForms is a relatively simple application. However, it needs to be architected such that changes can be implemented quickly and with little effort. Ultimately, organizational elements responsible for the form should have the ability, through admin screens, to alter the forms themselves. To this end, we have devised a system where form elements are automatically detected and passed to a stored procedure. The stored procedure determines decides if the request is an update or insert. Changes simply become a matter of adding a new object to the form and corresponding field to an associated database table.

The new eForms architecture consists of one class, which encapsulates all the work needed to assemble page data into an argument string. One stored procedure that determines if the calling arguments constitute an insert or update, and performs the indicated action. Many .aspx files, one for each eForm, and a common .cs code behind page. This architecture does place some constraints on the coder. First each form must have its own database table. Second, The form ID must be its database table name. Third, the form object ID’s must correspond to the associated table column name. Fourth, the form objects are limited to asp: components. CheckBoxList and RadioButtonList components are not allowed.