This document defines the new specs for studio UI. The goal is to develop a next generation consistent multi GUI interface (vt100, swing, web).

1 General

The UI should have some basic features like:

  • Automatic timeout to ensure release of cursors on tables after and idle time.
  • Hability to cancel long operations like going to last row, doing a query, changing the sort.
  • Concurrency control for multiple access to the same ResultSet from multiple threads.

2 Metadata

Most information should be obtained from database metadata. This includes:

  • Column names, types, scale, etc. This information should be used to ensure correct input.
  • Table foreign keys to ensure data validation on entry.
  • Check constraints with client side pre-validation with feedback to the fields that failed.

Additional information can be obtained from specific tables to allow more detailed setup. This includes:

  • Column output decoration like color expressions
  • Column input options like:
    • Client or server default values
    • Server function like CRC32(), FileName(blobcolumn), FileSize(blobcolumn), ...
    • Client check constranints to oveerwrite some specific or missing database constraint
    • Client javascript expression
    • Server javascript expression - this is not clear to be need

To handle all this feature system will use ResultSetColumnMetaData class that containts a set of extensions for all above. A part from all JDBC column metadata, ResultSetColumnMetaData provides.

Feature class description
JDBC extensions
Check constraints List<CheckConstraintData> The database check contraints expression that apply only to this column.
Attributes Map<String, Object> A set of attributes for the column
Align ColumnAlign To force an specific align. Mainly useful in reports.
tooltip String The localized tooltip for the column.
note int The column index in the metadata that is a note of this column.
icon Map<String, byte[]> A map for values an icons.
Headers ColumnMetaDataHeader A header system to group columns.
Grid ColumnMetaDataGrid Responsive layout grid parameters for column.
Render AColumnMetaDataRenderType The widget to render input (or convert data) like:
  • maps by using RADIO or SELECT
  • numbers by using SPINNER or SLIDDER
  • boolean by using CHECKBOX or SWITCH
Input options ColumnMetaDataInputOptions Includes multiple features to control the input like:
  • Reactive (computed) expression
  • Nullable expression
  • ReadOnly expression
  • Default value
  • Input mask
Style (mainly for reporting)
Prefix String A prefix.
Suffix String A suffix.
trend ColumnMetaDataStyleTrend For numbers the up is good or bad trend.
Style expressions
links ColumnMetaDataStyleLink
links ColumnMetaDataStyleFont
links ColumnMetaDataStyleColor

2.1 Default values

Defaults can be present on client or in database.

  • Client defaults can be either constants or values retrieved by a initial function. This function can perform any db operation to provide a map of column values depending on any logic (the user for example)
  • Server defaults are defined in database and are set when column is not send during the insert operation. Common server defaults include current DATE, current USER, etc.
  • Not a default but a computed value can be handled by a trigger operation.

The UI should deal with client defaults by being able to:

  1. Call, if present, the function to obtain the transaction defaults for an insert operation
  2. Transfer any default constant to input field in the appropiate format. For example, TODAY or CURRENT as a date

2.2 Server functions

A server function can be applied on a field to perform som computation on the field or other fileds. For example:

  • Encrypt a field
  • Compute a crc32, md5 on other field
  • Compute the mime type, file name or file size on a multipart content (blob) that is being submited

2.3 Check constraints

There are two types of constraints. Database check constraints and client side check constraints. We can split constraints in two types by examining it.

  • Contraints that reference a single column.
  • Contraints that reference multiple columns.

2.3.1 Database not null constraint

The not null should be evaluated on client input to prevent leave a form with empty required fields.

There are some cases when we need to disable a not null constraint on client. For example when a field can be left null to be computed by a trigger or server function.

We can use the colum input options nullable expression to enable this feature. By setting true on the expression it will set field nullable.

2.3.2 Database check constraints

  • A single column constraint is evaluated before field lost focus. If fails, field is marked with error and focus is keep.
  • A multi column constraint is evaluated before form is submitted. If it fails, all participant columns are set to error and sumbit is cancelled.

2.3.3 Client check constraints

Client constraints are used when some feature is not acceptable in the database. Some examples are.

  1. Comparing with live values: c_data > TODAY
  2. A constraint can not be enforced in db: process accepts a value that user entry does not.
  3. Other

2.3.4 Evaluation of constraints

