FormView viewstate always gets lost - why?

G

Guest

I asked this question earlier, but unfortunately the two replies I got did
not solve the problem. Here it is again, but now with the code:

After an Update my FormView always loses its viewstate values. The field
values in the FormView are always overwritten by the results of the Update
method in the business layer. No matter what I do, the databind always takes
place, even when I don't want it to.

See the example below. This is a simple form, with just one button and one
textbox. The value that I type in the textbox gets lost after I click on the
Update button. In this example, the business layer Update method consists of
only line of code. It refuses to save the new data because it decides that it
is not valid. The Update method returns -1 (or it can throw an exception,
that doesn't really matter). Afterwards I want the textbox to keep the value
that it contained before the update. But it doesn't. A new databind is
performed and the original data is fetched from the database using the
SelectOne method. How can I prevent this from happening?

The code-behind does not contain any code in this example. I tried
intervening with just about every event that the formview and datasource
controls have. With no results. (I got the suggestion to cancel the
ModeChanging event, but that did not work, and I'm not even changing modes
here.)

<%@ Page Language="VB" AutoEventWireup="false" CodeFile="Employee3.aspx.vb"
Inherits="Organization_Employee3" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Untitled Page</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:FormView ID="EmployeeFormView" DataSourceID="EmployeeData"
runat="server"
DataKeyNames="OrganizationEmployeeID" DefaultMode="Edit" >
<EditItemTemplate>
<asp:LinkButton ID="UpdateButton" runat="server"
Text="Update" CommandName="Update" />
<asp:TextBox ID="FirstName" runat="server" Text='<%#
Bind("FirstName") %>' />
</EditItemTemplate>
</asp:FormView>
<asp:ObjectDataSource ID="EmployeeData" runat="server"
TypeName="Ism.Prisma.Business.Organization.EmployeeManager"
SelectMethod="SelectOne"
UpdateMethod="UpdateTest" >
<SelectParameters>
<asp:QueryStringParameter Name="organizationEmployeeID"
QueryStringField="OrganizationEmployeeID" />
</SelectParameters>
</asp:ObjectDataSource>
</div>
</form>
</body>
</html>


Public Shared Function UpdateTest(ByVal organizationEmployeeID As
Integer, _
ByVal firstName As String) As Integer

Return -1

End Function
 
G

Guest

The behaviour you describe is expected, sureley the problem is not that the
formview will not keep it's viewstate data, but that you are not validating
the data entered into the textbox, so that it is valid for the datasource.
Once you only allow valid data, your problem goes away because the textbox
will re-bind to the valid data it has just updated the underlying data source
with. I can't understand why you would want the formview to remember the
invalid value that just caused an exception/error.
 
G

Guest

The behaviour you describe is expected, sureley the problem is not that the
formview will not keep it's viewstate data, but that you are not validating
the data entered into the textbox, so that it is valid for the datasource.
Once you only allow valid data, your problem goes away because the textbox
will re-bind to the valid data it has just updated the underlying data source
with.

In my opinion it is up to the business layer to decide whether data supplied
by the user interface is valid. For example: the user interface cannot verify
whether a unique code is really unique. The BLL should verify that.

Of course it would be possible to do a separate call into the BLL to ask if
proposed data is valid, and then afterwards do a second call to Update. But I
think that is an ugly solution. And besides, suppose the user interface
programmer forgets to verify the data? The Update method should still enforce
business logic before persisting the data and deny any attempts to save
incorrect data.

I really don't understand why I cannot change the current behavior. It it is
indeed by design it is a flawed design, IMHO.
I can't understand why you would want the formview to remember the
invalid value that just caused an exception/error.

The user should be enable to change the data when it is invalid. It is bad
GUI design to force him to re-enter all information, including the values
that were correct but did not get saved to the database.
 
C

Christopher Reed

I believe that by using the CommandName in your LinkButton and setting it to
"Update", you are triggering a default reaction to the FormView that will
attempt to update your database and then databind the "new" results, which
would mean that the old data will appear if the update fails. Thus, you
need to programmatically control the update which will then require you to
directly databind the data yourself meaning that if the data is invalid, you
would skip the databinding.

I'm still coming up to speed on the FormView control myself, so there are a
lot of things to discover under the hood.
 
Joined
Mar 14, 2007
Messages
1
Reaction score
0
This is what I do, I have a boolean in SQLDataSource inserted even, if exception thrown I set saveSuccesfull = false, then in FormView ItemInserted event I have this.


Protected Sub FormView1_ItemInserted(....

'show back user's original (invalid) data if saved failed for some reason

If Not saveSuccesfull Then
e.KeepInInsertMode = True
End If

End Sub


http://rosdi.name
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,968
Messages
2,570,152
Members
46,697
Latest member
AugustNabo

Latest Threads

Top