Hello!
I am new to the CSLA .NET and I am wondering how the CSLA business entities can be used with Web Forms UI. I am going to use CSLA 3.8 with .NET 3.5 Framework.
How can I for example use validation rules from the business entity to validate multiple textboxes?
How does the validation logic for example handle type casting from string to int and give a reasonable error messages to user when using data binding? Does type casting error stop validation, does it continue or does it crash the whole application? Can I call the validation to test if the user input can be type casted?
How can I for example change the color of a specific textbox to red when validation or type casting of the data fails? Is there some way to map the UI element to the business entity property or do I need to create a mapper by my self? If latter, how should I do it?
A very simple example
Web form
First name: [textbox]
Last name: [textbox]
Age: [textbox]
Organisation id: [textbox]
Business entity
string FirstName {get; set;}
string LastName {get; set;}
int Age {get; set;}
int OrganisationId {get; set;}
You should start by reading Chapter 20 of the Expert 2008 Business Objects book to get the basics.
In general there's no great answer for client-side validation in Web Forms. The Web Forms technology doesn't have data binding that is comparable to a rich client model like WPF, Silverlight or Wndows Forms - it just isn't there.
Generally, client-side validation in Web Forms comes from validation controls that the UI developer puts into the UI. That's far from ideal, because those controls are really duplicating business logic that is in your business objects.
If you are really good at Web Forms development, you can write code in your page to automatically inject validation controls into your UI. CSLA business objects expose their rules as rule:// URIs - this is discussed in Chapter 11. You can use that metadata information about the rules to know what validation controls to project into the UI. Sadly, Web Forms doesn't have any way to do this by itself...
You must always remember, of course, that some of your rules can't be projected into the UI. Any rules with interesting business logic, or data access, or anything beyond basic validation, will always run on the server. So whatever you do in your UI must include the ability to report server-side rule issues back to the user on postback. That's just the nature of the web.
During the postback you can always get the list of broken rules from your business object. Again, Chapter 11 talks about the different ways to get broken rule information from the object. When combined with LINQ, it is extremely easy to get broken rules by severity, by property, etc. Assuming your UI design includes a model for displaying server-side errors, you just render the broken rules into the UI as appropriate.
Copyright (c) Marimer LLC