 |
BOOK: ASP.NET 2.0 Instant Results ISBN: 978-0-471-74951-6
 | This is the forum to discuss the Wrox book ASP.NET 2.0 Instant Results by Imar Spaanjaars, Paul Wilton, Shawn Livermore; ISBN: 9780471749516 |
|
Welcome to the p2p.wrox.com Forums.
You are currently viewing the BOOK: ASP.NET 2.0 Instant Results ISBN: 978-0-471-74951-6 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
|
|
|
|
|

August 9th, 2007, 09:32 PM
|
|
Authorized User
|
|
Join Date: Aug 2007
Posts: 30
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Refresh the browser equals insert a new record!?
Recently,I was starting Micro Belinaso's ASP.NET 2.0 Website Programming - Problem-Design-Solution ,When I do with the News and Article Chapter ,I encounter a program . It was in the AddEditArticle.aspx Page, when I post a new article and sumit,it was just fine. But then I refresh the screen(the Browser),a strange thing happen:the article I just posted before was posted again!!!
I don't know why this were happen.I just know in the ManageCategories.aspx, When I do the same things above,nothing will happen,because the InsertCategory Store Procedure check whether a category with the same title has already exist before it really insert a category,the codes are shown as below:
Code:
CREATE PROCEDURE dbo.tbh_Articles_InsertCategory
(
@AddedDate datetime,
@AddedBy nvarchar(256),
@Title nvarchar(256),
@Importance int,
@Description nvarchar(4000),
@ImageUrl nvarchar(256),
@CategoryID int OUTPUT
)
AS
SET NOCOUNT ON
-- check whether a category with the same name already exists
DECLARE @CurrID int
SELECT @CurrID = CategoryID FROM tbh_Categories WHERE
LOWER(@Title) = LOWER(Title)
IF @CurrID IS NOT NULL
BEGIN
SET @CategoryID = -1
RETURN
END
INSERT INTO tbh_Categories
(AddedDate, AddedBy, Title, Importance, Description, ImageUrl)
VALUES (@AddedDate, @AddedBy, @Title, @Importance, @Description, @ImageUrl)
SET @CategoryID = scope_identity()
so when I do the same thing I mentioned above ,I just doing fine.
But I wonder why this happen and how I can avoid it.I am a ASP.NET beginner.
I know I should have posted this Topic in Micro Belinaso's ASP.NET 2.0 Website Programming - Problem-Design-Solution forum
(actually I did,but no one ever reply).And I know Imar is always active and patient to help others.So I posted it here.And I hope it wound't disturb anybody.
Eager for help.Thanks.
------------------------------------------------
We learn from the history that we do not learn from the history
__________________
------------------------------------------------------------------------
We learn from the history that we do not learn from the history
|
|

August 10th, 2007, 04:05 PM
|
 |
Wrox Author
|
|
Join Date: Jun 2003
Posts: 17,089
Thanks: 80
Thanked 1,576 Times in 1,552 Posts
|
|
I think it makes sense. Whenever you refresh a browser window, you're sending out the same data again.
Quick fix: do a Response.Redirect after you insert the record. That way, only the redirect page gets refreshed.
Slow fix: keep track of the records inserted, or the number of times the page has been loaded, and then skip the database call when appropriate.
BTW, instead of posting it in the Instant Results forum where it doesn't really belong, it's probably better to choose a more general ASP.NET related category instead here at p2p.wrox.com.
Hope this helps,
Imar
---------------------------------------
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Everyone is unique, except for me.
Author of ASP.NET 2.0 Instant Results and Beginning Dreamweaver MX / MX 2004
|
|

August 10th, 2007, 09:29 PM
|
|
Authorized User
|
|
Join Date: Aug 2007
Posts: 30
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Thanks Imar.I know you would't let me down .I forgot HTTP is a stateless protocol.It can not tell which request is new and which is old.But I am a little confuse with the concept. The ASP.NET can tell which request is postback,how can it do that.
And it also kept a session for every user.Doesn't that mean it has some states?
I am sorry for post this topic in your forum,which has nothing to do with the content of your excellent book.I like you books very much,and I am very appreciate for your kindness to help other's problems.Could you tell me which forum you comes frequently,so that I can post my topic there to ask for your help.Thanks again.
------------------------------------------------------------------------
We learn from the history that we do not learn from the history
|
|

