New Posts New Posts RSS Feed: Can Verifiers be Asynchronous?
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Can Verifiers be Asynchronous?
 Post Reply Post Reply Page  12>
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
mjwolfe View Drop Down
Newbie
Newbie
Avatar

Joined: 28-Oct-2009
Location: CA
Posts: 3 		Post Options Post Options   Quote mjwolfe Quote  Post ReplyReply Direct Link To This Post Topic: Can Verifiers be Asynchronous?
    Posted: 12-Nov-2010 at 2:51pm
Does the DevForce 2010 Verification Engine support one of my verifiers executing code that will cause a request to the server that would use a callback when the server-side call returns?
 
The purpose for this would be to get a stored procedure to run that can determine the validity of an instance of my entity based on an operation against a bunch of data in the database. It's too much data to bring it all client-side, but I don't want to wait to fail the save on the server to give the user feedback that I could have told them while they were entering the data on the client.
 
If it's not supported directly, could I implement my own class that holds the results of asynchronous verifiers returned from the server, and then have the callback re-fire the verifier on the associated property and have this new execution of the verifier pick up the results of the previous asynchronous execution to return this time instead of executing the asynchronous method a second time?
 
Thanks.
 
Back to Top
ting View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 27-Mar-2009
Location: San Francisco
Posts: 427 		Post Options Post Options   Quote ting Quote  Post ReplyReply Direct Link To This Post Posted: 15-Nov-2010 at 7:52pm
We don't yet support asynchronous verification, but this is something we're looking at.

The implementation you propose in the last paragraph should work.  Alternatively, after performing your async validation (e.g. through InvokeServerMethod), you could add the validation error directly to the Entity.EntityAspect.ValidationErrors collection and it will be reflected in the UI automatically. In DevForce 6.0.7 (early December) we will support INotifyDataErrorInfo as well as IDataErrorInfo so this should work for both WPF and Silverlight.
Back to Top
as123 View Drop Down
Newbie
Newbie


Joined: 27-Apr-2010
Posts: 30 		Post Options Post Options   Quote as123 Quote  Post ReplyReply Direct Link To This Post Posted: 13-Dec-2010 at 10:26am

           Can you please elaborate on the part "you could add the validation error directly to the Entity.EntityAspect.ValidatonErrors collection"? When we add a ‘VerifierResult’ to the ValidatorErrors collection from the callback method specified as part of the InvokeServerMethodAsync call, how to specify the context (targetinstance and triggercontext)? I do not see a VerifierResult constructor taking these properties. Can you please give an example?

 

Thanks

 
Back to Top
DenisK View Drop Down
IdeaBlade
IdeaBlade


Joined: 25-Aug-2010
Posts: 715 		Post Options Post Options   Quote DenisK Quote  Post ReplyReply Direct Link To This Post Posted: 14-Dec-2010 at 3:17pm
as123;

The VerifierResult, in this context, is only used to automatically display the errors on the UI. The context is not important in this regard. Maybe I could give a better advice if you can tell me what you're trying to achieve with the TargetInstance and TriggerContext.
Back to Top
as123 View Drop Down
Newbie
Newbie


Joined: 27-Apr-2010
Posts: 30 		Post Options Post Options   Quote as123 Quote  Post ReplyReply Direct Link To This Post Posted: 14-Dec-2010 at 3:43pm

         For example, let us say Async Check Unique validators are defined for ID and Name properties on Employee. When the Check Unique validation for ID fails, the callback specified will know the context, but how can this context information be passed to the VerifierEngine so that the ID property can be marked as in error (red box around) and show the error message when hovering over the box (as done by InotifyDataErrorInfo).

           In the callback method, if I just create a verifier result how will the Validation Engine know that the error is for ID and not for Name? I was thinking that in this case Target needs to be set to “ID” in the VerifierResult so that it can be marked as in error. Can you please clarify?

 Thanks

 Sample pseudo-code:


ValidatorMethod (…)

{

        …

        /* Async Query to check for duplicate values in the database */

                   EntityManager.ExecuteQueryAsync(query, userCallback, userState)

        …

}

userCallback(…)

