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
level validation for forms and
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.
NOTE: We decided to do only d
ata type scripts.
Simple property validators are a
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.
user interface setting up validation is similar to today’s regex validation
but is also intended
to be compatible with Ext client
(See Ext VTypes object)
User can pick an existing validator from a list rather than always create a ne
w one. There is a
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
Return true if value is valid, false otherwise
Message to show when the validation fails
A text input mask as used in Ext VTypes
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:
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.
that has functions matching the
(other functions may be defined
can either be provided in a
file for module
or can be entered into LabKey for
In the case of a module, the file would be in the directory with the schema
definition. If the file named
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.
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.
called even if only one row is being
Context is made available via the global LABKEY object
see Execution Context below
Do we want to add more context for the current domain? What if it is par
t of an Assay?
): called once per row.
Errors object is compatible with server
error handling in Ext
. 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.
There may be times when the set of errors can’t be known or
determined efficiently without seeing all the rows. The complete_
method is called after the
method has been called for each row. The error array is pre
filled with an array of error
objects each of which has a
field in it based on the row index of the row. The
complete_action can edit the array
or add new
passed the previous value to a record for each row. This seems expensive for bulk
updates, but not sure.
Instead of separate measures we could just have a parameter of INSERT, UPDATE, DELETE.
In the case of a user
defined assay it is possible to have
both on the base assay type and on a
particular assay definition. In this case
are called with the derived type first followed by the
base type. If
both the base &
an error for a field
the error from the derived
error is used in preference to the base type’s error.
The execution context for a validation
includes access to
LABKEY object and the file system
Ideally there is a server
side version of the LABKEY Object with the same parameters as far as Container,
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
LABKEY has an
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).
When on the client LABKEY.Query.selectRows returns the result it would otherwise pass to
If successCallback is specified on the server it is called synchronously.
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.
It is sometimes useful for triggers to run in an elevated security context so that they
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
ser for now.
If a validator throws an exception during execution the input will be rejected with an error “Error in
If the validator does
not compile it will be ignored (we should put some kind of error in a log).
entered into the user interface, non
compilation should not be an option.
If validators are placed on datasets they should be exported into the study archive with the dataset.