August 10th, 2007, 09:52 PM
|
|
Wrox Author
|
|
Join Date: Oct 2005
Posts: 4,104
Thanks: 1
Thanked 64 Times in 64 Posts
|
|
Peter (planoie), Imar, Gonazalo (gbianchi), and myself post pretty much all over the ASP.NET boards which can be found here: http://p2p.wrox.com/asp-net-asp-12
In so far as your second question goes, the concept of Session is, more or less, a work around to the stateless nature of HTTP and it is achieved through multiple different methods all of which can be found here:
http://msdn2.microsoft.com/en-us/library/ms972429.aspx
By default your application is using the In Process (InProc) session state management (unless you explicitly changed it in the web.config) which means that when X user makes a request to your website, a session cookie is given to your browser that stores the session ID for that user and it is through the existance of this cookie that the server is able to know which session belongs to which user.
hth.
================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
================================================== =========
Technical Editor for:
Professional Search Engine Optimization with ASP.NET
Professional IIS 7 and ASP.NET Integrated Programming
================================================== =========
|
|

August 10th, 2007, 10:45 PM
|
|
Authorized User
|
|
Join Date: Aug 2007
Posts: 30
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
quote:
Cookieless State
The last new feature that we can configure for ASP.NET session state is cookieless session state. Essentially this feature allows sites whose clients choose not to use cookies to take advantage of ASP.NET session state.
This is done by modifying the URL with an ID that uniquely identifies the session:
http://localhost/(lit3py55t21z5v55vlm25s55)/Application/SessionState.aspx
ASP.NET will modify relative links found within the page and embed this ID. Thus,
as long as the user follows the path of links the site provides, session state can be
maintained. However, if the end user re-writes the URL, the session state instance
will most likely be lost.
|
Where this ID comes from?If it is the user manually type the ID,how can the server
identity it,and what about two users type the same ID? If it is the server generates
it,how can the user knows this ID?
Thanks for your reply.
------------------------------------------------------------------------
We learn from the history that we do not learn from the history
|
|

August 11th, 2007, 03:09 AM
|
 |
Wrox Author
|
|
Join Date: Jun 2003
Posts: 17,089
Thanks: 80
Thanked 1,576 Times in 1,552 Posts
|
|
No, the server generates an ID automatically, which is then assigned to the user as a cookie (or embedded in the URL).
ASP.NET knows when a page has been posted back by looking at form fields (__VIEWSTATE).
When the page first loads, the form fields are empty. When the page is submitted back, the hidden form fields contain a value so it must be a result of a postback.
This trick is not really new to ASP.NET. I used similar tricks in ASP to detect postbacks, although we didn't call it post backs back then...
Imar
---------------------------------------
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Everyone is unique, except for me.
Author of ASP.NET 2.0 Instant Results and Beginning Dreamweaver MX / MX 2004
|
|

