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.
Related
Stackoverflow members,
How do you currently find the balance between javascript and code behind. I have recently come across some extremely bad (in my eyes) legacy code that lends itself to chaos (someHugeJavafile.js) which contains a lot of the logic used in many of the pages.
Let's say for example that you have a Form that you need to complete.
1. Personal Details
2. Address Information
3. Little bit more about yourself
You don't want to overload the person with all the fields at once, so you decide to split it up into steps.
Do you create separate pages for Personal Details, Address Information and a Little bit more about yourself.
Do you create controls for each and hide and show them on a postback or using some update panel?
Do you use jQuery and do some checking to ensure that the person has completed the required fields for the step and show the new "section" by using .show()?
How do you usually find the balance?
First of all, let's step back on this for a moment:
Is there a CMS behind the site that should be considered when creating this form? Many sites will use some system for managing content and this shouldn't be forgotten or ignored at first glance to my mind.
Is there a reason for having 3 separate parts to the form? I may set up a Wizard control to go through each step but this is presuming that the same outline would work and that the trade-offs in using this are OK. If not, controls would be the next logical size as I don't think a complete page is worth adopting here.
While Javscript validation is a good idea, there may be some browsers with JavaScript disabled that should be considered here. Should this be supported? Warned about the form needing Javascript to be supported?
Balance is in the eye of the beholder, and every project is different.
Consider outlining general themes for your project. For example: "We're going to do all form validation client-side." or "We're going to have a 0 refresh policy, meaning all forms will submit via AJAX." etc.
Having themes helps answers questions like the one you posted and keeps future developers looking in the right places for the right code.
When in doubt, try to see your code through the eyes of someone who has never seen it before (or as is often the case, yourself 2 to 3 years down the road), and ask yourself: "Based on the rest of the code, where would i look for this function?"
Personally, I like option number 3, but that's just because it fits best with the project I'm currently working on and I have no need to postback or create additional pages.
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.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
Concerning pages that build a web application:
Lately, I have found myself creating web pages that are simpler than the ones I used to. Before, I would try to jam as much functionality into a single page as I could to prevent from having lots of pages.
I am starting to realize that this was just making things way more complex, convoluted, and confusing than it had to be. Why not have more pages? I think the reason that I was doing this was because I didn't want the user to have to browse to other pages; just to have all the functionality they needed on a single page.
Well, these good intentions turned into an overly confusing interface for the user and very unmanageable source code. I am a new developer and I am trying to be very reflective of what I am doing so that I can improve. If it makes a difference, I am developing in ASP.net (though these are probably considerations for any platform).
My questions are:
Am I overthinking these things?
Has anyone else found themselves doing this?
Where is the happy medium?
There is no expert who can give you a rule that works in all places at all times. I have been known in my industry for years for "easy" interfaces and we've won significant amounts of business for it (as well as 5 "Best in Class" awards). I have also had people within my company and outside of it tell me - for years - that they like my work but wish that I would "jazz it up" with more graphics and such. What always amazes me is how little connection people see between the two.
So...a few rules of thumb:
A page should do one main thing.
A page may well have multiple links related to the main thing
Menuing and link layout should be consistent across pages
Simpler is better than more complex
Pages should be visually appealing and inviting
Rule 4 is more important than rule 5.
For example, my product provides an interface that lets people define classes and events to be displayed in a calendar. I could have one page that lets you Review, Add, Update, Delete and Edit the classes. Indeed, in some simpler areas, I've used the gridview to let people manage everything in a grid. However, classes have too much information to do this and still follow the rules above.
So,
The main idea is: "Here is a list of classes for this location"
The links are "Add New" shown above and to the right of the grid, Change and Delete are links within each row. This is consistent across the app.
Menuing for the system as a whole is always across the right/top. Nothing else appears on the class/event page except for standard elements common to all pages (a logo, a header, a footer).
The grid is nicely styled but there are no spurious graphics (4,5,6)
A few last things about UIs and graphic design.
First, develop your own vision and be consistent across pages and apps.
Second, do not be afraid of simplicity.
Next, when soliciting advice from others keep in mind that you do not want their advice - you want their impressions: you want to understand the way they perceive the interface. Advice is sometimes good but, more often than not, actually harmful. In my experience, everyone thinks that they are a UI expert.
When you do your hallway (or formal) useability testing you should discount almost all advice to the effect that "you should make that stand out more." As you'll see, it will quickly become "and that," "and that," "and the other." If you follow this advice, you'll end up with a mess due to Brittingham's first rule of design: If everything is important than nothing is. (There you go: when explaining why you can't make someone stand out more, just tell them that "it violates Brittingham's first rule of design!")
Hope this helps!
You hit the nail on the head. Use the KISS principle. (Keep It Simple Stupid)
I've done this in the past as well and not only does it make for a hideous UI, but confusing as to what operations you can do on the page due to having too much functionality. I've often found in testing that I did not have enough checks to see if the user could perform a certain operation based on the state of the data.
It's easy enough in ASP.Net to write several pages that do simple tasks and then link them together with Response.Redirect or Server.Transfer. Now all I try to achieve on any given page is what the design specs say. So if my page is just a search page, that's all I give. If the user wants to see the details of an item that was returned in the search, then I send them to an itemDetails.aspx page.
You've broken a wall that most software developers have, the one that was blocking your view on usability before. A lot of developers don't really think about it and try to make it easier for them by stuffing functionality in one window, web page or whatever.
The thing is once you start designing software from the user's point of view, i.e. making it easier, several things start to become clear. One is the issue of code maintenance, that code is easily more managable to work on if you don't stuff everything in one giant class or whatever travesty you've been doing. The other is usability itself, that you start to think how the user is actually using your application through the graphical interface. Third is avoiding requirements or scope creep where you stop developing functionality that the user doesn't need.
We as users want simplicity partly because we don't want to spend most of our time muddling through a bad UI when we can get our work done faster with a simple and slick UI. That makes it for us software developers the right thing to do, to think through your design on all levels... that and specs always lie.
Definitely agree: most attempts at writing pages/forms that do too much have resulted in
bugs and rewrites. Problems occur with keeping all parts valid/synchronized,
excess managing of users' expectations ("I've entered a bill number here and clicked "find person" there but it gives an error message. Why?") when the two are logically separate. These questions cannot arise if only the valid options are visible,
Formatting/layout issues: In ASP.NET pages, trying to layout independent User Controls turns out to be a nightmare ("But we really want all the buttons vertically aligned!" in separate user controls. Good luck with that.)
I'd consider webpages with more than one functionality only if the target audience consists of domain experts, i.e. people that need lots of functionality on one page for better productivity (think data-entry or financial software with lots of variables).
Even then, most of the time, it's possible separate pages into single units.
No
Yes - me
I found the happy medium was to use Masterpages, and using it in a way that was familiar to IFrames. That I could have a lots of functionality combined well together. There is a more interesting way of doing this with WPF/Silverlight called Prism
The amount of functionality on a page is usually not determined by you but by your customer. If the customer demands a single page to update some VeryComplexObject, you're likely to end up with an aspx page that has a significant number of lines. Main reason is that you simply have a lot of event handlers for all actions on the page.
Whether that page is complex is entirely up to you. You should always attempt to make your code-behind file as simple and clean as possible. Some suggestions in that direction:
Move all business code to another application layer.
Use ObjectDataSource for providing data to data-bound controls such as ListView, GridView, Repeater, ... Delegating loading of data to a dedicated object prevents a lot of overhead in your aspx.cs file.
Another suggestion is to use user controls to implement portions of your page. You would usually only do this when you can reuse the user control, but it can also be of great help reducing page complexity (both of your code-behind file as well as your aspx).
Sometimes I think we are all guilty of forgetting just who it is that we develop our applications for. It isn't always easy as a developer to be able to take a step back and have a look at your application as a user might do so. This is why big companies employee hundreds of people to do this for them and they don't always get it right.
Usability is a massive subject but it is defiantly something that all developers need to keep in mind. It has taken me a long time to learn this but when tackling any development task I always try to think about how my users are going to interact with what I am writing. This will make a difference to all levels of your development.
I would suggest reading Don't Make Me Think by Steve Krug. This book won't take you an age to read and it puts across some fantastic ideas that can help you to develop applications that are much easier to use and understand.
I always find that once I have thought about the user experience the decisions about what my web pages are going to do and how they are going to interact are much easier to make.
Maybe you should ask the people who are using your site. Or better yet, just watch people use your site. I think that would tell you if your site is designed well, or if you need to change it.
Looking for some direction here as I'm running into some migration problems.
We have a legacy application. The 'infrastructure' is running just fine. Business logic and data access layers written in VB calling SQL Server for the database.
I have a LOT of experience writing Winforms (desktop) application and have had no problems. However, the last time I wrote any ASP.NET stuff was in 1.1 (VS.NET 2003).
Among other things, for ASP.NET 2.0 and up, the Grid layout is gone. It's not just a simple case of dropping controls on a form, aligning them, ordering them and working with the code-behind anymore.
The new web-based application is starting out pretty simple. Just a common header (already made a user control for that) and footer with your typical CRUD functions in the middle.
I tried being 'intuative' in using a master page with content place holders but I couldn't get the placeholders to "grow", to say nothing of not being able to put a text box where I wanted one. Oh, I found the option in VS2008 to allow absolute positioning but it only worked for SOME controls - others I had to manually edit the asp tags.
Then I saw examples using div's and tried to implement them but I ended up with results that had objects writing on top of each other. The online help wasn't helpful to say the least.
Does anyone know of a good book, website or tutorial that can give the basics of what I'm looking for? In practice, I'm looking to make simple pages where some objects may have to push others gurther down the y-axis (as in, several comments being made and that section would push the section listing the 'attachments' down further). I have no trouble when it comes to all the other aspects of this application. It just appears that my webforms skills are about 3-4 years out of date.
This isn't going to be some fancy flash/silverlight application - just simple 'data maintenance' to get rid of some ugly and bug-prone processes involving reading common mailboxes and decoding Word files. The new goal is to have a nice weborm with proper validation.
I guess what I'm looking for is a "Webforms for Winforms programmers" book or site.
Help!
Thanks in advance.
The best advice I've heard on learning to use html/css layout goes something like this:
When building a new page, don't try to get all fancy up front. Start by building a very basic, text-only page. It should look like something from 1996- that brief period where everyone had just discovered the web but had not yet started using the table tag for layout- only no comic sans font. Don't use images at this point, unless the image is genuinely a part of the information being conveyed (as opposed to the window dressing to make it look pretty: you can add those later). There will likely be an h1 at the top of the page, and give each sub heading an appropriate hN, but at this point there shouldn't be any layout information in the page at all. The only place you'll have a table tag is if you genuinely have tabular data to show. If it helps you write this code then you can wrap everything in old-fashioned <center> tags for now- just don't forget to remove them later.
Now let's start tweaking the markup a little. Use things like ul (unordered list) for your list of navigation links and label/legend to identify and group your form areas. The general idea here is to have each element on the page encased in the most appropriate html tag, and to use the full set of available tags- each for it's designated purpose.
At this point you have a page that is ideally suited for a screen reader or search engine. By building this page first, you have made SEO and accessibility compliance easy on yourself. Of course those aren't the only requirements, so we're not done yet.
Now you need to identify the different sections of your page, from both the layout and logical perspectives. The page should largely already be divided logically, but you may find a few places where the normal tags don't cut it. You'll also want to group certain elements for layout reasons. Encase each of these areas with a div tag, and give the tag a class name that refers to the purpose for the tag: the group your are creating. This is just another case of using the a tag (the "division" tag) for it's intended purpose. Also, since elements can have more than one class, you may want to think about also grouping your classes logically. For example, you might want to have a separate class that distinguishes the site template from the rest of the page.
By and large this should not have changed the appearance of the page, but now you have something where it should be very easy to start adding styles. At this point you can now start adding images and layout. The goal here, though, is to change the actual markup as little as possible. If you can manage it only add ids and classes, though you will likely need to add an additional span or div that you had not identified earlier, and sometimes you'll need an extra block level element to force a compatible layout across browsers.
If things are done correctly, the result is a page that not only looks good, but is also easier to work with when testing across browsers, will naturally degrade well when a style or javascript feature isn't supported, and scores well for SEO and accessibility. This also makes it easier to have a developer build a simple page that provides a certain level of functionality, which they can this pass off to a separate designer to make it look good.
You may also want to check out A List Apart. This is a great website with lots of "tricks" for using CSS to layout things on the web along with lots of other web oriented content.
Grid positioning was an abomination for websites. Sure it made for an easy transition from those familiar with the WinForms designer, but it produced horride HTML that is nearly impossible to maintain.
The very best resource I can recommend to you is CSS Mastery. You'll need to learn HTML and CSS, but they're quite easy to get into.
By the sounds of it, you're looking for a crash course in HTML ?
the "Design Canvas" of an ASP.NET aspx Page & ascx Control is just HTML tag markup.
If you've no web design experience, I'd recommend starting somewhere like
W3Schools
When Microsoft gave us ASP.NET, they tried to make programming websites, more like programming rich client applications. However, there are a lot of issues you have to deal with, the major one being statelessness, when developing for the web that don't exist when developing a thick client app (WinForms). So the first step is to not think of the two as similar in anyway.
The drag and drop tools are nice, but what you really need to understand is HTML and client server models. HTML will help you understand how things are getting laid out, and client server models are important to understand how data gets to and from the web to the server. If you have developed in ASP.NET 1.1, then things really haven't changed for 2.0. The concepts are the same, just some of the provided controls have changed.
A lot of people were really unhappy with the grid-based layout from 1.1, because it didn't really work in a number of situations. It still has to ultimately render as html, and html just isn't suited to that kind of layout. For example, things might not be ordered properly or pushed off the screen for mobile browsers (iPhone, etc). There's also things like screen readers for the blind. If you work for the government, that 2nd item is a legal requirement rather than just a nice-to-have, and there are a lot of developers who do work for the government.
So ASP.Net 2.0 tried to generate markup that's at least a little nicer for html. The downside is that you actually have to understand html layout now. But, c'mon: you're building a web site. If you can't handle a little html you're in real trouble.
My advice to build one static page using something other than visual studio. Use <input tags rather than server controls on that page and don't actually implement any logic. Use it to understand how your layout will need to work. Once you have that down, it's really easy to duplicate that for your pages in Visual Studio.
This doesn't really belong as a separate answer, but I wasn't sure you were likely to see another comment to my response above.
The normal behavior of all block-level elements, including divs, is for each new element to appear below the previous element. It sounds like you've set position:absolute; on everything, perhaps while playing with the Grid-based layout option in visual studio. Don't do that- it's hijacked the expected behavior and that's why you see everything piled on top of each other.
Although ASP.NET MVC seems to have all the hype these days, WebForms are still quite pervasive. How do you keep your project sane? Let's collect some tips here.
I generally try to stay clear of it... but when i do use WebForms, i follow these precepts:
Keep the resulting HTML clean: Just because you're not hand-coding every <div> doesn't mean the generated code has to become an unreadable nightmare. Avoiding controls that produce ugly code can pay off in reduced debugging time later on, by making problems easier to see.
Minimize external dependencies: You're not being paid to debug other people's code. If you do choose to rely on 3rd-party components then get the source so you don't have to waste unusually large amounts of time fixing their bugs.
Avoid doing too much on one page: If you find yourself implementing complex "modes" for a given page, consider breaking it into multiple, single-mode pages, perhaps using master pages to factor out common aspects.
Avoid postback: This was always a terrible idea, and hasn't gotten any less terrible. The headaches you'll save by not using controls that depend on postback are a nice bonus.
Avoid VIEWSTATE: See comments for #4.
With large projects the best suggestion that I can give you is to follow a common design pattern that all your developers are well trained in and well aware of. If you're dealing with ASP.NET then the best two options for me are:
o Model View Presenter (though this is now Supervisor Controller and Passive View).
This is a solid model pushing seperation between your user interface and business model that all of your developers can follow without too much trouble. The resulting code is far more testable and maintainable. The problem is that it isn't enforced and you are required to write lots of supporting code to implement the model.
o ASP.NET MVC
The problem with this one is that it's in preview. I spoke with Tatham Oddie and be mentioned that it is very stable and usable. I like it, it enforces the seperation of concerns and does so with minimal extra code for the developer.
I think that whatever model you choose, the most important thing is to have a model and to ensure that all of your developers are able to stick to that model.
Create web user controls for anything that will be shown on more than one page that isn't a part of masterpage type content. Example: If your application displays product information on 10 pages, it's best to have a user control that is used on 10 pages rather than cut'n'pasting the display code 10 times.
Put as little business logic in the code behind as possible. The code behind should defer to your business layer to perform the work that isn't directly related to putting things on the page and sending data back and forth from the business layer.
Do not reinvent the wheel. A lot of sloppy codebehinds that I've seen are made up of code that is doing things that the framework already provides.
In general, avoid script blocks in the html.
Do not have one page do too many things. Something I have seen time and time again is a page that say has add and edit modes. That's fine. However if you have many sub modes to add and edit, you are better off having multiple pages for each sub mode with reuse through user controls. You really need to avoid going a bunch of nested IFs to determine what your user is trying to do and then showing the correct things depending on that. Things get out of control quickly if your page has many possible states.
Learn/Grok the page lifecycle and use it to your advantage. Many ugly codebehind pages that I've seen could be cleaner if the coder understood the page lifecycle better.
Start with Master Pages on day #1 - its a pain coming back to retrofit.
Following what Odd said, I am trying out a version of the MVP called Model Presentation which is working well for me so far. I am still getting an understanding of it and adapting it to my own use but it is refreshing from the code I used to write.
Check it out here: Presentation Model
Use version control and a folder structure to prevent too many files from all being in the same folder. There is nothing more painful than waiting for Windows Explorer to load something because there are 1,000+ files in a folder and it has to load all of them when the folder is opened. A convention on naming variables and methods is also good to have upfront if possible so that there isn't this mish-mash of code where different developers all put their unique touches and it painfully shows.
Using design patterns can be helpful in organizing code and having it scale nicely, e.g. a strategy pattern can lead to an easier time when one has to add a new type of product or device that has to be supported. Similar for using some adapter or facade patterns.
Lastly, know what standards your forms are going to uphold: Is it just for IE users or should any of IE, Firefox, or Safari easily load the form and look good?