{

            …

            _verifierResult = new VerifierResult(_result, message);            

            _currInstance.EntityAspect. ValidationErrors.Add(_verifierResult);

            …

}
Back to Top
DenisK View Drop Down
IdeaBlade
IdeaBlade


Joined: 25-Aug-2010
Posts: 715 		Post Options Post Options   Quote DenisK Quote  Post ReplyReply Direct Link To This Post Posted: 15-Dec-2010 at 5:05pm
as123;

One of the constructors of a VerifierResult is

VerifierResult(VerifierResultCode code , string message, params string[] propertyNames)

So by passing the propertyName, you can trigger, for example, a DataGrid's BindingValidationError event which you can customize to show the error red box.

I have attached an example below.
Back to Top
as123 View Drop Down
Newbie
Newbie


Joined: 27-Apr-2010
Posts: 30 		Post Options Post Options   Quote as123 Quote  Post ReplyReply Direct Link To This Post Posted: 15-Dec-2010 at 5:47pm
    Thanks. I was looking into an earlier version of DF and this constructor was not there. It is available in 6.0.7.
Back to Top
as123 View Drop Down
Newbie
Newbie


Joined: 27-Apr-2010
Posts: 30 		Post Options Post Options   Quote as123 Quote  Post ReplyReply Direct Link To This Post Posted: 29-Dec-2010 at 10:34pm

           I tried this solution and it works with adding validation results to the collection. 

           However, if the same error occurs again for a different value for the same property (after the initial error), the error is added again to the validation summary control unlike the Verifier Engine behavior, which is only one entry in the Validation Summary even if the same verifier error occurs for the same property multiple times.  Do we need to have custom logic to avoid getting duplicate messages?

On a similar note, how do we remove the message after the Async call succeeds? If I try to remove the validation error by calling EntityAspect.ValidationErrors.Remove(), the message is removed from the collection, but the property still shows as in error and the ValidationSummary also shows the error.  Do we need to do anything else apart from removing the validation result from the ValidationErrors collection?

Thanks.
Back to Top
DenisK View Drop Down
IdeaBlade
IdeaBlade


Joined: 25-Aug-2010
Posts: 715 		Post Options Post Options   Quote DenisK Quote  Post ReplyReply Direct Link To This Post Posted: 30-Dec-2010 at 12:25pm
as123;

Yes, it looks like you need to add custom logic to avoid duplicate messages for this.

In regards to removing the errors, you will need to call ValidationErrors.Clear() as well as removing the errors from the ValidationSummary manually.
Back to Top
as123 View Drop Down
Newbie
Newbie


Joined: 27-Apr-2010
Posts: 30 		Post Options Post Options   Quote as123 Quote  Post ReplyReply Direct Link To This Post Posted: 30-Dec-2010 at 1:21pm
          Regarding the removal of errors, I believe you meant ValidationErrors.Remove(), and NOT ValidationErrors.Clear() as I am only trying to clear a specific error.
 
          You have mentioned about removing the entry from ValidationSummary manually, but how about the red box around the property in error (result of INotifyDataErrorInfo)?  As part of the removing the validation error entry from the ValidationErrors collection, the error notification (red box) does not go away. Do I need to do anything else to fire that event so that the property is no longer in error after removing the entry from ValidationSummary?
 
          It was mentioned earlier that IdeaBlade is looking into Async Verification. Is there a timeframe by which we can expect this?
 
          If there is a better workaround to handle all these situations for Async Verification in SilverLight, please let me know.
 
Thanks
Back to Top
DenisK View Drop Down
IdeaBlade
IdeaBlade


Joined: 25-Aug-2010
Posts: 715 		Post Options Post Options   Quote DenisK Quote  Post ReplyReply Direct Link To This Post Posted: 30-Dec-2010 at 4:09pm
as123;

You're right, it shouldn't be this complicated to handle Async Verification. I need to do more research on how this works with DevForce and get back to you. I will find out about the timeframe as well.

Meanwhile, here's a link which you might find useful.
Back to Top
as123 View Drop Down
Newbie
Newbie


Joined: 27-Apr-2010
Posts: 30 		Post Options Post Options   Quote as123 Quote  Post ReplyReply Direct Link To This Post Posted: 30-Dec-2010 at 4:14pm
           Thanks for looking into it.
