We have about 10 applications that basically do the same thing, all written using the Wizard Control for .Net 2.0. The flow they follow is pretty simple:
1. User selects option from a drop downs.
2. Next page has more options more narrowed.
3. User sees confirmation page.
4. Report is generated.
Some of these applications have optional pages, such as allowing the user to upload custom images for the report and allowing the user to select specific lines of data.
I'm attempting to merge these applications, but I'm not sure I'm approaching this the correct way. My first inclination is to create configuration tables in SQL to drive the menus that appear. So, for example, there might be a table with the WizardId, Name, Theme, etc., also a table of steps, and another table to link everything together.
Is there an easier way to approach this that I'm just missing?
We've been thinking through this issue lately and I've come up with two options that both seem valid, just have different uses. One way to do it, similar to what you have described, is to create the following:
A table that holds the wizard information
A table that lists the types of questions to be asked in each wizard
A table to hold the data entered by the user for each question
This is very flexible, but the problem is you have to dynamically generate all the controls you need to collect the information (textbox, drop down, radio, file upload, etc) and store how to display that control in your database.
The other approach that we have tried out on a recent project is to associate a user control with either each wizard or type of wizard step. It isn't as modular, but you have a lot of control over how the controls are arranged and how you collect the data.
I think both approaches are useful in different scenarios. Going with a database driven approach allows you to generate new questions and wizards easily, but lacks the user friendly approach that we wanted for our new application.
Related
Lets say you are developing an web app that requires that you are able to Add/Edit items. The item form contains several input control. Would you separate the add/edit pages or use the page for add/edit and control via querystring (i.e. ItemAddEdit.aspx?isEdit=1)
The advantage I see in separating is that it is easier for the (non-technical) user to type the page and to determine whether it is add or edit. Also, when there would be specific changes to each page (if ever), it would be easier to change.
For the single page, well, you reuse code which eliminates some duplicate code and avoid possible problems.
And no, I can't use routing.
This is generally something which could be a subjective thing, because there's as many ways of doing things as there are coders, and a lot of it can be depending on how your system is set up generally.
But, if I were to recommend, I'd say the way you should do it if working with asp.net web-forms is to make two web pages (add/ edit) and then you use a user-control on those to group up the shared logic between the two pages. After all - that's why we have user controls.
In this way you can have both of your situations, by keeping logic in one file/class, but still have two entry points.
This would also mirror more how MVC does it, which could be considered a plus.
That being said - if your administration functionality is behind login etc, there's nothing to hinder for actually doing it in one and separate with the query string approach, and then just load the data if editing or display "empty"/base data when creating.
You shouldn't have the user type the addresses anyway, but click through the links to follow your flow, so the query string should be a minimal issue.
But for the sake of keeping your functionality clean and divided, I'd personally recommend going for two page / usercontrol approach.
I am trying to figure out if it is possible to create ASP.Net web pages dynamically. Here is my scenario: I am dynamically creating a huge amount of controls to track data entry that are split up into sections. These sections will play off one another in the sense that if I say I have 5 sections it will create subsections each with the same number of controls and options but divided into groups. This is for tracking the law so it needs to be diverse, dynamic and it obviously has alot of options as the law does. How might one handle something where you have a ton of controls on a page but you want to easily walk the user through the data entry process without confusing them? Our thoughts at this point are as you create the subsections it creates a dynamic webpage that has the subsection controls within it. Or do we need to look to alternative methods - We also thought about hiding the section information doing a display: none with the CSS for each section as you go through the data entry process hiding the controls you are no longer using. how is this possible using ASP.Net with VB? Thanks!
If i understand you want to use client language to manage your controls. May be it's easier to create controls in post back function using vb with viewstate enabled.
In visual Web devlepoer I have my database connection in my project if My project database has several tables that I want users to entered data to into my webform and be submitted to my database is there an easy way to replicate my tables fields in a form. Like gridview for input.
I can manually sit here and create tables and add textboxes etc in html but seems a little redundant when the tables are already visible in the database explorer.
Want to be sure I am not taking the long version of an easy process. There are plenty of easy forms and tables for viewing database data but what about for submitting it?
The back-end is completely Separate from the UI. At a later date it might be decided to group the fields in a different order, etc. Using a GridView only adds unnecessary overhead.
From a UI design perspective, you should not have too many form fields on a single page as the user is less likely to complete the form - basic usability issue. If this is the case, try splitting up the fields using a Wizard control and perhaps keep the user informed of their progress ( page 2 of 5, etc.).
Well, I am trying to implement a wizard interface to help the user to choose the right service then add it to the shopping cart then possible checkout or discard.
This is similar to the concept of the t-mobile / att. Where we select the type of plan then the services we want ( minutes , data plan, mobile phone device then checkout) . The UI should be very web 2.0 like there would be help text , suggestions.. etc.
The technology is asp.net 4.0 (mvp - codebehind model)
I did a lot of research, looked around using state design pattern , commander pattern.
My thinking is like a pattern where we have a Wizard controller which controls the wizard steps then once done hands over to the checkout process the end user can always go back and change any options during the wizard. Incase if its a existing customer then we have to skip few steps as we already few details.
Its all custom UI, I was thinking to use asp.net mutliview and each view loads based on current and next step.
In Brief I am confused and need some directions
Be aware that the multiview actually loads all details behind the scenes, one reason I don't like using it.
You could easily just have several ajax update panels. Each is the step of the wizard and when you post each item, you hide that panel and show the next step and potentially update and step indicator you have on your screen.
You have several choices -
1. jQuery and ajax calls to load details into divs
2. update panels (as described above - my choice here)
3. wizard and multiviews - Im not a fan of using them. Certain customization issues exist with these built in controls at times and you need to be wary of certain details - like multiview actually processing all data for hidden items (if they contain queries this could significantly impact your system when you don't expect them to run and they do even though the view is hidden)
I am working with an ASP.Net web app that allows users to create an "application."
They define fields and their data types. Based on that, I generate a query to create a table.
I would like to use the metadata from the table to generate an input form to display to users.
Is this a good approach?
Has anybody done a similar project
that can share some lessons learned?
How about creating and altering
tables at runtime?
Does anybody see any problems with
that?
You will need to accomadate for all userdefined field types (text, number lookup, dropdowns, check boxes, dates, etc).
These will have to be save to the database per field type per user per forms.
Further you will have to allow the user to define their own layout. this will mean that you have to same the entire form layout, per user per form per control.
There are some apps available, that applies this logic, (I think SharePoint has this type of approach).
I have done this once before, but it was using WinForms, using XtraLayoutControl , DevExpress Layout Controls.
This did allow me to save the layout, but did not create the controls for me automatically. I still had to implement that my self.
If you have any specific questions, regarding db table layout, client integration, or performance of these queries, Please feel free to ask.