A database constraint is converted from SQL to javascript uning ATLR grammaer in server and is transformed for client for evaluation. The conversion may introduce some functions or changes in the expression to handle the javascript eval (for example date comparision has some complexity). This is expected that the expression will run in both server scripting engines (Nashorn or Grall) and client but this has some issues.

The conversion tool maybe should produce a server syntax and a client syntax. For the moment we are working with server syntax but it is clear that some cases need to be addressed. For example the BigDecimal comparision need to be trea different as there are no BigDecimal on client.

Type Description Swing form Web form Considerations
string Any form of string java.lang.String javascript string -
int Any form of integer javascript Number -
float Any form of floating poin java.lang.double javascript Number May have preceision issues due the difference of types on large float values. Even so it will be very unusual. For example a constraint like a != 0.0000001
Decimal A database bigdecimal. java.math.BigDecimal javascript Number This is a special case as we have two diferent types. On server we have a BigDecimal and comparision expression to use bigdecimal compareto is gnerated on server.
Date Dates, time and datetime java.util.Date javascript date Conversion transforms dates using getTime() as it exists on both sides (server and client javascript) and thus date comparision should work.

Test cases

Check Description Swing Web
t_smallint <= t_integer OR t_integer IS NULL Compare a integer or NULL to an smallint    
t_smallint <= t_decimal OR t_decimal IS NULL Compare a decimal or NULL to an smallint    
t_date1 <= t_date2 OR t_date2 IS NULL Compare two dates accepting NULL    

3 Grid component

The grid component provides a way to interact with resultsets. It supports decorated render (styles, colors) and scrolling on device.

The grid should be able to render 3 types of ResultSets.

  • ResultSetCursorTable, an scrollable ResultSet backed by database that performs:
    1. row refresh (to see underlying third party commints)
    2. horizontal row fetch and update
    3. vertical (child) table cursor handling (for each child, compute the ResultSetCursorTable on each parent row)
  • ResultSetCursorReport, an scrollable ResultSet backed by memory mapped file as it includes rows generated by grouping.
  • Any other JDBCResultSet or MemoryResultSet provided by studio core.

4 Form Components

A form contains a set of filed from main table and related tables (horizontal joins). It can also render it's descendent items (vertical joins).

4.1 Horizontal joins