Back to Top
DenisK View Drop Down
IdeaBlade
IdeaBlade


Joined: 25-Aug-2010
Posts: 715 		Post Options Post Options   Quote DenisK Quote  Post ReplyReply Direct Link To This Post Posted: 10-Jan-2011 at 11:49am
Here's a sample app that should demonstrate at a basic level how to do async validation with DevForce.
Back to Top
as123 View Drop Down
Newbie
Newbie


Joined: 27-Apr-2010
Posts: 30 		Post Options Post Options   Quote as123 Quote  Post ReplyReply Direct Link To This Post Posted: 10-Jan-2011 at 12:40pm

          Thanks for the latest sample.

 

          If I make a Company Name error by entering @ as part of the name, it shows the error correctly, but as mentioned earlier the error is duplicated if I tab back to the same field. After correcting the error, the user is expected to come back to the filed twice to clear all the existing errors. Do you still think it is the problem with DataGrid/INotifyDataErrorInfo? If so, do you know why we do not see such a behavior when doing Synchronous Validations?

 

         Also, the ValidationError is removed by checking for '@' in the error message. It is possible that we might have such characters in other error messages or we may not have such a text to look for in our messages. Is there a better implementation for this? Is there a tag property or something like that for validation error which we can set when a specific error message is generated (may be, a unique Message ID) so that we can look for such immutable property and remove those errors.

 

          For example, if we have validations to make sure that Name and ID must be unique (checked async), the messages might be just 'Must be Unique'  or 'ID must be unique.' or 'Description must be unique.'. It might be difficult to remove such messages. Another alternative might be to regenerate the same message and look for its existence and remove it. However, this won’t work if we have generic messages like ‘Must be unique’ and the context is added dynamically as part of displaying error summary.

 

          Thanks again for your help.
Back to Top
DenisK View Drop Down
IdeaBlade
IdeaBlade


Joined: 25-Aug-2010
Posts: 715 		Post Options Post Options   Quote DenisK Quote  Post ReplyReply Direct Link To This Post Posted: 11-Jan-2011 at 5:37pm
as123;

The error message duplication is indeed strange. I have verified that both INotifyDataErrorInfo error collection and the ValidationError collection only has 1 error count each. And when you remove the VerifierResult, it removes both message as well. This is the exact same thing that happens with Synchronous Validations. It looks like I need to dig deeper on this.

Regarding the user expected to come back to the field twice, this actually looks more of a UI issue in that if you focus on any other field, the error will go away. You don't have to come back to that same field twice to clear the errors.

As for your ValidationError removal question, I just used the Message property as an example. You can use any other property you like to search for the VerifierResult in question. For example, PropertyNames can be used as well.

var propertyName = Customer.PropertyMetadata.CompanyName.Name;          
var resultToRemove = validationErrors
       .Where(v => v.PropertyNames.Contains(propertyName))
       .FirstOrDefault();

 
Back to Top
DenisK View Drop Down
IdeaBlade
IdeaBlade


Joined: 25-Aug-2010
Posts: 715 		Post Options Post Options   Quote DenisK Quote  Post ReplyReply Direct Link To This Post Posted: 12-Jan-2011 at 4:23pm
as123;

I was finally able to find, what I think, is the root cause of the duplicate message. 

When adding a free form VerifierResult, the TriggerLinks are not being handled properly and due to our implementation of INotifyDataErrorInfo.GetErrors(String.Empty), it causes the duplicate message. This combines with the fact that TriggerLinks is not serializable. So for now the quick fix for this is to add the TriggerLink manually inside the server call back method.

private void OnServerMethodCompleted(InvokeServerMethodOperation args) {

...........................

var vr = (VerifierResult)args.Result;
        vr.Verifier.AddTrigger(Customer.PropertyMetadata.CompanyName.Name);

if (vr.IsError) { validationErrors.Add(vr);

.........................
  }

..........................
}

I will file a feature and/or defect request for this.
Back to Top
 Post Reply Post Reply Page  12>

Forum Jump Forum Permissions View Drop Down