I am facing a minro issue, but a tricky one.
I have a DetailsView with Edit/Cancle/Update functions.
When the user click "Edit" make changes and Update, if there are validation problems, it will throw the errors of invalid data, and keep in edit mode. But then if the user click cancle, the DetailsView will be in ReadMode, and will show the incorrect value. I am not re-loading the BO from Database after cancel.
So, to solve this problem, I decided to use BO.BeginEdit() when DetailsView CommandName="Edit" and BO.CancelEdit() when DetailsView CommandName="Cancel", and before I can the "SaveObject()" from the UI, I do the following in code-behined:
If BO.IsValid() Then
BO.ApplyEdit()
End If
Session("BusinessObject") = BO.Save()
In general, it is working fine, but I will get a confusing error message "Object is still being edited and can not be saved" if there are broken validation rules.
And, if I change the above code as follows:
BO.ApplyEdit()
Session("BusinessObject") = BO.Save()
Then, BO.CancelEdits() will have no effect.
What is the proper way to implement a "Cancel" command in DetailsView in web application ? If I want to avoid re-loading the BO from Database after cancel ?
Tarek.
I found the solution.
Basically, I examined the sample code for using Undo features from the Book for Windows Forms, and followed the same way, but for Web Forms.
I think it is better to undo the changes made to the BO, after a failed save operation due to broken rules, instead of re-loading the complete values back from the Database, or force the user to navigate away completely from the Edit Mode of the DetailsView to a different screen.
If you have any feedback, do let me know.
Tarek.
For non-web apps it is almost always better to use undo than to reload the object.
In web apps that is not necessarily true. To use undo in a web app you usually have to use Session, which has a set of negative consequences. Reloading the object also has negative consequences. You just need to decide which negative consequences are least bad for you.
(which is why I find web development so frustrating - web development is just a continual series of choosing the lesser of two evils - I find it depressing...)
Thank you for the reply.
I was checking the PT Sample Application, the web part (Csla 2.x ProjectEdit.aspx), and I noticed that the method implemented after a failed save operation due to broken rules is to force either to input correct data and save, or to navigate back to the Project List view, which meas Reloading from DB.
I am not sure I understand what I will loose if I use Undo in web application, since I am already using a Session to cache the BO between screen post-backs.
The only thing I did is the following:
1. On click on Edit Command, I call BO.BeginEdit()
2. On click on Cancel Command, I call BO.CancelEdit()
3. On Click on Update Command, I do the following:
temp = BO.Clone() ' new
temp.ApplyEdits() ' new
Sesison("BO") = temp.save() ' same like before
I don't understand how is this method considered "not better" when compared to Windows Application.
Tarek.
If you are already using Session then the only cost you'll pay with n-level undo is that it will increase the size of your object in memory (since the object contains a snapshot of its previous state). If that isn't causing you problems on your web server, then there's no problem.
My response was in the broader context of "web purity", where people often try to avoid Session so they can achieve higher scaling and fault tolerance. If you don't need those things - or if you choose to get scaling via sticky IP web farms (and give up fault tolerance) then you have no problem either.
Copyright (c) Marimer LLC