Validation Bundle FAQ
For some time we've been hearing alot of requests from customers to deliver guidance on building responsive web client applications utilizing ASP.NET AJAX. As a result of this feedback we had an exploratory phase where we looked at different patterns of
building AJAX style applications. As part of our discovery we classified Web applications into one of 3 types with types 2 and 3 pertaining to AJAX style applications.
- Pure RIA applications. A web application that performs most of it's rendering on the client rather than the server. AJAX is utilized heavily for accessing server side resources bwithout having to do a full post-back. The user interface rendering
relies on the AJAX Extensions.
- Hybrid RIA applications. A traditional web application that renders both on the server and the client. On the client AJAX functionality is sprinkled throughout the interface in order to deliver a more responsive experience. In this kind of application
partial-postbacks are common where the browser utilizes AJAX to post the page in an asynchronous fashion. The response to that post consists of HTML that is then dynamically updated on the client.
As we evaluated the different options we quickly determined that our focus should be on Hybrid RIAs rather than pure RIAs. The reasoning for this was several fold.
- Customer's voted more heavily on how to AJAXize existing applications rather than creating pure RIAs
- The tooling and developer productivity are lacking for building pure RIAs.
- The ASP.NET team recommended based on their customer feedback that this should be our focus.
Validation was something that we had many asks from the community for. As we were focusing on responsivness that led us to think about Validation in those terms. To kickstart our efforts we developed an Order Entry Reference Implementation that would help us
to flesh out customer scenarios around responsiveness. The reason we chose Order Entry is due to it's being a common type of LOB application that many developers have built.
As we built out the RI we noticed a few common challenges, one of which was around invoking server-side Validations from the server. As we evaluated improving Validation responsiveness we saw 3 main scenarios which we optimized around.
- Access server-side resources. An example of this would be validation of an Account number against a very large list of accounts that could not / would not be embedded in the client. This also can include validations that utilize custom business logic
that cannot easily be recreated on the client.
- Reuse validations across many screens and applications. For example a regular expression validator on the SSN property of an Employee entity, where that employee's data may be displayed in many screens, but you don't want to replicate the
logic all over the place.
- Hybrid of client / server validation. For example having a client side required field validator combined with a customer ASP.NET Server validator or with using VAB.
Why are you using ASP.NET validators versus a lighter mechanism?
The short answer is that we found alot of benefit in what the platform provides. ASP.NET Validation is woven very tightly into the page itself. This means the page is aware of it's validators and knows whether or not the it is in a valid state. Also the
infrastructure provides summary controls and the like which can display the summary of all errors on the page. Having the ServerSideValidationExtender work with all ASP.NET Validators gives developers more options as to which validations they can make more
responsive, and also allows leveraging the built-in ASP.NET infrastructure. We did consider the following alternative mechanisms which were rejected.
impacted the rest of the deliverables for this release. Also we felt with emerging technologies such as Silverlight on the way that will allow the .NET CLR to run on the browser, this was leading people down the wrong path.
- Use light JSON services to perform the validations without requiring a full page life-cycle. We also evaluated this approach, but determined that if we went down this road, we would not be able to leverage the rich validation infrastructure provided
by ASP.NET. This would cause us to have to signficantly reinvent the wheel which would dramatically increase the scope of the project. Also we determined that for many LOB applications running behind the firewall, the size of the payload was acceptable. However,
in some scenarios this may not be the case and creating a custom JSON mechanism may be appropriate.
Why are you using Update panel for the entity-level validation? Why can't I directly call Entlib like I can with the properties by using the PropertyProxyValidator?
The Update panel allows us dynamically display the text that indicates the Save was successful. The reason we need the custom validator, is that the PropertyProxyValidator only works on a single property of an entity. It doesn't actually instantiate the
entity, and instead simply takes the value that was provided and runs the appropriate validations. As such, it does not allow cross-field, cross-property validation. Using a custom ASP.NET validator allows us to instantiate the actual entity instances, set
the properties based on the passed in the viewstate, and we can then Validate the entire entity.
Why is there a dependency on ASP.NET AJAX?
ASP.NET AJAX provides a rich set of functionality for buiilding AJAX style applications which this bundle leverages.
Why is there a dependency on the AJAX Control toolkit?
The new ServerSideValidationExtender inherits from the base extender built in the AJAX toolkit.
Why is there a dependency on the PropertyProxyValidator in Enterprise Library.
There's actually not. However, the PropertyProxyValidator provides the ability to invoke property-level validations on an entity. The ServerSideValidationExtender 'Ajaxizes' this validator to allow it do a partial-postback.
What validators does the ServerSideValidationExtender support?
Any server-side ASP.NET validator.
In cases where your application is operating in a low-bandwith / high-latency environment it may be best to strictly use the client-side ASP.NET validators. Even in these scenarios you may want to leverage the ServerSideValidationExtender to perform complex
validations that cannot be easily replicated on the client. If you application is running on a corporate intranet, or over high-speed connections, then this may not be a concern.
Can I use the Validation bundle with the Web Client Software Factory?
Yes. The extender is within a reuable library that you can reference from your existing WCSF applications as long as the solution is properly configured to use ASP.NET AJAX and the AJAX Control Toolkit.
Can I use this with an existing ASP.NET Application that does not use CWAB.
Absolutely. The Validation bundle does not have any dependencies on our factories. The extender is within a reuable library that you can reference from your existing ASP.NET applications as long as the solution is properly configured to use ASP.NET AJAX and
the AJAX Control Toolkit.
Will it work with Visual Studio 2008 Beta?
We believe it will, but we are doing some additional testing which we will post on. Worst comes to worst we think customers would need to recompile the extender with appropriate .NET 3.5 references in VS2008.
Am I required to have GAT/GAX installed?
No, as there is no automation.
Can I get the source code?
Yes, as this is a CodePlex project, you can download it by clicking on the