create table test_hjoin_lang(
    lang char(2) primary key

create table test_hjoin_master(
    id serial,
    lang_1 char(2) references test_hjoin_lang (lang),
    lang_2 char(2) references test_hjoin_lang (lang)

insert into test_hjoin_lang VALUES ("en");
insert into test_hjoin_lang VALUES ("de");
insert into test_hjoin_lang VALUES ("fr");
insert into test_hjoin_master (lang_1, lang_2) VALUES ("en", "de");
insert into test_hjoin_master (lang_1, lang_2) VALUES ("en", "fr");


|tabname           |tabAlias                                |columname(in form, script...) |columnLabel   |
|test_hjoin_master |                                        |                              |              |
|test_hjoin_lang   |test_hjoin_lang1                        |test_hjoin_lang1.lang         |      lang    |
|test_hjoin_lang   |test_hjoin_lang2                        |test_hjoin_lang2.lang         |      lang    |

4.2 Vertical joins

4.3 Field types

Type Mask Nemotecnic Notes
Decimal     Display format using user locale for decimal point and column scale
Date     Display format using user locale
char     May have a mask formatter like "(##)-####" or an UPSHIFT/DOWNSHIFT
varchar     May have a mask formatter like "(##)-####" or an UPSHIFT/DOWNSHIFT
longvarchar/clob     Accepts a text document. The nemotecnic may indicate the syntax highlight and grammar check.

4.4 Input options

Input options can be defined for each column. It consists of 3 expressions that are evaluated in javascript context with all existing fields as bind variables.

Name Description
reactive expression An expresion to be evaluated to compute field value based on other fields (ex: a = b*2)
editable expression
nullable expression
mask An input mask following the MaskFormatter specification

  • An invalid mask input should set the field in error.
  • A null input mask should be accepted with no error.

4.5 Form Actions

4.5.1 Copy row

4.5.2 Reset

Reset is the action allowing to create a new row in the form.


Dictionary default value: This a static default value defined at table dictionary level. It's not related to physical db default values as this allows to create diferent defaults and diferent application rules.

Global Form specific default values: Default values dynamicaly defined at form level. (Can we have two modes (?) one time and on each reset).
This allows to define default values based on user (e.g. default company for this user), calculated default values or non-global (not in dictionary or distinct from dictionary) default values

In one-time form default values this can be calculated ones when entering the form ane reused each time. (similar to current globals (???))

In each reset mode, defaults are get each time reset method is executed.

Transformations: this are simple methods to transform field values. E.g. UPPER, LOWER, MASK, etc.

Should all transformations be processed like reactive transformations(?) UPPER, LOWER, etc are specific cases of reactive transforms?

How can we decide if a default value should be applied in a layer. e.g. Should default dictionary values always override the form defaults or viceversa? Should defaults override keep previous value or only when previoys value is null?. Should this be custimizable?

Reactive Transformations: Allows to change form attributes depending of evaluation of form field values. Form attributes changed can be: noentry/disabled, hidden, fg color, bgcolor. How can we disable a complete box or tab(?)

Are we using Syntax nmotechnic Codes (wic_jdic_syntax_mnemo) ? don't see usage examples.

Reset workflow


Reset WorkFlow description

  1. Iterate in all form fields in data entry order (non visible form fields goes first)
  2. For each field, evaluate if form has defined a keep value attribute.
  3. If "keep value" flag is set, we don't change field value.
  4. Evaluate dictionary default values. Two modes: force and "if void". In force mode, always apply this default value. If not null, only apply if field value is void
  5. Evaluate form specific default values. Also two modes: force and "if void"
  6. Warning, Do we require a dynamic form specific default values?

4.5.3 Insert

Insert & Stay

Insert a new row and stay in the new created data

Insert & Reset

Insert a new row and start a new insert by calling "Reset" method.

4.5.4 Update

User can modify data from the form and a set of rules should be applied.

Main table
Feature Swing Web
Once a field is modified it should be marked to give user the notion of what's changed and form update should be enabled only if at least one field is modified.    
When a field is modified from application it should also reflect modification status in the UI. This is accomplished in Swing using a DocumentChangeListener    
Undo modification status of a field (and global form) if user restores original value.    
Check expression that apply to a single column should be evaluated after field and if failed, field should be marked with error and focus preserved.    
Check expression that apply to multiple columns should be evaluated before form update and if failed, participant fields should be marked with error and first field should get focus.    
A modified form can not be deleted, so delete button should be deactivated on modified forms.    
A modified form can can not be closed (disposed) without notification to avoid losing changes.    
Horizontal join table
Transactions should be possible on horizontal table joins. For example: in the relation orders->customer, update customer table.    
Update on non existing relations (ex: non existing customer) should be disabled.    
Adding a non existing relation should be considered.    

4.5.5 Delete

To delete a row from the form

Feature Swing Web
The delete button is active only if row is not already deleted and is not modified    

4.6 Form Labels

Single access point and easy to maintain multilanguage labels.

5 Transaction handling

The UI components when used over ResultSetCursorTable should be able to handle multi level parent child transactions.

5.1 Parent-child

This is the common case when performing parent and child table transactions. Master table is the parent table.

5.2 Child-parent

Master table is the child table. This requires that the child acting as master should be able to load parent data.

For example, when editing an order line a soft reference can require the company sored in head to filter an item.

5.3 GrandChild-Child-parent

Master table is the grand child table. This requires that the grand child acting as master should be able to load child referenced data and get parent data from child.

6 Wish UI Features

6.1 Darg & Drop Blob files

Possibility to drag and drop files directly.

6.2 Info boxes

Aditional information at boxes.

6.3 Reorder list with mouse

Possibility to reorder al list using mouse.

6.4 Helpers with reference 'number-id'

Add the possibility to parameterize the helper so that it captures an id but shows a description.

User's don't know identifiers, know codes or descriptions.

6.5 Date range picker

Varaiable type date range picker... then calendar are together and don't have to do extra clicks.

6.6 Rating

Field type rating.

6.7 Grade

Field type grade. Can have multiple values and select one (Like include but multiple choice nice...)

6.8 Slider

Filed type slider

6.9 Desktop add box-bookmarks

Add the possibility to add a box of bookmarks. Now is complex because tool of bookmarks are separate.

New option at Desktop menu. (Add box bookmark).

Ask for name of box and insert into (wic_user_desktree) and (wic_user_pt_box).

New box appear at desktop with option (Add item, remove item, edit item...)

Item is related to (wic_user_deskdata).

6.10 Easy set null to blob field

Make easy to set null a blob field, example. at product form when add an image and i want to delete it.

7 Special Features

7.1 Memory grid

7.2 Big selector