CSLA Validation, AJAX, Web UI & Cool!!!

CSLA Validation, AJAX, Web UI & Cool!!!

Old forum URL: forums.lhotka.net/forums/t/4225.aspx


vdhant posted on Thursday, January 24, 2008

Hi guys
Just wondering if anyone has done anything interesting within validation and ASP.net AJAX to provide rich experience to the user when it comes to validation. As in, maybe using a CustomValidator which has a ValidatorCallout Extender and when the user goes from control to control a quick postback is cased which simply checks to see if the relevant property is valid or not and if not returns the relevant messages back so that they can be displayed in the extender. Or if there is to much overhead with checking per control handling this on the submit postback or something.
I am just after something that is a bit richer than simply displaying a list of messages at the top of the screen when the user hits submit.
Thanks
Anthony

Henrik replied on Thursday, January 24, 2008

Anthony

We've just gone into beta 2 stage of an online day care system, that is based entirely on AJAX postbacks on the client, ASP.NET on the server and CSLA.NET 3.0 as our business layer.

We started out with the same ambition as you are describing: doing async postbacks for each field change to do validation.
However we found that the client becomes way too chatty and since our potential load will be in a couple of thousand simultaneous users, this would kill our servers.
Moreover, since some of the fields requires quite a bit of validation code (db lookups ...) we can't afford to do the validation more than once.

Instead we've gone with a kind of "predictive fetch" pattern, where we load as much "simple" validation information as we can, when the user starts a new edit process.
The validation information contains simple validation rules such as MaxLength, IsRequired, Min/Max date and such. This information is tucked into a JSON object and stored on the client.
If an edit process involves looking up some data, that will have an effect of the client validation rules, we tuck as much validation information, about that, as we can into the lookup.
An example is an enrolment wizard where the user enters a Danish CPR-number (SSN in the U.S). Before we show the wizard we async load simple validation rules for the number entry. After the number has been entered and the user clicks next, we lookup the number and if found, we tuck (piggy-bag) validation ruleinfo, that relates to the number, in the async response. As I've mentioned, this is only simple information such as the earliest and latest date a child with the specified number can be enrolled in the day care centre and which field that are required and such.
We do not return the validation error/warning string in the response. These are put into a JSON object that is built and registered during OnPreRender. These resides on the client for the entire lifetime of the page.

When the data is sent back to the server for Save, the CSLA business objects do the entire validation including the heavy db-lookups and if any errors are found, the server-page throws an exception with the error string, which is shown on the client.

By doing it this way, we prevent a lot of async postbacks as well as catching simple entry errors asap.

What you have to keep in mind is that even though async postbacks are small units of data, the server still has to take a thread from it’s thread pool to handle the request. You’ll soon find that just 50 simultaneous users doing async postbacks to validate each field, will starve the thread pool quite quickly. Of course you can get by this by increasing the number of threads in the pool and/or scaling the server/farm, but we’ve found it to be an unnecessary cost compared to what we get in return.

Regards
/Henrik

 

 

JonM replied on Thursday, January 24, 2008

I can't wait for SilverLight 2.0.  I'm hoping we can load CSLA business objects w/ validation directly into the browser.  Of course, the browser shouldn't be trusted.  It would be good to re-check on post.

vdhant replied on Thursday, January 24, 2008

Hey Henrik

Thanks a lot for the great info. This sound like exactly what i am after and I can see how the checking on every control would be a killer.

If you can bear with me I have a couple of questions:
A) How hard did you guys find this to set up and get working? At the current time I haven’t used Asp.net AJAX at all but I have used JavaScript a lot (so creating client side validation code doesn’t phase me) and have used other AJAX frameworks (I seem to be doing a fair bit of server side framework development at the moment) and am wondering how much work it will be to get to the point where one could do what you have described?

B) When you store the rules that you determine that the client can processes (i.e. min, max, req, etc) you store these in a JSON object, does this just contain the list/array of items that contains the name of the property and the name of the rule and any extra data (like min and max) that you need? If this is the case do you then have a method that runs when the client leaves the control which looks through this list for any rules that associate to this property and dynamically run them?

C) I can see that with the last point in B that i mentioned, you could do the check, but how do you go about presenting the results? Have you be able to push the results into the various relevant AJAX control (i.e. ValidatorCallout Extender, I’m thinking that I would be cool that once you have the broken rules for an property that you push that into the extender, but saying that it would mean that you would have to dynamically create the extender speech bubble when required for each property otherwise you would need server side code)? Or have you created another mechanism for this.

D) In the last point in B when you find a rule that you want to check (i.e. is a given control mandatory) have you replicated the validation methods on the client (I guess you would because you would have to do a post back)? This being the case did you write your own methods or did you hock into the pre-existing client validation within .net?

E) How much of the functionality of the rules engine did you port from CSLA to the client (i.e. did you being across dependent properties and short circuiting, etc)?

F) When preparing the JSON on the server do you simply request all the rules from CSLA (i guess the come back in the 'rule://...' format or similar) and then create your JSON object from there? And how do you determine which rules you can include?

G) Again how hard was the overall process of doing the port and are you guys happy with the result? I am thinking that you should be since you only have to declare the rules in one place.  

H) What are the chances of getting a copy or a sample of what you have done here ;)

Thanks for you time I know there are a couple of questions here but I just want to see what’s is involved before I start.

Thanks again
Anthony

Copyright (c) Marimer LLC