views:

283

answers:

2

I am just starting on a complex data entry form and thought I'd ask for input from anyone that may have gone down a similar road before.

The form is going to represent a cost estimate (plus additional information) for a project consisting of multiple tasks. All TaskTypes are pre-defined in metadata for a ProjectType, and can consist of various different input options depending on the TaskType, which will then drive how the user interface renders for the grid of tasks for the ProjectType instance.

For example:

Task Type xxxxxxx Input Options:

TaskName       DataType   InputType   LowLimit   HighLimit    Options
TaskType1      Number     TextBox        100        1000
TaskType2      Number     DropdownList                        1;2;3;4;5      
TaskType3      Memo       Textbox 
TaskType4      Text       DropdownList                        Jan;Feb;Mar;Apr;May

This is basically just a few examples...I will have to support basically any sort of input type possible on a form, render it appropriately, and then save it back to the database when editing is complete.

I will be doing this in webforms as I have not touched MVC yet.

I will need to have all task displayed in a table/grid and all simultaneously editable (ie: no putting a GridView row into edit mode then updating). I suspect this may be a bit much to expect of the standard Microsoft GridView, especially being able to edit all rows at once, but if anyone has come up with a clever way to pull this off before let me know. I'd be happy to pay for a 3rd party control, so if anyone has any suggestions on ones that support simultaneous multi-row editing nicely, let me know. Or, is there some sort of jQuery based solution that would be the best way to handle this?

Another question is, how should one store this in a database? Should I just store each datatype in a varchar(max) Value column, should I have a NumericValue, TextValue, VarCharValue column, and then use the appropriate one? Or is there an entirely different approach that would be more appropriate?

UPDATE

This webform is going to be quite big, the user will be editing 30+ tasks per project, each will be a row in the grid, with proper input control(s) appropriate for the data type, ie: textbox,calendar, textarea, dropdown, etc. HOW TO DO THE UI IS MY BIGGEST QUESTION.
The kind kind of reporting that will be done will be a high variety, so storage should make this as easy as possible.

A: 

Have you checked out Asp.Net dynmaic data?

J.W.
A: 

You haven't said how you're going to use the data, so it's pretty hard to recommend how to store it. You'll of course need to store the data based on what you plan to do with it later. The less you plan to do with it, the less complicated your database will need to be.

John Saunders
Are you implying I have to explain for you specifically how I'm going to consume the data? How about you use your head? From the description, can you honestly not making a reasonable assumption?
tbone
How about I came up with about five reasonable assumptions, any of which could have been what you had in mind? How about you mention cost estimates, then give an example of a general purpose survey form, not associated with cost or any factor related to cost? How about you say reporting, but don't say by whom or how? Ad-hoc by end-users? Canned reports? Degree of user interaction?
John Saunders
@-3 = explanation, please. It's not about revenge, but about improvement. Can't improve if I don't know why.
John Saunders
Re explanation - I'm just browsing (you've collected a few "offensive" votes...), but since you ask - this post does come off as quite... abrasive (to put it mildly).
Marc Gravell
@Marc: quite true. I wondered at 3 all at once, with the given timing, and not even 1/3 comments. Point's across at any rate, so will edit a bit now.
John Saunders
I honestly still can't imagine how you could so seriously misinterpret the question, without purposely trying to do so. The UI question is the meat of my argument though, and if you had something interesting to say about that I'd gladly remove my downvote.
tbone
@tbone: I know that the main part of the question was about the UI. I didn't have anything to contribute on that. But you also wanted to know about the database, without havinve provided enough information. I was certainly a lot more sarcastic than I needed to be, but the fact remains: you may feel that the data storage choices are apparent, but I can only think that means you've decided you have to store everything as key/value. More information about the query and reporting patterns in a separate question, might get you a better solution.
John Saunders
Ya....I'm now thinking of building proper sub-tables per project type, then decorate them with metadata for the UI....more work but more flexible. Thanks, downvote removed. :)
tbone