What does VaryByParam do on an asp.net directive? I have tried looking on the web, but can't actually understand what it does.
Thanks
Please see OutputCacheParameters.VaryByParam:
Gets a comma-delimited list of query
string or form POST parameters that
the output cache uses to vary the
cache entry.
Basically what this means is that the output caching of a given page will use certain values to determine which cache should be returned since a dynamic page may have different redered representations of itself.
Those different representations tend to be driven by user-provided data and this property allows you to configure which values from the query string or a POST payload will control that.
Related
I want to use viewstate variable's value which is saved in one page on another page. But while doing so it shows NullReferenceException. I am new to ASP.net. Please Help me out.
in register.aspx
ViewState("name")=textbox1.text
in success.aspx
dim a as string
a=ViewState("name").toString
Use Session["name"] = textbox1.text...
If I am not mistaken, you don't have direct control or should have direct control over viewstate.
ViewState is the technique to persist state across postbacks and is lost when you load another page. therefore you will need to use another way to send the data to the next page. Read up more here on MSDN
The common choices for sending data across pages include:
QueryString
By setting up the previous page property
Session variables
ViewState is restricted to a page, so it cannot be used on another page. The reason is that ViewState is serialized in the page output in a hidden field that is transferred to the client and back to the server upon a postback.
If you want to transfer data to another pages you have several other alternatives:
As #AnastacioGianareas also pointed out, Session memory is one of them. It is located on the server, but sessions will expire after a certain time of user inactivity. Being located on the server, it reduces application scalability if you have many users and lots of memory allocated in the session.
Hand over the data as a query string parameter to the other page, e.g. redirecting to "Success.aspx?name=". This will work for smaller amounts of data that you can put into the query string (e.g. ids or names). It is important that a client can also request Success.aspx with that query string parameter, so it should be reserved for uncritical data and be validated carefully.
Use a cookie to transfer it to the client and back again.
This link gives a good overview of the alternatives.
From MSDN:
View state is the method that the ASP.NET page framework uses by
default to preserve page and control values between round trips. When
the HTML for the page is rendered, the current state of the page and
values that need to be retained during postback are serialized into
base64-encoded strings and output in the view state hidden field or
fields.
Options to persist data between pages are varied and depend upon your requirements, this page on MSDN describes each of these options and the considerations you should make.
For your requirement either QueryStrings, SessionState seem like the best solution.
As a side note, always validate your 'State' variables (regardless of which method you chose) to ensure that they aren't null and are of the expected type. i.e. all these values will be stored as Strings, if you are going to use a variable as another type (an int, double etc) you should make sure this is valid. Also, should you go down the querystring route, take into account any security considerations as users may / will modify these values.
I've been developing classic ASP pages at the job for the past five years and now we are moving to ASP.NET. I'm trying to understand how to get form field values from one page to another and it seems like there is more than one way to do it. In classic ASPI just called request.form collection and got the information. Which way is recommended in .net? Cross Page, Transfer, or HttpRequest?
Gracias.
It actually depends because I don't always use any particular method. Sometime it is easy to expose as property or sometimes just server.tranfer is fine or sometimes as querystring.
If data is sensitive and/or to many itmes I use Session where you can store an class object of custom type as well and not just basic data type.
And in certain cases I store stuff in DB and just pass an id to the record to next page via querystring or session and retrieve everything I want from DB.
Here is reference to different types available.
When creating search forms in web pages, I generally use the GET method. This allow the results to be URI Addressable. It also makes for easy pagination of results in the standard manner.
But what about a form with a large number of options and fairly long field names? Using a GET request means that the URL of the results page can actually crack the practical URL length limit of 2KB.
If I change to using POST, I beat the URL length limit. But then I lose the URI addressability. Also, all pagination links need to be reimplemented as little subforms with all the search parameter data stored in hidden fields; making these operate as links would then require something like onclick handlers, which makes them usable only when client-side scripting is enabled.
So, what is the advice for long search forms that:
maintain URI addressability
allow reasonable pagination links
don't break a practical URL 2KB length limit
The only thing I'm coming up with is sticking with GET, but reducing the lengths of the field names so that we are less likely to bust the URL limit.
Whaddya think? Many thanks in advance.
What you need to do is use the post method - you can't get around this if your URL is going to be over the limit (although you can delay the inevitable by abbreviating names and values).
Take the post and then redirect the client to a get, to keep things addressable you can either store the search server side against a key and retrieve it on the get (e.g. from memory or a database), or you could encode the keys into a single querystring key or a smaller number of keys which capture the behaviour. The resulting response will be bookmarkable etc.
Pagination is easy enough - just look for the presence or absence of the navigation buttons in the form collection and respond accordingly.
Which is the best way (in performance and security) to send multiple parameters to a web page (on a different server), considering that the length of the parameters may vary because I'm sending a list of products, and the customer may have selected more than one product, so we need to send each product on the querystring to the other page.
For example (I'm on C#); I want to call a web page like this:
Simple Querystring: thepage.asp?Product=1&Name=Coffee&Value=1.99
Json: thepage.asp?{"Product":"1","Name":"Coffee","Value":"1.99"}
XML: thepage.aps?<xml><Products><product>1</product><name>Coffee</name><Value>1.99</Value></Products>
(Obviouly considering we can't send special characters via querystring, but I put them here for better understanding)
Which will be the better way (performance, security)?
Thanks in advance.
Based on your comment, you're limited to what the third-party site will accept - if all it will handle is query-strings, that's how you'll have to send it. If it will handle form posts, then you could look at submitting the information in the headers of a post, but that is going to take more work (you also haven't specified if you're building a WebRequest on the server side, or doing this through JavaScript on the client side).
All things considered, here are some general points:
There are various limits on the length of a query string (IE limits them to about 2083 characters, some servers or proxies may ignore parts over 1024 characters etc), while POST requests can be much larger.
If you are doing this client side, the user can see the query string parameters (which has the benefit that they can book mark them), while they can't (easily) see POST requests.
For greater security, if the third party server supports it, submit the request over SSL.
Special characters can easily be sent via the query string if you UrlEncode them first.
As to performance, it depends on the amount of processing you have to do to create the query strings over creating XML or JSON strings.
I would use the simple querystring approach, which you could write a utility to convert the request.querystring collection into a format that works better for you (XML, JSON, Dictionary, etc.), IMHO.
HTH.
You need to keep in mind that there is a limit to how long your query string can be, depending on which browser your users use. IE6 has a limit of 2053 characters for example. I would suggest you come up with a method to keep your query string as short as possible to avoid hitting this limit.
As far as security goes, there really isn't any security if you are passing around information in a query string. Anyone can modify that information and then send it. If security is a major concern, you should look into encrypting the information before adding it to the query string, or find a different method for sending it altogether.
Come on what is the question asked ? which is the better way . no one answer proper here. all are telling about limitations. but not about the remedy to solve it . let say i want to pass 100 parameters generates dynamically all are in huge length , can i use here POST() then? I don't thinks so, just consider, what should the remedy then?? may be pass collection object as parameter.
I have form that displays several keywords (standard set of choice lists that changes rarely). There are about 4 such fields and each have about 20 choices or so.
I'm thinking if caching the keywords will be helpful for performance / best practice? Is there a strategy for determining when to cache?
To start, you ought to look at the cost for those keywords.
Are you querying them from the database, each one individually?
Are you querying them as a group?
Are they constants that you're simply writing out?
In general when optimizing (IE caching) look for items that are going to return the most bang for your buck.
Also look at the old 80-20 rule; ~80 items of data are a small drop in the bucket, whereas a list of 800,000 items is worth looking at.
You could use the ASP.NET Output Cache in your Page Directive.
<%# OutputCache Duration="60" VaryByParam="Keyword" %>
This will create a server-side cache of the page for each Keyword GET/POST request, and each cache will last 1 minute.
So if someone visits my-page.aspx?Keyword=Cards asp.net will render the page and save it in memory as HTML for 60 seconds. If someone visits my-page.aspx?Keyword=Books it will create a separate version of the page in HTML and cache it as well.
Use a lazy initialized singeton with appropriate field to store your data. eg of this singleton at
http://www.yoda.arachsys.com/csharp/singleton.html
You can have the property to be of type
"IDictionary<string, IList<string>"
if you want them organised by Category and iterable by keyword.
You can use
"IDIctionary<string, IDictionary<string, string>"
IDIctionary
if you want to be search able by category and keyword. If I read your question correctly, this would be an appropriate choice for you