What are some scenarios where MultiView would be a good choice? The MultiView control along with its View controls simply seem to extend the notion of Panels.
Both Panels and MultiViews seem prone to abuse. If your UI concerns and biz logic concerns are properly separated, why lump views together in a single ASPX?
I have used MultiViews as a more flexible basis for a Wizard control.
I do agree that lumping lots of views together is a code smell. In the case of a wizard there are often lots of pieces of state you want to share throughout the process. The multiview allows this state to be simply stored in the viewstate.
Most of the time I make the contents of each view a single user control that it can encapsulate the logic related to that particular step.
I've used it in the passed to implement a simple Ajax-enabled tab interface.
Style a button to look like a tab, then set it's onClick event to switch the active view in an update panel.
Any situation where you find yourself toggling the display of one or more panels is a prime candidate for a MultiView control. A more templated wizard control, or master / detail forms for example.
I agree that they are open for abuse and you should evaluate whether you're better off separating your code into separate pages before using them. I've worked on projects where the previous developer has tried to put too much onto a single page using MultiViews and they are sheer hell to work with.
One thing to be wary of with MultiViews is that unlike panels, any declarative datasource controls contained inside them will always bind, even when the view they are contained in is not active / visible.
Any time that you want to show different content on a page based on some condition. At work I've created a tab control that just uses a MultiView and another simple control I made that looks like tabs. Each tabs puts a link (which is styled) in the other control that is wired up to set the active view to the correct tab.
It can be useful for things like online forms, where you may have one view showing the actual form and another view displayed afterword with the "thank you" text etc.
Related
I would like to use more client-side scripts on my aspx page. I'm not an expert in this area and I'm a bit overwhelmed at the options. First, let me spell out what the page is displaying and then what I am trying to accomplish.
The Page:
The page containts a GridView (on the left-hand side) which is pulling data from a DB for different types of products a user can request. For example's sake, let's say we have table, chair, and couch.
What I want to Accomplish:
When the user clicks on a row of the GridView (let's say "table"), the ID of that selected row and the title is copied over to the right-hand side of the page into an accordion pane (or a similar display). The header of the accordion pane will be "Product: Table". When the accordion is expanded, the user has the option to specify the color and size of the table (via check boxes, text boxes, etc.). So essentially this is shopping cart functionality on the right-hand side of this page.
I should also point out I would like a "remove" button for each pane in the accordion so it can dynamically be deleted.
What is the best option for this situation? Should I use jQuery, AJAX (AJAX Control Toolkit?), a combination or a different tool? Thank you in advance for your help.
I would use knockoutJs because it's easy to use, has reasonable documentation and good online support. At a glance it looks easy than backbone as well (I don't know backbone).
I would not use the AJAX Control Toolkit unless I had too. I HATE the ajax toolkit as everything happens 'by magic' and once you step off the path shown in the simple demo's you are dead.
Knockout does require a little investment of time, but I consider it a great framework for web apps that require moderate javaScript use.
I have a user control which contains a number of child controls. I want to be able to change the layout of the control (i.e. change the markup surrounding the child controls) via a property of the user control, but I don't want to have to duplicate the child controls themselves. This precludes using, say, a MultiView with different versions of the layout in each view, since in that case I'd have to duplicate the controls. I'd also rather use markup than emit the code for the control directly (as you'd do in a server control).
To give a contrived example, say I have a label and a textbox. In one layout, I want the label and textbox to be contained by divs and laid out on top of each other. In an alternate layout, I want them to be contained side by side in a table.
Should I just go ahead and duplicate the controls between each view? It seems like a violation of the DRY principle, but I'm not sure if I have much choice. A partial solution would be making the views of a multiview into naming containers so that I could at least save myself the time of having to prefix the duplicate control IDs with something to make them unique.
Thanks! Please feel free to ask if the above doesn't make sense.
You could use a templated user control to define header and footer templates for each section of the user control. From there you can use CSS and/or public properties on the user control to style the pre-defined (non-templated) components of the control.
It really sounds like maybe you should go ahead and create a server control instead of just a user control. You'd have to create the markup in code, but it would allow you the best flexibility.
An idea is to create a second user control, that is clone with the first on the design file but have the same code file.
FileLayout1.ascx
FileLayout2.ascx
both of this have
CodeFile="FileLayout1.ascs.cs" Inherits="FileLayout1"
FileLayout1.ascs.cs
You can load the 1 or the 2.
The limitations/problems are that both ascx must have the exactly same control names, and you have the same control 2 times (but the code is only one time)
From my point of view the good think is that you free to design the layout as you like on both way.
I haven't seen this implemented before in ASP.NET, but am thinking about a UI that would look and act like this:
Conceptual Overview
A TabControl is loaded and the first tab contains a grid
When a row is double-clicked, a new tab is created with the record detail
The content of the tab/record detail is created by a usercontrol
Many tabs could be created, and therefore many instances of the usercontrol will be created
I know ASP.NET will rename my (runat="server") ID's for me, and that I can use jQuery or ASP.NET server-side code to work with the ID's... My concerns are:
How can I ask ASP.NET to generate a unique ID for each Nth instance of my usercontrol (to be rendered in a placeholder)
How do I actually create that extra instance of the control?
What else do I need to keep in mind?
Since I don't want postbacks I'm considering basing my implementation off of ComponentArt's Callback Control, and using ASP.net usercontrols to achieve this effect. This will allow me to do most things that require a postback, but won't refresh all the elements on a page... just the section that contains the user control. That being said, I'm not tied to a particular implementation.
You should look into the Page.LoadControl method. It works nicely and as far as I remember you put placeholders on your page and load the controls into the PlaceHolders, that's how you control the ids.
One thing that doesn't work out so well with this approach is when your control raises events that your Page object has to handle. If your control is selfcontained however you shouldn't have a problem.
This might help you get started:
http://www.codeproject.com/KB/aspnet/LoadingUSerControl.aspx
I have a web form that has multiple ListBoxes, TextBoxes, DropDowns. If I put one UpdatePanel around the whole page, I noticed the page is slower. Is this because, every control is being updated? If I put different UpdatePanels around each control, I noticed the page has a better response. Is it right to assume that this is because I have more control of which parts of the page are updated based on selections from ListBoxes and DropDowns for example?
Thanks,
X
each update panel generates a round-trip to the server (i assume you're using a timer or something to cause this)
the general rule would be to group controls in an update panel that must change together, otherwise separate update panels makes more sense
I use update panels with a set of related functions in mind. I find that for my apps when there are related pieces of content on a page, such as a search tool, it is best to be placed in its own update panel. Be careful putting too many update panels however on your page as the client will have to download more code to make it run.
A rule that I use is to set the update mode of all panels to only fire when children are changed, and in some cases it's best to do it programmatically in your code behind. This is best in cases where you have a section of items in another update panel but both don't need to be updated or the parent one only needs to be updated on occasion.
By triggering the panels in your code you will create a little more work for yourself but in the end you will also have a lot more control over the user experience and this may help you also send fewer bits down the pipe.
Andrew
I've been trimming the UI of our website by doing the following in the onload event of that control:
btnDelete.isVisible = user.IsInRole("can delete");
This has become very tedious because there are so many controls to check again and again. As soon as I get it all working, designers request to change the UI and then it starts all over.
Any suggestions?
One simple suggestion would be to group controls into panels based on access rights
Something I have done before has been to create a custom page class (Actually, I do this part on every project) that each ASP.NET Page inherits.
This page class contains an IsAdmin property.
I then subclass the commonly used controls that may or may not be visible between modes into custom controls, and add code to check the Pages IsAdmin property.
All this is maybe an hour of work, but if you build pages using these controls, they manage their mode automatically.
Another fun timesaving tip is if you need to flip the page in and out of readonly mode. I added a property to the main base class, and then added a custom control that renders a textbox in one mode, and a label in the other.
Again, a little bit of time on the components, but then you can create a readonly version of the page in 2 lines of code...Very worth it.
You may be thinking of the situation in the wrong way. Instead of thinking of individual controls, think of it in terms of business roles and what they have the ability to do. This goes along with grouping controls into panels for access rights. For example, maybe only managers have the ability to delete and do other things, and you have a role for managers that you check. This way if there are changes, you can just move users into different roles. Business rules should not change drastically. There will always be tweaking as new positions gain more responsibility, but thinking of it in this way should minimize the number of changes to be made.
A quick and dirty option is using the asp:loginview controls, which can be wired up to user roles.
Not as elegant as the custom page class option suggested by Jonathan, and can be a bit of a performance hit if they are all over the page.