[2005] Design Question

[maikeru-sama]

I haven't posted in the forum in a while and it is always good to be back .

Background - We have an RPG Program on AS400 that accepts user input and inserts data into a DB2 table.

I have been asked to move this functionality to the Web using ASP.net.

Here is the short and sweet version of the specs. We have about 80 departments that fill out paper forms called Cash Report Forms stating the revenue that they took in. They then turn this form into a person in my department and this person enters all of that data into a Green Screen and after this person is finished, hits a button and this data is inserted into a DB2 Table (JD Edwards Table).

The issue that I have is that alot of the 80 Departments use very unique Cash Report Forms. Once I get a print out of all the forms, I am hoping that I can condense them down to maybe 5-10 unique Cash Report Forms. However, 5-10 unique Forms are still alot and this type of project seems ideal for Dynamic ASP.Net.

Dynamic ASP.Net gets pretty nasty and I just wanted to make sure that there isn't any other way of doing something like this. I thought about a DatagridView but the forms are just too different to go that route.

[maikeru-sama]

Im going to go the route of the web page below. On the second page, in the very last paragraph, it describes my situation to a tee.

http://aspnet.4guysfromrolla.com/articles/081402-1.aspx

[rjv_rnjn]

I would disagree on the approach. The reason is the cost of code maintainability. But it also depends on the number of controls that you have on the form and their types. The possibility explained there in the example is a simplistic "text literal" with question, "radio buttons" with options and a possible list of values. But if your form is a bit complex and is to contain a variety of controls (textboxes, dropdowns, labels) arranged at different places in the form, the HTML markup code you put in to accomplish proper indentation would be a bit too much.

[brin351]

The core reason to have dynamically generated forms for data input is the forms 'change frequently' and or a Manager (not tech) need to add remove controlls as in a CMS.

If you have 10 forms that rarely change I'd suggest make them static.

Are you thinking of using a database table to hold form details... like
shop - control - text - validation....

[maikeru-sama]

The core reason to have dynamically generated forms for data input is the forms 'change frequently' and or a Manager (not tech) need to add remove controlls as in a CMS.

If you have 10 forms that rarely change I'd suggest make them static.

Are you thinking of using a database table to hold form details... like
shop - control - text - validation....

I actually finalized the design today at work.

Without going into too much detail, I work for a City. We have quite a few departments within the city (alot more than ten) and each department has unique "Cash Revenue Forms" that they submit to my department and that data is entered via green screen.

The Cash Revenue Forms don't change all the time but change enough to where it would be best to make it Database Driven. Also, the person that enters all the data into greens screen will be the administrator of the new application and she will add new screens, accounts on those screens and all other administration duties.

Furthermore, the controls are limted. You will have 1 Label (Account Name), 1 Textbox (enter monetary value) and an optional Textbox (Quantity of item). Now there are some other controls, but those are universal to most of the forms and whether or not those show up, similar to the optional textbox mentioned above, will be based on a flag in the Database.

I have done dynamic ASP.net before at my previous job but it was nowhere near as complex as this current project.

I will list a brief overview of my design in the next post.

[maikeru-sama]

Here is a brief overview of my design. There are other tables, but I am only listing the more relevant ones.

Note: The word Screen and Department are the same thing.

Hardcoded Tables:
Department - Each department will have 1 record in this table. It will have a UserID as well because each user will be associated with 1 Department. Also, this table will have several flags that will be used to determine whether certain things are shown or not. This table more or less is an overview of the entire screen.

Accounts - Each department has 1 or more accounts that appear on a screen and the user will enter monetary values for some or all of the accounts. Each account will be associated with a DepartmentID. The actual accounts and their descriptions will be stored here, not the data the user enters. More importantly, this is the table that will be queried when the user needs to add new Revenue to the System (Add Mode). New accounts will be added to this table at the user's discretion.


User Tables:
AccountReceipts - This table will actually hold all the data the user entered. It will have the accounts, the monetary value, totals etc etc. When the user needs to modify data, this table will be pulled not the Accounts table (Modify Mode).

I had to design this to where you could add, delete and modify new accounts to a screen. Also, the administrator needed the ability to add entirely new departments. I was told there are about 80 different screens and based on the ones I have seen, I have gotten it down to 2 Templates or ASP.Net Pages. One template/page will build regular and more common screens. The 2nd one will build a Miscellaneous screen the users use. I didn't want them on 1 ASP.Net page to cutdown on complexity.

I have already written all of the necessary queries and they are very straight forward and have been tested on mock data.

Now I have to figure out if I am going to use a datagrid or use a PlaceHolder with a table inside of it and put individual controls on the table dynamically. If I go with the later, I imagine I will use 1 Sub Procedure to add controls to the table and call this same Sub Procedure each time I need to add a new row, if that makes sense. Now, getting the values of the controls from that table may be a little more tricky, so I will have to weigh my options.

I have some Javascript questions, but I am going to do more research before bothering you all with those questions.