|
|||||||
| .NET Discussion and technical support for, building, using and deploying .NET sites. |
![]() |
|
|
Thread Tools | Search this Thread | Rate Thread | Display Modes |
|
#1
|
|||
|
|||
|
I need a recommendation on how to do the validation in this case without postback
Hi Every 1,
I have a Create/Delete Users and Roles aspx form with C#. I want the form to validate whether the user had any opened tickets in the past before deleting that user. If the user has any opened tickets then the deletion is not permitted. I want client side validation for this purpose without postback. Just to update you on this, my form will get the user opened tickets information from SQL SERVER Database (I know how to do this.). I need a recommendation on how to do the validation in this case without postback(I want the form to validate whether the user had any opened tickets in the past before deleting that user. I want client side validation for this purpose). Thanks |
|
#2
|
||||
|
||||
|
Question: Have they logged on somewhere earlier? Is their identity being carried throughout as a session variable?
It sounds like you are also delivering, or have compiled, a list of open tickets when the form is presented. If they do have open tickets, set a boolean session variable (token) that can be used instantiate a local script variable which in turn is used to disallow user deletion. This part could be done by either dynamically disallowing the deletion function using vbscript or javascript via an onSubmit="return <some fx name>()". If the onSubmit fx returns false, then deletion can be blocked by not processing the form and notifying the user why deletion is not permitted at this time. Alternatively, if you have the token at the beginning of form generation, why not use it to prevent the functionality or function trigger (button or selection) for deletion from being presented at all.
__________________
javawebdog Two things to remember: "The only place success comes before work is in the dictionary." "It's more than just a matter of survival. It's a matter of sympathy, compassion, passion and style." Last edited by javawebdog; 11-03-2009 at 07:04 PM. |
|
#3
|
|||
|
|||
|
No need to store it on the sessions as you don't need to pass it across pages much more to the server. Still using sessions or viewstates really depends on how you'll use it or you can just use any public variable.
Code Behind: Code:
protected Boolean MyLockedToken { get; set; } // Or utilize viewstate
protected void Page_Load(object sender, EventArgs e)
{
if(!IsPostBack)
YourMethods();
}
protected void YourMethods()
{
MyLockedToken = true;
}
Code:
function MyValidate(){
if(<%= MyLockedToken %>)
blah_blah();
}
|
|
#4
|
||||
|
||||
|
The reason I chose session variable (you're right you could use a page variable as easily) was in case the original inquiry to get the information was on one page and the form was being delivered on a second page. And if denying a user some functionality it may be needed later on yet another page (some sort of advisory notice). Since the choice of the session var is a boolean the expense is very low.
You know the old saw, 'Better to have and not need it, then need and not have it.'
__________________
javawebdog Two things to remember: "The only place success comes before work is in the dictionary." "It's more than just a matter of survival. It's a matter of sympathy, compassion, passion and style." |
|
#5
|
|||
|
|||
|
Fair enough. Either way the implementation should be just similar to what I posted earlier.
Code:
private Boolean _MyLockedToken;
protected Boolean MyLockedToken
{
get
{
if(_MyLockedToken == null)
{
try
{
_MyLockedToken = (Boolean) Session[SESSION_KEY];
}
catch(Exception exc)
{
// Your exception handling
}
}
return _MyLockedToken;
}
set
{
Session[SESSION_KEY] = value;
_MyLockedToken = value;
}
}
|
![]() |
| Bookmarks |
| Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|