Visual LANSA Forum

Ok, so in SP2 I have heard that Repository Validation now works on VLWeb client fields. Spinning up one of the new SP2 demo templates show this. This does not seem to work in VLF-ONE as the control does not get highlighted. Only the message appears. When trying to figure out why, I discover on the VLWeb template, there is a "Validate" method on Dialogs and Views. There is no such method on the VF_AC010O object, but there are some avValidate methods I can't find any documentation on these.

Are these used to perform client side validation like in VLWeb's Dialog and View?
How do you use them?
Can client side repository validation be done in VLF-ONE or are we stuck doing it the old way. viewtopic.php?f=3&t=193&p=2388

EDIT
I've been experimenting with the avValidate methods but not getting expected results.
I track the controls in the uInitialize And on the button click But the avValidateAllTrackedMDControls always returns true. A difference from this method and the VLWeb method is that this method does not include the Table, which should be required as far as I know.

Those new methods are designed to work in conjunction with the code that the VLF generates from the Common Activities tab. I think that the best way to see how they work would be to use a test framework. Create a business object, then use its Common Activities tab to generate an automatic SCRUD ………….

Check the MD style control option, then define the instance list columns and associate the business object with a data base table (eg: xEmployee) then generate a simple SCRUD.

That will create a hidden filter and a command handler.

The SCRUD command handler shows how the client side validation methods you are interested in are used.

A key one of interest is the redefined method avHandleTrackedControlChange which executes every time a control that is being tracked/monitored is changed. It clears any errors. Another is avValidateTrackedMDControl which validates a control, and also scrolls it into view if it has an error.

Those methods are just very specialized VLF-ONE abstractions to make doing client side validation use less code.

You don’t need to use them, and it may be better not to.

It’s important to remember that at the lowest level, if you have a control like:

Define_Com Class(#xEmployeeGivenNames.EditField) Parent(#DataItemPanel)

Then you can use these in any way you like:

#xEmployeeGivenNames.ClearError

#isValid := #xEmployeeGivenNames.Validate( Insert #xEmployee ) /* Say */

If you have your form elements in some sort of a collection, or as iterable children of a container like a view or a panel, then you can do this in a loop using less code.

I think (but am not sure) that not specifying a table name might also be valid, because it would apply any dictionary level validation rules that apply to the field globally, rather than just database table:

#isValid := #xEmployeeGivenNames.Validate( Insert )

There's also hotfix related to this area.
This prevents the SCRUD generator from using the wrong table name for validation - but it's very easy to correct manually if you don't have the hotfix installed.
viewtopic.php?f=4&t=1829

Hi Mark,

Thanks for the help, I never would have anticipated having to redefine multiple methods and invoke the validation on the control itself.
VLWeb seems to make it much easier.

It appears that this does not support lookups and complex logic checks as those checks don't get the same UI highlighting treatment.

Joe

Hi Joe,

you're right, it doesn't support lookups and complex logic checks (at least, currently it doesn't).

It only supports checks that CAN actually be performed on the client using only information that is at that point in time available on the client.

Since lookups involve database access and complex logic checks COULD involve database access, they HAVE to run on the server.

I understand that we like the reporting mechanism, the material design error state/error message, and that we would love to see those server side checks being reported in the exact same way as the client side checks. We're just not there currently, as we're still missing the correct context in messages coming back from the server.

Having said that, I do find that a lot of the additional server side messages don't really have a single context and in that sense don't really belong on a single field but might much be better off on an alert.

Cheers,
Danny