August 11th, 2007, 08:04 AM
|
|
Authorized User
|
|
Join Date: Aug 2007
Posts: 30
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
quote:
ASP.NET knows when a page has been posted back by looking at form fields (__VIEWSTATE).
When the page first loads, the form fields are empty. When the page is submitted back, the hidden form fields
contain
a value so it must be a result of a postback.
|
As to the __VIEWSTATE,I am not quite clear about it.
That's,does the __VIEWSTATE contains the user's post back data.Or just the data the server send to it,
that is the data it received from the server.
To make my question more concrete,let me take a example:
consider a ASP.NET UserControl with only a TextBox and Button server controls.
Code:
public class TestControl : UserControl
{
public string UserName
{
get{ return txtUserName.Text;}
set{ txtUserName.Text=value;}
}
protected void btnSumit_Click(object sender, EventArgs e)
{
Reponse.Write("Hello,"+UserName);
}
}
<asp:TextBox runat="server" id="txtUserName" />
<asp:Button runat="server" id="btnSumit" />
But actually the ASP.NET will do this things for us:
it first check whether the ViewState collection of the TestControl
has some value(if it is post back ,it should have),and load from it,
otherwise it give the default value to its property,which for a TextBox
is null:
public string Username
{
get
{
return ViewState["txtUserName"]!=null ?
(string)ViewState["txtUserName"] : null;
}
set
{
ViewState["txtUserName"]=value;
}
}
it also set a flag HasUserNameChanged to indicate whether the property
value is changed during the postback:
public bool HasUserNameChanged;
when the user clicks the Submit button and posts the page back to the server, the page
calls the LoadPostData method of the TestControl control and passes a NameValueCollection
collection into it. This collection contains a name/value pair for each form HTML element where the
name contains the value of the name attributes of the element and value contains the value that the
element has posted back to the server. In other words, this collection contains one name/value pairs
associated with the one form elements that the TestControl contains, the UserName for the txtUserName
text fields.
protected virtual bool LoadPostData(string postDataKey,NameValueCollection values)
{
string username=values[UserNameTextInputName] ;
if(username !=UserName)
{
UserName=username;
hasUserNameChanged=true;
}
return hasUserNameChanged;
}
where the UserNameTextInputName is something like:
protected virtual string UserNameTextInputName
{
get { return "UserName"; }
}
Just to identity it from the post back data Name/Value collections
From these code we can see that the LoadPostData method assigns the retrieved values to
these properties only if the new values are different from the old values of these
properties. This is only possible if these properties can maintain their values across
page postbacks,which means that they must use the ViewState collection of the TestControls
as their backing stores,just as list above:
public string Username
{
get
{
return ViewState["txtUserName"]!=null ?
(string)ViewState["txtUserName"] : null;
}
set
{
ViewState["txtUserName"]=value;
}
}
Then it will come to the Raise Post Data Changed Event (postback only),
and finaly to the Raise Postback Event (postback only):
in our example,the btnSumit_Click event ,whick just print a welcome.
What I want to ask is , What's the different between ViewState and Postback data,
It seems that the Postback data contains all the data the page need to main its
state,and get the user's input data.
Consider another situation:
I have two TextBox , the user input "Magi" in one of them,and remain the other
unchanged,(let's say,there old value are "aaa" and "Imar" respectively),then Click
the sumit button.In this way,What's in the postback data's name/value collection,
and what is in the viewstate.
Will it be like this:
the postback data is "Magi",(since it changed)
and the ViewState is "aaa && Imar"?(the old value)
or postback data is "Magi && Imar",(since they in the same form)
and the ViewState is "aaa && Imar"?
------------------------------------------------------------------------
We learn from the history that we do not learn from the history
|
|

August 11th, 2007, 08:17 AM
|
 |
Wrox Author
|
|
Join Date: Jun 2003
Posts: 17,089
Thanks: 80
Thanked 1,576 Times in 1,552 Posts
|
|
ViewState contains data about the page when it renders. It's what makes events like TextChanged possible in .NET (and a whole lot more).
So for example, when you do this:
txtUserName.Text = "SomeValue";
the Text property is stored in ViewState.
When the page has done loading, this value is thus stored in the __VIEWSTATE field.
Then when the user changes the client side text box and submits the form, a few things happen. The new data is sent as form data / post data in the request for the new page.
ASP.NET now has access to two values: the old one in ViewState and the new one in the form data / post data.
This way, ASP.NET can trigger events like TextChanged because it can see the text has changed by the client.
This is just an example, and there's a lot more to it (besides ViewState you also have ControlState that you cannot turn off and that controls use to keep state like a current page index) but I hope it gives you some idea.
If I understand your examples correctly; it's probably the latter. E.g. the form contains both values, so the browser (who doesn't know a thing about ASP.NET) simply submits both fields to the server.
Depending on ViewState settings (App level, page level or control level settings can turn ViewState on or off) the two original values are stored in ViewState.
Imar
---------------------------------------
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Everyone is unique, except for me.
Author of ASP.NET 2.0 Instant Results and Beginning Dreamweaver MX / MX 2004
|
|

August 11th, 2007, 09:42 AM
|
|
Authorized User
|
|
Join Date: Aug 2007
Posts: 30
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Thanks a lot for your patient to see my long code and example.
Thanks to you explaination,Now I have some idea about ViewState and PostbackData.
That is,the postbackData actually contain all the value of the form,because it is
sent by the browse which knows nothing about the server side,and does't know anything
(and not care )about which field's value has changed by the user and which is not.
It just send out all the field's value it contains,which is contained in the postback data
name/value collection. right?
But as to the viewstate,it just contain the value the browser receive from the
server,that is ,as to the server,the value after it render the page and
send the render HTML page to the request user.
I once wonder that why the viewState is needed.Because the postback data contains
all the data,both old and new.Now I think understand,It is for the server to know
which field has changed by the user so that it can raise the PostDataChanged event,
to handler the postdata.
Hope I really catch this concept.
Thanks again.
------------------------------------------------------------------------
We learn from the history that we do not learn from the history
|
|

August 11th, 2007, 09:51 AM
|
 |
Wrox Author
|
|
Join Date: Jun 2003
Posts: 17,089
Thanks: 80
Thanked 1,576 Times in 1,552 Posts
|
|
Yeah, that covers most of it.
However, there are a few minor remarks.
Technically, ViewState can be considered part of the postback data. Again, the browser knows nothing about ASP.NET, so it sends the hidden __VIEWSTATE field in each postback, together with the other data.
My *Changed event was just an example. There are many others uses for ViewState. Consider a label: it gets rendered in the browser as a <span> element so it doesn't use a form control. However, when you set the Label's Text property, it will survive postbacks because it uses ViewState as the backing store for the text.
Same goes with other data: page indices with paging, sort expressions and directions when sorting data and a lot more can be stored in ViewState, including the stuff you add yourself.
Hope this clarifies things.
Imar
---------------------------------------
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Everyone is unique, except for me.
Author of ASP.NET 2.0 Instant Results and Beginning Dreamweaver MX / MX 2004
|
|
 |