ASP.NET Web Applications - Part Two
Posted By Robin Freeman | last update 06-Feb 2011
Musings from the basement of a very tall building
Apologies to the reader who follows these blogs for my apparent death. I am involved in a project that is driving me to distraction and this blog fell off my radar. The heart of the problem is that NHS data seems to consist of chess pieces. Yes each data piece does its own thing, but the pieces can't be joined together. We need these pieces to be jigsaw pieces where there are surfaces along which the datasets can be joined. The tall building managers are looking at integration engines for data management. These are begining to appear on the market and have price tags in millions. I begin to think they aren't expensive enough, as a very hefty price indeed will need to inspire the NHS to rethink and organise its data dictionary into a whole.
I digress. Last time we managed to use an aspx page to send data back to itself without actually using any active server code. If you open the tool box in visual studio you will find all manner of 'asp controls' with which you can beautify your web page. As the page is sent from the web server to the client the asp engine changes these into html and so all is made good. As you begin these controls can be useful. If you progress you will probably find they don't offer enough control and so will use the html equivalents.
We need to do something with the data returned to the web server when the aspx page is submitted, so open the webform1.aspx.cs file, the 'code behind' file. This has a set of using's which are the c like pointers to library files your code will use, the default usings are enough to get you started. Then there is a namespace term. A difficult concept in which this term is used to seperate the name you make up for a type, from the same name for almost certainly a different type in a different namespace. Okey dokey then. Finally you get the class (or type) that is this code behind and within it, the page load type. Now the asp engine deals with the html/asp on the aspx page, then runs the code in the page load type.
The problem you have already found is the page is loaded as new be it a new request, or be it the case that it has posted itself back to itself. The system can tell the latter situation because the __viewstate posted back contains state information, as well as an encoded version of the page. Thus your page load event should contain; if(Page.IsPostBack == true){}, the code to run during a post back being between the curly braces. Because our form has no information at start up we don't have to write any code for a new page request (which would then be in else{}); we will consider this in another blog. We are going to retrieve the data we want from the http post with string strHRID = Request.Form["txtHRID"], etc. The name value pairs in the post are placed in an array by the asp engine, hence the square brackets containing each name to access each value. You will find this piece of magic has now given you the data entered on the web page in string types named by you. Anything allowed by C Sharp can now be done to this data, which as Darth will tell you, is more than you can possibly imagine.
Of course back on earth you are going to validate the data and if valid, save it in a database
The downside to __viewstate. Well as it contains an encrypted version of the page, it can be as long as the html within the page and can slow the page down. Happily if your page isn't going to be used for clever post backs it can be switched off in page properties.