LabKey JavaScript Validation

hushedsnailInternet and Web Development

Nov 12, 2013 (3 years and 9 months ago)

124 views

LabKey JavaScript Validation

Mark Igra

Revision 1, 4/19/10

We’ve had several requests for



Consistent validation whether through forms the API or bulk load



Shareable Validators that can be used on individual field types



Row
-
level validation for forms and
bulk upload

This spec covers field validators and “data scripts” which can be associated with LabKey data types.

PRIORITY: I think there’s a lot more value in the data scripts than individual field validators.

Field Validators

NOTE: We decided to do only d
ata type scripts.

Simple property validators are a
JavaScript

function that takes a value and returns Boolean true or an
error message. These field validators can

be created via the LabKey user interface or stored in an XML
file in a file based module.

Wit
hin the
user interface setting up validation is similar to today’s regex validation
but is also intended
to be compatible with Ext client
-
side validation

(See Ext VTypes object)

1)

User can pick an existing validator from a list rather than always create a ne
w one. There is a
drop
-
down list of available validators at the top of the dialog.

These can be shared at the
container, project or site level if the user has the right permissions. If creating a new one there is
a new drop
-
down called Shared with a pick l
ist of “Not Shared”, “This Folder”, “Project”, “Site”.
This should be added to existing validators as well.

The validator has the following settings

a.

Name

b.

Function


An anonymous javascript function. This is filled in with the content

function (
value) {


//
Return true if value is valid, false otherwise


Return true;

}

c.

Message


Message to show when the validation fails

d.

Mask


A text input mask as used in Ext VTypes

2)

There

is a “manage validators” link that gives a list of validators visible in this
context and allows
you to edit or delete them

if you have permissions
.

Suitable warnings applied

LabKey should with standard validators corresponding to the Ext vtypes:



Email



Alpha



Alphanum

Data
Type
Scripts/Validators

Data
Type

scripts
can validate a sing
le row or a set of rows.

Since these scripts can do operations like
modifying the data on the way though they are more like triggers.

A
data

script
is a

server
-
side

JavaS
cript
file
that has functions matching the
names below

(other functions may be defined
)
.

A
data

script
can either be provided in a

file for module
-
defined types

or can be entered into LabKey for
other domain
types
.

In the case of a module, the file would be in the directory with the schema
definition. If the file named
TableName.
js exists
for a given table/dataset it would be used. There should
also be an option in the xml to specify a script name.

Since the Ext form model provides for Ajax
-
based reporting of server side errors, these scripts are not
initially (or perhaps ever) targeted for

running on the client.

function init
_
action
() :
Action can be “insert”, “update”, “delete”. This method is called
once for an
entire set of rows, allows the user to set up data structures used in validation. In particular might want
to do a query to popu
late a set of legal values.

Init is
always

called even if only one row is being
processed.

Context is made available via the global LABKEY object



see Execution Context below
.

ISSUE:
Do we want to add more context for the current domain? What if it is par
t of an Assay?

function
before_
action
(row
, errors
): called once per row.
Errors object is compatible with server
-
side
error handling in Ext

(
http://www.extjs.com/deploy/dev
/docs/?class=Ext.form.Action.Submit

)
. To add
an error you would do something like errors[“MyField”] = “Out of range”. If errors is not empty an error
will be reported for that row.

If errors is empty the action will be attempted, but still may not succeed
.

The function can modify the row object as part of its operation.

function complete
_
action
(
errorArray
)
:
There may be times when the set of errors can’t be known or
determined efficiently without seeing all the rows. The complete_
action

method is called after the
before_
action
method has been called for each row. The error array is pre
-
filled with an array of error
objects each of which has a
_rowNumber

field in it based on the row index of the row. The
complete_action can edit the array

or add new
elements
to it.

ISSUE: Westside
passed the previous value to a record for each row. This seems expensive for bulk
updates, but not sure.

ISSUE:
Instead of separate measures we could just have a parameter of INSERT, UPDATE, DELETE.

Inherited Va
lid
ation

In the case of a user
-
defined assay it is possible to have
script on

both on the base assay type and on a
particular assay definition. In this case
both

scripts

are called with the derived type first followed by the
base type. If
both the base &
d
erived
validators report

an error for a field
the error from the derived
validator
error is used in preference to the base type’s error.

Execution Context

The execution context for a validation

includes access to
LABKEY object and the file system

LABKEY O
bject

Ideally there is a server
-
side version of the LABKEY Object with the same parameters as far as Container,
User etc.

The main piece of code that a validation script would want to access

is LABKEY.Query functionality.
However it is probably not suffici
ent to use the callback
-
heavy version of the API. Instead I would have
the following

1)

LABKEY has an
isclient

property so that you can check if you are on the client or server. (These
scripts currently run on the server only but you could imagine otherwise).

2)

When on the client LABKEY.Query.selectRows returns the result it would otherwise pass to
successCallback

3)

If successCallback is specified on the server it is called synchronously.

File System

One of the things it would be nice to

do is give access to the f
ile system. The client side code already has
a way to set do file system access via WebDav. This is obviously async in some respects

and on the
server it would have to be synchronous.

Including External Code

ISSUE: I would think that it would be nice to be

able to reuse code here. Node.js has ways to load
modules, I believe, but not sure what the search path would b
e. I think we blow this off for now.

Permissions/Run As

It is sometimes useful for triggers to run in an elevated security context so that they
can query/update
data that the user cannot see. However as this creates a big hole for

accidental exposure of data so this
would not be the default.

It would be nice to have some sort of annotation here, but probably all scripts should run as the current
u
ser for now.

Error Handling

If a validator throws an exception during execution the input will be rejected with an error “Error in
Validator”.

If the validator does

not compile it will be ignored (we should put some kind of error in a log).

For validators

entered into the user interface, non
-
compilation should not be an option.

Import/Export

If validators are placed on datasets they should be exported into the study archive with the dataset.