I have a asp.net webpage that displays a link Login or Logout depending on a session variable "IsLogged". I want to implement caching in that page. But after applying caching the Login/Logout becomes inconsistent with the session variable. What is the best approach to address this problem so that I can also apply caching in that page?
Thanks,
Partha
I am not sure how you are caching specifically but you could break your page up into two user controls (ascx).
Your aspx page could contain the user control to that shows the login information (make sure that when you load the user control with a dynamic url so that the caching ignores it because the address is diff everytime like:
yourSessionInfo.ascx?stopcache=32487239875 (the number could be just current time in ticks)
You just need something that changes in your url so that the page 'looks' like it is different and reloads.
Then have the rest of your page in another user control that has a static url:
yourRestOfPage.asx
Notice nothing changing in the url so page can be cached.
Not sure if this will solve your exact problem but it should at least start you down the right path.
Related
I have a master page which has a rather simple menu system. The menu items available are based on the logged on user. However, the database calls to determine this logic are over a second which is probably too long for my liking.
Is there a way to wrap the Menu into a UserControl but along with having a duration to refresh but obviously also the output cache should be on a per user basis?
I know the other solution is to cache the data for each user and then rebuild but I thought the more efficent place to start would be Page Output cache.
Please note also this application does not user Session state.
You can look at VaryByParam method of Page Output Caching.
When your user logs in add a query string to your page something like page.aspx?uid=x123
then add the following to your page:
<%# OutputCache Duration="10800" VaryByParam="uid" %>
This will make it per user cache.
Do remember:
Even if you put your user as a query string, still do the validation, that its the same user who logged in, to avoid users peeking into each other's view by simply changing the query string.
I am working in ASP.NET (framework 2.0) with Master Pages.
I have a page that requires registration and then the user gets kicked back to the referring page.
I need to figure out how to provide a success lightbox that appears over the referring page, not the registration page (the event is fired on form submit).
I have the inline stuff in the master page and the scripts and everything fires just fine but the form is refreshed with the new (referring) page and the DIV gets hidden again.
Is sessions the only way to go here? Is there a way of having one lightbox appearing from the master page regardless of what the sub-pages are doing?
Thanks.
There should be a successful registration event. Can you emit some javascript in that scenario that would cause a redirection to the referring page. You could pass a parameter which would indicate that a light box should show up. I don't think you can redirect directly from successful registration because I am guessing that some cookie would need to be set- which the framework should handle. I might be off, but that is where I would start. I would try and avoid Session if possible.
I have an ASP.Net(VB.Net) project which has various modules/functionality. I want to give users the freedom to set their own default startup page.
I don't know how to get a head-start implementing this feature.
Also, I am NOT using MVC
On the master page place some control to choose current page as default (i.e. button or checkbox). After user has select current page as default you can store the page address to user's profile or any storage you like.
Set the site start page like Default.aspx and in the Page_Load method of this page read user's saved default page if exists and redirect to it.
You'd want to set up a way for the User to store their preferred home page in your database (or your preferred method). Once that's done you should be able to do this in a simple fashion:
ASP.NET WebForms:
On the Master Page / Default page, check to see if they're logged in in your Page_Load event.
If they are, check to see if they have a start up page saved, if they do then use Response.Redirect and send them to their preferred location.
If they don't, or aren't logged in, then show them the default page.
ASP.NET MVC:
On the HomeController's Index method check to see if they're logged in.
If they are, check to see if they have a start up page saved, if they do then use RedirectToAction and send them to their preferred location.
If they don't, or aren't logged in, then show them the default view.
There are probably plenty of other ways to accomplish this as well, but this should be a straight forward way to get your started.
I have a set of interlinked dynamic web pages.
When the user clicks from one page to another, I don't want any caching to happen - the request must go to the server, which will return an up-to-date page.
But when user clicks Back, I do want the cache to be used - some of the pages can take some time to generate, which is fine when you're clicking through to them, but not when you're clicking Back.
Is this possible?
(Please don't suggest re-engineering everything as a single page making AJAX queries!)
(Note: this question is the opposite of the ever-popular "How do I prevent caching when the user clicks Back?" question.)
A common trick for avoiding the browser cache when dealing with dynamic pages is to add a parameter to the link url that is unique (using the time, to the millisecond is common).
When the user hits the 'back' button, they will go back to the last rendered version, and should get it from the cache.
I'm doing some brainstorming for a portal framework, and I'm envisioning a breadcrumb navigation stack that is tracked via the ViewState (so that if the user clicks "back" in their browser and clicks some other link, the breadcrumb trail will depart from the right page). My pages are really just ascx controls that get loaded into a placeholder control on the main portal page based on the URL. When the user clicks a portal link, there is a postback that loads the original page and invokes the given link's "clicked" handler, which should then "push" the current location onto the breadcrumb stack before sending the browser a redirect instruction to change the URL to that of the page that I want to go to.
That's as far as my brainstorming goes for the moment, because once we perform a redirect, we lose the ViewState. Rather than doing the redirect, I've thought of simply telling my main portal page to replace the current page control with the target page control, thus avoiding the extra http round-trip and allowing me to keep the ViewState. But then my entire website experience occurs in the context of a single URL, so I lose URL bookmarking among other things. And if I wrap some of my controls in AJAX panels, the entire site happens in one page request as far as the browser's history is concerned.
What I would like is some way to have the browsing history and URLs behave as if each link is leading them to a new page with a descriptive URL and all that, but still have some way to know the path that the user took to get to the page that they're on (ViewState seeming to be the simplest way to track this).
Could anyone suggest some techniques I might try using?
First suggestion... You may want to look into ASP.NET MVC. However, I have to admit to some ignorance here as I'm not sure that would really solve your problem. But it sounds like the sort of thing MVC would be suited for.
Second... it's possible to override the methods responsible for saving and loading ViewState. One of the things you can do, for instance, is push the ViewState into the Session rather than sending it down to the user and back up on postback. You could easily add some custom code here.
Third... I think you may want to rethink part of your design. The ViewState really serves one purpose: It recreates the state of the page as it existed when the page was rendered for the user. If you are moving to a different page, or a new set of controls, why would you need the ViewState at all? The ViewState itself is really just a hack to begin with... ASP.NET's way of maintaining state on top of a stateless system. (but that's a whole 'nother discussion) We have other methods of maintaining state... the primary mechanism being the Session object. Why not save your breaacrumb data there instead?
I would look at using cookies. For performance reasons, you really want to avoid HTTP redirects if you can, and ViewState only works if the user submits a form, not for regular links.
You might do something like maintain several path lists in cookies that show the path that the user took to go from one page to another. Maybe you set a unique ID with each page that is applied by some JavaScript as a query string when the user clicks on a link, and the server uses that ID and the past history from the cookies to determine how to render the bread crumb on the next page?