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)
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
We have an ASP.NET web-application which has become difficult to maintain, and I'm looking for ideas on how to redesign it. It's an employee administration system which can be highly customized for each of our customers. Let me explain how it works now:
On the default page we have a menu where a user can select a task, such as Create Employee or View Timesheet. I'll use Create Employee as an example.
When a user selects Create Employee from the menu, an ASPX page is loaded which contains a dynamically loaded usercontrol for the selected menuitem, e.g. for Create Employee this would be AddEmployee.ascx
If the user clicks Save on the control, it navigates to the default page.
Some menuitems involve multiple steps, so if the user clicks Next on a multi-step flow then it will navigate to the next page in the flow, and so on until it reaches the final step, where clicking Save navigates to the default page.
Some customers may require an extra step in the Create Employee flow (e.g. SecurityClearance.ascx) but others may not.
Different customers may use the same ASCX usercontrol, so in the AddEmployee.OnInit we can customize the fields for that customer, i.e. making certain fields hidden or readonly or mandatory.
The following things are customizable per customer:
Menu items
Steps in each flow (ascx control names)
Hidden fields in each ascx
Mandatory fields in each ascx
Rules relating to each ascx, which allows certain logic to be used in the code for that customer
The customizations are held in a huge XML file per customer, which could be 7500 lines long.
Is there any framework or rules-engine that we could use to customize our application in this way? How do other applications manage customizations per customer?
If your regular data is held in a database I'm not entirely sure why you'd want to have all of that customer specific information in an xml file. Move it into the database.
Next, there are many different kinds of rules engines out there. Considering you're using asp.net you might want to look at Windows Workflow for at least some of this. You might read the following: http://karlreinsch.com/2010/02/05/microsoft-rule-engines/
A long time ago I used a product called Haley Rules to drive a c# web app. It controlled everything from the screens that were available right down to the fields that appeared and whether they were required or not. It took awhile to get the team on board with how it worked, but once that happened bringing on a new client was extremely simple. Haley was since gobbled up by Oracle, but was probably the absolute best one out there.
Others you might be interested in are NxBRE and even nCalc. NxBRE is an actual rules engine which is a port of one built for java. nCalc on the other hand isn't a rules engine per se. However, if you can express your logic in simple boolean statements then it is extremely fast. I'm currently using this to drive page flow in one of our applications.
Some commercial ones include: FlexRule, iLog
Your existing rule engine tool supports your web application, which means it meets your needs already. You can use other "Rule Engine" like MS work flow, but IMO it can also end with a hard to maitain situation.
Let's say there is registration portal. It collects general user infomation and save them into database. Simple. we build one protal for one client with several ASCXs and Rules.Then for another client,we add more rules and more controls to these ASCXs. Working in this way, sooner or later we will reach the final straw client. At that time the code base is hard to maitain and devs lost themselves in lots of rules. It is what happened to me.
So to me, it is not about which Rule engine to use.
Then How?
I have raised a question, and one of the answer makes sense to me( thought not a picked answer). In this answer, the guy mentioned what kind of company you are. In your question it is more like which department you are or do you want to seperate your dev teams.
If you are in a archetect teams, build a framework with a rule engine. Create a basic registraion portal as a sample portal.Make DAO,BO decoupled with UI (Seperate layers).
If you are in a customise teams, create customised user control (dont reuse these user control in basic version). What you will recreate is just UI, you can still use DAO,BO as they are not defined in user control, they are at other layers. In this way you get the freedom to define your client specified rules without worring about contaminating other clients rules or introducing new bugs to other client's registrations.
Just realise it is not like an answer to your question. Anyway it is my thoughts after limited xp of working on a engine rule based ,multi-clients web application.
Our team is building a new web site with ASP.NET. We plan to use a 3-tier architecture. The problem is that the controls shown on the web page need to be changed all the time according to the customer's requirements, which means adding a pair of label/textbox, or removing a pair of label/dropdownlist when the customer needs it. So the layout needs to be flexible and allow to easily add or remove controls, although it just shows some simple product messages like price, discount, tax, etc.
The previous version of the web site saved all the control information in a database, like control name, control type (textbox, label, dropdownlist), which page and panel it belongs to, etc. You can see there is a big performance hit because every time there is a request to this page, it needs to get all the required controls from the database and add them to the page manually, no matter whether the request is a postback or not.
We thought about adding the controls directly to the .aspx page, but in this case it will be difficult to change them later. We also considered holding all the controls' information in XML files, which may give a little performance advantage, but it still needs to render the controls all the time.
So this is the problem we have, to improve the app's performance and also meet the users' needs at the same time. Could anyone help me with any solutions or ideas?
PS: you can also ask questions if I didn't make it clear enough. Best regards.
This sounds like a good situation for User Controls. If all you're doing is toggling child-control visibility, then creating a user control with toggleable visibility properties should meet your needs. You can still use your backend to toggle visibility, but you'll only need to pull yes/no flags from the db instead of entire page schemas.
From an architectural standpoint, User Controls are great because they encourage modularity, code reuse, and lend themselves well to version control (UsercontrolV1.cs, UserControlsV2.cs, etc). The point on version control is especially great in cases where change requests require logic updates, or simply need to revert to a build that existed x iterations ago.
Now that is what i call a Flexible web-Application.
the controls shown on the web page need to be changed all the time
Who will change the controls? The client? Can you not just update the .aspx file and publish it to the server every time a control is requested to be changed?
but any way, its an interesting question. There is nothing else really that can be done except using a XML file.
I am designing a pretty complex webform with Master/Detail structure. Is it a good move to keep the add/edit form on the same webpage ?
My current scenario has 2 separate web pages (add new & edit), On add new page the add details is disabled until user saves the master.
On edit page everything works out of the box.
Both the forms have exactly similar controls
I am thinking about the following new structure - Same webpage for Add/Edit (User adds master
record (add mode) -> Saves -> Gets
redirected to the same page with edit
mode-> Can add,update delete new
Details or Update the master he
just entered
What do you guys prefer in such scenarios ?
On a note, separate webform for edit page means duplicating everything
with just some minor changes to Save/Edit functionality. Also for the details I have to provide Add/Edit/Delete on the same page anyway
Thanks Damien.
No, it's not a good idea. My experience is that add/edit might look quite similar, but they have things that differ. The number of differences usually grows as the project grows.
Use different forms, or you'll end up with spaghetti.
You might however move parts that will not change to user controls and include those in both pages.
I suggest to use JQuery and Open Popups for such operations for new and edit case. This will also make reuse of your controls.
In my past projects I've been using webform to implement windows form style complicated backend admin page by using asp.net webform.
Just wondering by using asp.net mvc, can it make this kind of complicated UI page much easier?
This highly depends on what UI you need. For me, it wouldn't be easy without jQuery... but with jQuery it's very convenient.
For example of possible nesting, my app has cart that contains Accordion for customers, with each pane containing custom tabs with sliding animations for orders, with each order containing table of items, where each item can be expanded to show included products details (not to mention context menus to change customers, on-the-fly discounts changing with notification tooltips, popups to show product details, and so on). All this on single page. And I still find it very easy to manage, because all the functionality is well split across MVC controllers and views.
As for "admin part", I use two-level nesting (with second level on another page, but I just don't want to go deep into jqGrid), and it's 5 minutes to setup a new admin page using AutoMapper, custom attributes, and some custom code. Got new entity (e.g. SomeProduct)? 5 minutes and new admin page with grid, custom editing controls and formats is done. With MVC.
But if you need traditional "data grid" approach, chances that ASP.NET will do better. Or maybe jqGrid (or third-party grids like Telerik) will help you, because they have subgrids and all this stuff. I would say, if you don't like Domain-Driven Design, if your application is not object/entity driven, but highly based on raw data tables, then MVC might be not what you need. But I may be wrong because I never worked with such applications. All other apps, I'd prefer MVC.
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.