ASP.NET, web form model.
Is there any sample code/site that demonstrate a couple samples for regular website patterns/ templates? Like if I want to use tab to switch between different pages, should I put the code in a single page or in different page, and treat each tab as a page.
Or if in a search page (just a single search bar and button), should I display my result panel in same page using dynamically enable the result panel, or just to another page?
I want to find a general design pattern/ template. Please advise, thanks.
I don't know if this answer will be helpful to you or not. Correct me if I am wrong.
You are specifying demonstration about web designing. It seems the functionality you want is clearly saying to choose from weather you want to use AJAX or not. I suggest why don't you use jQuery Framework for all this functionality.
I would give this a read and consider what best fits your application and your programming style, no one size fits all with paterns.
http://msdn.microsoft.com/en-us/magazine/dd252940.aspx
After you have a general idea, head over to google.com and look for the patterns that catch your eye for simple tutorials
Edit:
For the specific question about whether you should modularize your code. The answer is almost always yes. If you think there is a chance that the component will be used somewhere else then doing this a head of time can save you a lot of headache later. This practice also makes maintaining a lot easier because it gives a clear scope of what could be causing a bug. Instead of having to look threw an entire page of unrelated code for things changing state unexpectedly in the page life cycle.
Let's say I'm on a list page and I
page to, say, page 10. Then I select
a record on that page and redirect to detail
page. After that, I click on the edit
to redirect to the edit page.
After I update the record I'm redirected back to
the detail page. I, then, press back
to go back list to continue my browsing from
where I left off. The key here is
where I left off in the list which is
page 10.
What is the best way to handle this?
Initially, I put a hidden field called page number in each of the webforms and pass it along with the querystring back and forth. Seemed like a lot or a bit redundant checking the querystring on each page and passing it.
I was wondering if there are some other ways. for instance, I've been reading about a separation between the UI and the presentation layer is a good idea (for larger scale apps). To me I understand it as all click handler events will yield control over to the presentation layer which is just a plain class?
Is this correct? Also, is the presentation layer suppose to implement something particular? I know this could probably be saved in session but could someone humor me and show me how to use a presentation layer to handle this (I know it would be overkill but is it possible?)
I don't think there is THE best way. Everything depends of what you achieve to do, ie. the requirements of the whole project.
After all, according to the description, I don't even understand why are you having three pages to do a single thing. By the way, ASP.NET data controls handle mostly everything for you, so you don't even have to ask yourself how to do this (except if you have serious reasons to avoid ASP.NET controls).
For example, a simple <asp:ListView /> will let you list items page per page and show details when a single item is selected. Edition of an element is also quite easy.
What you are asking for is well... large and could span multiple blog posts to give a complete understanding of UI Design Patterns.
I have a small example of MVP with Asp.Net here: What is the best way to reuse pages from one website in another?
However, it is not exhaustive. If you really want information on this you should do some looking into a framework such as WebForms MVP, or ASP.Net MVC.
Check out ASP.NET MVC. It is a framework which goes on top of ASP.NET to do the separation between the presentation layer and business layer.
For simplicity, what you are describing is a very good example of the perfect place to use Asp.Net Dynamic Data.
It's incredibly easy and powerful, and easy to modify once you dig into it a bit. I'd start with the videos here: http://www.asp.net/dynamicdata
I've been using this more and more on every project, for at least the simple CRUD portion of it. I really can't express how much I love this tool now that I'm used to it.
I wonder if someone knows if there is a pre-made solution for this: I have a List on an ASP.net Website, and I want that the User is able to re-sort the list through Drag and Drop. Additionally, I would love to have a second list to which the user can drag items from the first list onto.
So far, I found two solutions:
The ReorderList from the Ajax Control Toolkit, which requires a bit of manual work to make sure changes are persisted into the database, and that does not support drag/drop between lists.
The RadGrid from Telerik which does all I want, but is priced far far beyond my Budget.
Does anyone else have some ideas or at least some keywords/pointers to do further investigation on? Espectially the Drag/Drop between two lists is something I am rather clueless about how to do that in ASP.net.
Target Framework is 3.0 by the way.
The Mootools sortables plugin does just that, and best of all, it's free ;)
http://demos.mootools.net/Sortables
This is just personal opinion, but the problem I find with ready-made controls in cases like this is that they are extremely bloated, because they're trying to fit everybody's purpose. If all you need is a sortable list then a simple Scriptaculous list or jQuery list with a quick WebMethod callback should fit the bill quite nicely, and you can obviously stick this into your own user control.
As I say, just my opinion, but I wouldn't go spending money on something that's going to add tons of overhead to my page, when I could spend (literally) 10 minutes writing one for free.
I've evaluated the Telerik grid as well as Infragistics version. In the end we took an approach similar to what tags2k suggested. We just wrote our own javascript and called .Net PageMethods to do the server side work.
We found both of the "out of the box" solutions to be bloated. Unless you put paging in at like 20 records per row they really stunk performance wise.
Checkout Raj Kaimal's ajax control extender:
http://weblogs.asp.net/rajbk/Contents/Item/Display/517
It works like a charm.
Curious if others feel the same as me. To me, controls such as datagrid/gridview/formview/etc. are great for presentations or demo's only. To take the time and tweak this controls, override their default behavior (hooking into their silly events etc.) is a big headache. The only control that I use is the repeater, since it offers me the most flexibility over the others.
In short, they are pretty much bloatware.
I'd rather weave my own html/css, use my own custom paging queries.
Again, if you need to throw up a quick page these controls are great (especially if you are trying to woo people into the ease of .NET development).
I must be in the minority, otherwise MS wouldn't dedicated so much development time on these types of controls...
Anyone that thinks nobody uses *Grid controls has clearly never worked on an internal corporate webapp.
I'm pretty much writing my own HTML - I'm using the ListView and Masterpages, but not really using the controls much anymore. My ListView laughs at your silly old repeater, by the way.
However, bloatware isn't necessarily a bad thing. If I needed a low volume intranet application built, I'd much rather pay a less experienced developer to drag and drop controls than for an HTML twiddler (like you or me) to craft each tag. There's definitely a place for the quick, simple approach. What's the cost of "bloatware" in that scenario, as long as the control based code is written in a maintainable fashion? Often wiring controls together requires less custom code, which means simple maintenance.
The one place I have to disagree with you - pretty much regardless of the application - is in crafting your own paging queries. You may like to do that kind of thing, but there's absolutely no business value in it. There are several professional-grade DAL tools which will usually write more maintainable, faster queries than most developers. Even if you lovingly craft the perfect paging query, it won't keep up to date with changes to the schema unless you continue to throw hours after it. I think better use of those hours is to build a lightweight system and put those hours into monitoring and fixing specific bottlenecks, rather than immediately jumping to the "database assembly language" layer.
I've been reading your posts guys and it made me feel dumb.
I mean in every application I made where I work there is at least one datagrid/gridview in it. And I didn't have the feeling I am missing something.
Sure I find datagrid/gridview kinda bloated but are they that much disgusting to use?
I think you need to learn to use GridViews before you condemn them. I use them extensively. At first it was a bit challenging to figure out certain things, but now they are indispensible.
GridViews within UpdatePanel with AJAX CRUD and pagination are lightning fast. One of the larger systems set up this way (for internal/external application) has a moderately sized db in the backend. There are many nvarchar(2000) fields and the transitions and updates are great.
In any event, if you've written your own version of displaying data, you may want to continue using it if it works. (Same argument could be made for writing your own compiler, writing your own version of HTML, writing your own version of data access binaries...) The advantage of using GridView is that there are a lot of people who are familiar with it and that MSFT has abstracted/modeled the class to do a lot of things that we used to have to do manually.
Every single app we development at my company has grids (the apps are all behind the firewall). That includes both web apps and Winform apps. For the web apps it's the good ole gridview with custom sorting for the winform apps we use Janus grid. I'm trying to get the developers/users to think of a better user interfaces but it's a tough to change. I gotta admit its still better than the alternative of the users building their "own" apps with Access that I would then need to support!
Using controls like the GridView are great for simple apps. Even if you are a server-side HTML bracket-twiddling ninja, they can make developing simple stuff much less time consuming. The problem is that they usually start to expose their shortcomings eventually, and you end up having to spend time tweaking them anyway. But at least you can get up and going quickly to start out with.
For example, the default paging in a GridView doesn't support paging in the database itself (you have to load all the rows before it will page them), so once you start feeling that pinch in performance, you may need to think about rolling your own or, perhaps better, find a more capable grid control.
Anyway, the point is that pre-built components are good. They help. But as usual, it depends on what you need them to do.
I've actually used GridView extensively for an adminsitrative console. I even created a custom DataFieldControl that sets the field's header text and sort expression based on data field, creates an Insert row in the bottom and automatically collects the values in the row and forwards them to the data source's insert method, and generates a list box if an additional list data source is specified. It's been really useful though a huge time investment to build.
I also have another control that will generate a new data form based on the fields' metadata when there are no records (in the EmptyDataTemplate).
<asp:GridView ...>
<Columns>
<my:AutoField HeaderText="Type"
DataField="TypeId"
ListDataSourceID="TypesDataSource"
ListDataTextField="TypeName" />
</Columns>
<EmptyDataTemplate>
<my:AutoEmptyData runat="server" />
</EmptyDataTemplate>
</asp:GridView>
I really like the telerik radgrid. Their product ain't cheap, but you get a lot of controls and features. And the data binding support is pretty good, both in a simple asp.net data source binding way and in a more custom handle-your-own-databinding-events kind of way.
At my company we use grids everywhere, mostly ComponentArt Grid (http://www.componentart.com/). Yeah it's bloatware but you get a lot of functionality that wouldn't be much fun to re-invent: sorting, paging, grouping, column reordering, inline editing, templating (server-side and client-side). The client-side APIs are nice too.
I like the GridView control and have used it in several custom DotNetNuke modules for my company's web site. For one thing, using the built-in controls means less dependencies to worry about. And once I had it set up how I wanted it, I basically copied the code to other pages and just had to do minor tweaks.
I've found that there are so many options with modern grid controls (Infragistics, Telerik, etc) that it takes longer to configure the grid than anything else. The MS controls are pretty simple yet they can do pretty much anything.
They are one of the benefits of asp.net. Up until just recently I hated them, but the more you use them the easier they become, once you learn what setting you must change for which instances. Mainly I like the form view and listview the gridview still needs some work.
We use the Infragistics UltraWebGrid + LinqDataSource on our intranet apps.
It gives us ajax, sorting, filtering, paging all server side.
The "export to excel" also is a killer feature.
We have 5000+ users,lots of data, performance is excelent.
I largely abandoned grids once I started designing from user stories, rather than from database table requirements. And never editable grids. The old way was just how we coerced users into doing data entry/table maintenance for our systems, and it never matched their workflow - any real job ended up skipping from one master/child form to another.
And the users never figured it out - but they sure knew our applications were harder to use than they should be.
An exception is analytical applications. But there are relatively few of those, and they are largely read-only.
I too would like to see an expanded answer on why GridView et al are considered "bloatware." I have extensively used GridView as well as 3rd party products (Telerik, etc) and find that for the majority of internal and some external projects, they work great. They are fast, easy to use, customizable - and BEST - I can hand them over to someone who knows GridViews who can then easily pick up where I left off. If I were to hand-code all of the numerous apps/controls, the overhead in the next person figuring out what is going on would be enormous even under the best of circumstances.
For me, I can see some of the 3rd party products being bloatware (but still sometimes useful), but the bare-bones GridView I've found to be quite fast with moderate queries.
For my corporate intranet projects, grids are indispensable. They are the foundation for easy reporting on the ASP.NET webforms platform.
Easy to Design
Paste the grid on the page. Insert BoundField objects for simple binding. asp:HyperlinkField for easy linking.
Binding
You can bind grids in a handful of ways:
a collection of objects (List, ArrayList, Hashtable, or any simple collection)
SqlDataReader in your code-behind (yikes, that would require SQL in your presentation tier)
SqlDataSource (specify a stored proc. All the columns on the resultset map directly to the grid's columns. It's a very quick and dirty if the report doesn't mimic your domain object nicely. i.e. summations of different things.)
objectDataSource (binding to a method on your BL)
For those who might call out SqlDataSource and ObjectDataSource, you don't always have to have them declared in your .aspx.cs or .aspx.vb . I am not advocating them here, just pointing out the possibilities.
I don't think you can discount the RAD benefits of the built-in GridView and other 3rd party grids. Management types love and want tabular data.
Components like the GridView/FormView/DataGrid follow the 80/20 rule.
This means that 80% of the time when you use them for simple purposes they get the job done and are extremely easy to implement.
But 20% of the time you will be trying to build something complex (or weird) and you will be forced to jump through a dozen hoops and bend the code in many ways to try to implement a solution.
The trick is to learn whether the problem is an 80 problem or 20 problem, if you can identify the 20 problem early you are much better off writing the code from scratch yourself and ditching the "time saving" one.
I use them extensively in the corporate environment I work in and I'm working with one right now. The people who don't use them remind me of all those "I built it with Notepad" developers of years past. What's the point of using asp.net if you're not going to take advantage of the time savings?
I have never used it. I completely agree, it's bloatware. I usually end up using the repeater with custom controls that i made.
For anything long term I would try to avoid datagrid/gridview, it sometimes becomes too hacky making it do exactly what you want, after a certain number of these tweaks you start to realise its not saving time in the long run and you might not be getting the control over markup that you need.
However the built in paging and sorting functionality works well and in 2008 there is a new ListView control which aims to sort some of these problems out and give you tighter control of the html that is output.
I have wondered about this for a long time. There seems to be a consensus here that the grid controls are bloatware. But, can anyone definitively cite the cost of using these controls? Is there excessive HTML sent to the browser? Too much resource devoured on the server? Is generating the HTML table faster (assuming it's well-written)?
In addition to the bloatware issue, I have often run aground when UI requirements are enhanced to include features beyond the scope of the standard controls. For example, in early ASP.Net versions, I struggled with putting images in column headers. And, I believe it's still a challenge to add a second, top-level header row spanning multiple columns. At some point, it becomes really difficult to wrestle with the control to achieve the desired effect. And it's frustrating if you know the HTML you want, but you just can't make the control do it.
On one project, I finally gave up and wrote myself an HTML table class to generate a very complicated grid. It took a couple of days to get it just right. But, now I have the basic code, and it will be much more efficient to tweak that for future grids.
No doubt about it, though. It's hard to beat the fancy grid controls for speedy development, if you can just live within their limitations.
If you work with designers a lot on public facing web sites then you should ditch the GridViews and stick to repeaters. That's my opinion anyway - I've had to pull apart hundreds of GridViews and turn them into simple repeaters in order to fulfill the design requirements.
If you go near DataGrids or GridViews with a 10-foot pole on a public facing web site then you HAVE to use the CSS friendly Control Adapters. (At this point you might find it easier just to do it in the Repeater.) Prior to Control Adapters being available I would have considered these controls broken out of the box.
I find that too many .NET developers do not have a good understanding of design, accessibility, CSS, javascript, standards etc. which is why they succumb to GridViews, ObjectDataSources etc.
GridView is fine and very powerful control and works well with css or theme. The only thing that is annoying me is that VirtualCount property was dropped when old 1.1 DataGrid was replaced with GridView in asp.net 2.0 and it was useful for implementing custom paging. However same can be done via data adapters.
Though working with repeaters is maybe clearer and you have total control over rendered html still I wouldn't recommend going on that ways because is harder to implement and maintain.
I never really used the standard WinForms grid before but at my last job we used the ComponentOne FlexGrid extensively and it worked beautifully. There were still some annoyances with trying to get all the customization we wanted but overall it saved us a ton of time and produced beautiful results.
Currently I'm working with Silverlight 3 and RIA Services and I can't imagine trying to produce what we're doing without the DataGrid and DataForm controls. The time being saved far outweighs any of the overhead.
i am a moderate level developer i can say without these controls i couldn,t ever learn developing.just you have to admit yourself to it for a while till you find your way to customize it and the end result will be great
I'm trying to look at it all in context. I have a page that has a nice gridview (displays 10 rows at a time, 6 columns, sorting, and paging) and if I just look at the html table that is created along with the viewstate, I'm only seeing 29k of code.
Is 29k vs. 18k for using a repeater or listview really worth all the effort in these broadband times?
I personally stick with the gridviews however the design guy I work with sometimes gripes about trying to style it via css.
Just reading your posts. I agree PHP is easier than asp. but I just started using visual studio for formviews and gridviews. Can not get much easier for either vb or C# programmers. ASP still has problems uploading large files. PHP it's a snap. I run PHP under IIS 7.5