I have a master page where I'm loading some data into the session.
I put the lines of code that call my queries in the Page_Init event of the master page, inside an if statement
if (!Page.IsPostBack){ load data from queries into the session }
Is this what I need for all the session data to be loaded only once per session. What about call backs? Do I also need to check to avoid a reload of session data on call backs? Any other condition I need to check to avoid unnecessary reloads of session data? I'm looking to run the queries inside the condition statement only once.
Thanks.
No. What you just posted won't guarantee that will be called once per session. In fact, every time your ASPX page is invoked with a GET command, the data will be loaded.
If you want data to be loaded just once by HTTP session (I am assuming by session you mean HTTP session) then try Session_OnStart event handler.
You can check to see if the session variable is null. If it is null then load the data. If it is not null then do nothing.
As Pablo Santa Cruz suggests, the best place to load the session variable is in the Sessio_OnStart event handler but a quick and dirty way is to simply check for the sessions existence in the Page_Init event.
Related
I have several ASP.NET pages that store an object in the session and use it for data binding etc. The object in the session is referenced in several pages of a 'wizard'.
I want users to be able to have several tabs open and work on several different objects stored in the session at the same time.
I am using a URL param to do this, where the param is incremented each time the page is hit, i.e:
http://server/MyPage.aspx?action=1
http://server/MyPage.aspx?action=2
And my session access is simply
return (MyObject) Session["MyObject" + Request.Params["action_id"]]
This is fine, but it doens't work for object data sources when they are data bound - the error is "Request is not available in this context"
How can I get an ID that I can retrieve on the server side reliably in callbacks and page loads? The ViewState doesn't seem to be available in
Ah, the trick is to use
System.Web.HttpContext.Current.Request
Is there a way to save the querystring ids after the page load? the reason why i am looking is that ...i should be back and forth with pages and more importantly if the user try to manupluate the ids then it should not effect the result of my page since i will be reading the Ids not from querystring but from some save prop or something like that.
for an example: let says the page loads very first time... i have this url:
http://www.somesite.com/Shop/Product/Detail.aspx?ProductId=100
and if the user try to modify the querystirng and re-load the page then the page_load should not read from querystring rather from saved prop or something???
In your page load event look at the Page.IsPostBack property. It is false when a page is first loaded. You should validate your parameters then and perhaps save them to session or viewstate.
If Page.IsPostback = false Then
'Validate Request("ProductID") here
'Save in viewstate or session state
Else
'Retrieve ProductID from viewstate or session state
End If
If a user changes the query string, you should consider it a new page load.
This would not work since it's against the very basic nature of Internet. Internet is stateless.
Everytime user changes the querystring, it will be treated as a new Url, storing the parameters will be of no use. Page.IsPostback won't work either since every Url change will be a first hit.
Saying that, you can still work around it,
With every Url, you can pass a unique identifier (like a GUID.)
As soon as page hits, you can save parameters in session and work with them and use the Guid to map the two requests.
But the problem remains here, if the user changes that Guid then again it will be treated as a new request. You can go one step ahead and start saving that GUID to make sure that only system generated GUIDs are handled but overall it will just make your system complex.
My guess is that you might be looking at a wrong solution for your problem. If you can share your actual aim then we might be able to recommend you something more tangible.
You can not stop users from editing querystring values and trying to see content of another page or execute something. what you can do is you can check in the page load that this user has sufficient permission to access this page.
Ex : www.mysite.com/editproduct.aspx?productid=4
In editproduct.aspx, you have to check whether the product 4 has access by the current user who is accessing the page.( May he should be the creator/ he should be in a specific power users group etc... depending upon your scenario). If he has access, show the edit form to the user, else hide it and show a message saying "you are not authorized to access this resource."
There is no way; however, you can use session to validate when the Page_load is called.
If ( Page.isPostBack = true ) {
Session("SAVE") = false;
}
For a while in the before the Request.Querystring statement, you validate the 'save' session state.
I need to pass a Infragistics ultrawebtree from a page to another. I used Session("data") for this and then I just access it from another page. But when I assign the session value after casting to a Infragistics ultrawebtree control in my second page, it doesnot build the tree structure and it is invisibile. Is I am wroung in this approach, is there any other way to pass the entire tree structure from one page and display it into another page. Any help is appreciated
If anything, I would store the datasource in session instead of the tree. Storing the entire control in session creates a lot of unnecessary overhead, and limits your options per implementation on the next page.
EDIT: You should be able to export the tree structure to XML format, and store the XML in session. According to the documentation there should be WriteXmlDoc() and WriteXmlString() functions available. There's also ReadXmlDoc() and ReadXmlString() functions you can use to repopulate the tree on the next page.
Here's the documentation for the UltraWebTree. You'll see these methods under the Public Methods section:
Only the data should be stored in session. Storing controls in session is likely to cause issues because the control will be disposed during page unload and controls shouldn't be accessed after being disposed which is what would happen when accessing the control from session. See Why Controls Shouldn't be Stored in Session for more details.
I have spend a lot of time on this problem without any change :
I have got 2 simples apsx page, in the first page the
Page_Load event put data in the session ;
later the on_click event of a button fire an HttpWebRequest to the second
page
with the idea to retrieve on the page_load of the second page the data in
the session.
to sum up : 1st page put data in session, make the httpWebRequest to the 2nd
page
2nd page : try to get the stored data in the session.
This is the different attempt of code i 've tested to perform this action,
the result was always the same. When i try to add sessionId Information (via
a cookieContainer or directly in the Header request) i get a timeout exception
System.Net.HttpWebRequest.GetResponse() and when i do the HttpWebrequest
without the session_id information i get the response immediatly but without
the session info :-)
It's not clear what you're trying to do, but have you considered using Server.Execute instead?
http://www.west-wind.com/weblog/posts/2004/Jun/08/Capturing-Output-from-ASPNet-Pages
I have a composite control that has a couple of private fields that reference values in the cache and these private fields are called during the constructor method. Since a string key is used to identify the value in the cache, I must have a way of storing that string key in such a way that it is available at the time the control is instantiated, and I have to be able to reference it on postbacks without it changing.
In addition, this key is generated the first time the control is loaded, but it should not be changed again after that first time.
How can I accomplish this?
I have already tried saving it to viewstate, but that doesn't work because viewstate is not yet available at the time the control is instantiated.
I have tried using a private field and then checking against Page.IsPostback in the constructor and if it isn't postback, I assign a value to the private field, but on subsequent postbacks it looses it's value, and I can't reassign it in the Page.IsPostBack again because it is an autogenerated GUID.
This has got to be something folks have had to do before....
There isn't a lot of state info available during control construction at all, so this could be difficult. Is there some reason you can't move your code which accesses the Cache'ed info into the control's Init event?
I assume you can't use Session because the information stored is related to that specific request/postback. If it's not specific to that request, using Session could be a possibility - but I think you may encounter other problems trying to deal with control state so early in the lifetime.
After seeing your comment to the other answer; you should be able to move your code that checks for the cached datasource into the control's Init or even Load event, so the state will be available.
Also, incidentally; are you sure you really need to cache this data? That could end up taking up a lot of server memory.
Have you tried Session?
You can store anything you like in the session object for one particular user, maintaining the value / object between postbacks.
If you want to store on a global basis and not per ser basis, try Application
Although this isn't the best solution (rearranging your logic to fit the lifecycle model generally is), have you tried accessing the Request directly? I once really wanted to get the selected value off a DropDownList very early in the lifecycle so I could adjust some elements in the building, and I did it like this:
myDropDownList.SelectedValue = Page.Request.Form[myDropDownList.UniqueID];
So instead of waiting for the viewstate to load the server-side proxie's values, I just got it myself from the client-side control value that was passed in on the post. I probably would do things differently if I redesigned that page, but it seems to have worked out alright for now and it solved the problem I was having.