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.
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.
Can some one please tell me if I should use user controls in my project as much as I can? Ff so why and if not why not?
It's an interesting question; but think of it this way.
You've just written a table, listing all of your users. You show this on the List Users page of your website.
On the "Find User" page, you might want to be able to show a list of users. Do you rewrite the same HTML, code, javascript, CSS as before? Or do you reuse the control, this time adding the ability to filter by a user name or other attributes?
Essentially, user controls are there to package up reusable bits of your website. Rather than repeating the same code everywhere, you can package it up in a user control, and simply add it to any page you want just by adding the appropriate tag.
Also, you have just made ONE control in your project responsible for dealing with some functionality - all of the logic for it is in one place and separated from other code. This is an important concept too, as it stops all of your code being jumbled together. In the users example, you can interact with a list of users through an interface, rather than mixing it with other code that might do different things. This is called SRP and can be a good thing.
As a practical example, we have a control that shows a list of our products. We can reuse the same control on the Find screen, the Admin screen, the "Products Like this" screen, and on the "Products you have chosen" screen. This code contains a lot of logic that is all in one place so it can be maintained easily, and it can be reused very simply too.
User Controls can be a very good thing. So you should use them when you feel like you can package up a group of existing controls, HTML etc. It makes them reusable, and much easier to maintain.
There is also the concept of custom controls - these are usually reimplementations of existing controls - you might have an ExtendedTextBox, for example, that validates the text as someone types it.
You can read more about both kinds of controls here
User controls are good for the same reasons that subroutines/functions/methods are good: code (and markup) re-use.
Like subroutines, controls can be a problem if they do things like modify global state, make lots of DB or other off-box calls that aren't always needed, introduce unavoidable synchronous blocking, etc. They can also add an unnecessary layer of complexity if they are never re-used.
I would use the controls that the VS IDE Toolbox provides as much as possible. I would only roll my own control if something that the environment supplied, didn't quite do what I wanted it to do.
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.
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.
In my application, I have a situation wherein the users will need to have the flexibility to customize the UI to a certain extent. The following are some of the customizations that is being discussed now...
Change Label text associated with the with Use Input controls
Mark a control as Mandatory/Read only/Hidden
Assign a regular expression for the text box
Are there any recommended design patterns for my situation? Seems like I need to store all these in a database and worried about the performance impact if I have to read every element from the database for every page.
Thanks,
Harsha
I would look at some of the open-source CMS or portal systems written in ASP.NET and see how they are doing UI customization (if they are).
Phil Haack has some insight at the following article:
Scripting ASP.NET MVC Views Stored In The Database
http://haacked.com/archive/2009/04/22/scripted-db-views.aspx
Apparently it's not an easy thing to do in ASP.NET. It's easier to do in ASP.NET MVC, because the markup is cleaner and you can control it with jQuery.
The overall concept you are going for is not easy to have system wide, however the specifics you stated are fairly easy.
You'd have to setup some fields in a database for those values and then on the page load set those values on the page load. Pretty trivial from a 'how to'. Which your question shows that you 'get'.
Now unless you are using an Access Database :-), I don't think you have to worry about the performance hit. But if truly concerned, put some caching logic on those values so you only have to hit the database once. Though, be aware this will store the values in memory on the server, so if you are working with a very minimal hardware this could be an issue as well.