I inspected them and concluded that field-validation does not result in a message shown on the screen. E.g. choose orders, edit the first one and change the date into 01-01-1900. The date change is not accepted, but no message is displayed. I think a message should be shown.

It seems there is an issue with the validation example because many field validations which can fail such as the order date being over 1 month less than the current date should fail and report the error. The code which does thiis is on line 71 of OrderValidator.cs

                            involvedEntity.SetEntityFieldError(OrderFieldIndex.OrderDate.ToString(), ORDER_DATE_ERROR_MESSAGE, false);

However the asp net page simply contains a bulleted list which is only updated when entity level validation fails e.g. the required date not greater than the order date. When entity level validation fails an exception is raised and caught in the asp net page.

Well review the validation sample further and get back to you

Hi Matt,

This is caused by the fact that the asp.net controls do not support the IDataErrorInfo interface. This was allready noted in http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=11948

I'll try to implement the suggested solution tomorrow.

Jan

This is caused by the fact that the asp.net controls do not support the IDataErrorInfo interface. This was allready noted in http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=11948

I think you have posted a wrong link.

Anyway LLBLGen Pro validation is ment to validate LLBL Entities, for UI messages and notifications a user should also use a UI user input validations. So LLBLGen validations act as a second or final line of defence. Also if you want you may raise an exception in LLBLGen validation, and catch it in the UI and display the message within.

Walaa wrote:

I think you have posted a wrong link.

You are right. Sorry for that. I copied the link from the wrong message. The link should be:

http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=9206&HighLight=1

Anyway LLBLGen Pro validation is ment to validate LLBL Entities, for UI messages and notifications a user should also use a UI user input validations.

The examples illustrating DI and Validation show that it is to be used for field-validation. This seems to work fine for Windows Forms (even without raising exceptions) but gives problems in Web Forms.

I'm still working on the suggested solution.

I have some of it working using the suggestions on http://www.kowitz.net/archive/2007/11/08/idataerrorinfo-for-asp.net.aspx

This solutions dynamically adds custom validators to the page for each error found. And for each property that is invalid it inserts a literal in the page that should result in a red coloured asterisk (*) being shown next to the property. The errors added via the custom validators are shown in a validation summary.

I have a gridview showing products. When a product is selected, stock details are shown in a detailsview. The user can choose the edit icon in the detailsview. When he does, enters wrong input and chooses to save, the input is not accepted.

The validation summary works, but the asterisks are not displayed. Also the information shown in the detailsview is refreshed by the content of the database and the detailsview returns back into readonly mode (the default).

I would like the detailsview to stay in edit-mode and the content not being refreshed, allowing the user to correct the input.

I'm willing to post what I have got until now, but I'm reluctant because I think this is not a LLBLGen problem, but a result of ASP.NET functionality.

Hi JayBee,

The "Adapter - WebApplication - Validation Example" was re-tested and re-released. Could you please download and read the Readme.txt, then use it again?

For the Orthers.aspx example one thing changed: you can edit any order, but you can't insert orders which are too old.

When you click "Save" the entity is sent and the validation take place (validation per postback). If you want to have a behavior like WinForms (validation per field input) you should to use AJAX.

Hi Daelmo,

I tried it. I do not think this is the way user input should be verified. When I edit the first order and change the RequiredDate into a date that is before the OrderDate, I do get a message, but the inputchange itself and al other proper input changes are gone. The user will have to fill in everything again and does not see the wrong data he filled in.

The original input should be preserved and a list of error should be shown. The solution I am trying to develop does support a list of errors but it does not preserve the input.

How do you think Ajax can solve this? I do not think there is a relation between Ajax and this problem.

Cheers,

Jan

Well, if you use Ajax you the user don't have to wait the whole postback but validate control by control depends upon the user-input

Another approach: commonly many websites that don't use Ajax perform a whole postback and clean the failed controls at the trip. For instance, if you set an invalid value to a control, when you do a postback the control comes blank. You can do this at ValidateFieldValue.

You also could include this kind of information (What field is, what value is wrong, etc.) in the field IDataErrorInfo.

Even if you use 3th party gui-validation tools (like that you posted above) you have to make this kind of decisions at your Entity/EntityField validation level.

The point is that I would like to use the 'advanced' features of aspnet 2.0. I.e. the new controls and LLBLGenProDataSource. For Gridview just displaying data and paging it is fine. For updating / inserting I think you still have to use a seperate dedicated IO screen since field validation will not work the way I described. That is a pitty.

JayBee wrote:

I have some of it working using the suggestions on http://www.kowitz.net/archive/2007/11/08/idataerrorinfo-for-asp.net.aspx

This solutions dynamically adds custom validators to the page for each error found. And for each property that is invalid it inserts a literal in the page that should result in a red coloured asterisk (*) being shown next to the property. The errors added via the custom validators are shown in a validation summary.

I have a gridview showing products. When a product is selected, stock details are shown in a detailsview. The user can choose the edit icon in the detailsview. When he does, enters wrong input and chooses to save, the input is not accepted.

The validation summary works, but the asterisks are not displayed. Also the information shown in the detailsview is refreshed by the content of the database and the detailsview returns back into readonly mode (the default).

I would like the detailsview to stay in edit-mode and the content not being refreshed, allowing the user to correct the input.

I'm willing to post what I have got until now, but I'm reluctant because I think this is not a LLBLGen problem, but a result of ASP.NET functionality.

Hi,

I'm not a user of LLBLGen, although I do have similar problems with ASP.NET and validation. The behavior you are seeing from the details view and can be fixed via an event :

protected void DetailsViewAddress_ItemInserted(object sender, DetailsViewInsertedEventArgs e)
{
     e.KeepInInsertMode = true;
}

If you with to do something based on valid data being inserted, use an event from the datasource (this is from ObjectDataSource, but I'm sure LLBLGen has something similar):

void ObjectDataSourceAddress_Inserted(object sender, ObjectDataSourceStatusEventArgs e)
{
/* ... hide DetailsView... */
}

In general if you are using a data source I'd treat details view as a 'dumb' interface, the datasource is the component with the power. Hope this helps.

brendan wrote:

If you with to do something based on valid data being inserted, use an event from the datasource (this is from ObjectDataSource, but I'm sure LLBLGen has something similar): Code:

void ObjectDataSourceAddress_Inserted(object sender, ObjectDataSourceStatusEventArgs e) { /* ... hide DetailsView... */ }

LLBLGenProDataSource has the corresponding EntityInserted event.

It all seems so complicated. And adding a lot of code without any logical added value.

I decided to stop using the DetailsView control

IMHO it is much clearer that the input field rules and entity rules are checked before an insert or update is done. This can be done by adding some extra functionality to the SelectedIndexChanged event of the gridview (e.g. determination if the entity can be deleted or updated and as a result of that show the save, cancel and /or delete button). That has to be followed by validation of the entered values.

So, Im back to my old approach. Still thinking of using the validator classes to do the validation.

JayBee wrote:

IMHO it is much clearer that the input field rules and entity rules are checked before an insert or update is done. This can be done by adding some extra functionality to the SelectedIndexChanged event of the gridview (e.g. determination if the entity can be deleted or updated and as a result of that show the save, cancel and /or delete button). That has to be followed by validation of the entered values.

IMHO you are totally right. You have to add validation at all your layers: GUI, Business Logic, Entity/EntityField, Database. If you validate well at your GUI, you will save overhead and WebServer and Database roundtrips. I would recommend to use your BL, Entity and EntityField validation too to prevent other input flows. And if you can incorporate some 3rd. party validation controls (like the one you posted) you will save a little of code.