format in catalogdefinitions

A Commom Component Specification project for the Catalog is planned. Maybe you should rethink your POV on the project.

CCS members are watching this group already and gathering ideas from it (Bill Wood fe as you know). When the project becomes open (no NDA, open discussions) I'll drop ideas in another appropriate place when provided.

Hello Stefan,

thank you for the suggestion.

A format property was considered at one point (it is a property in the Data Dictionary nonetheless), however, it was not included in the FCS release. Some considerations being that format is UI related and not specific to the data and also that the case that a format from the Data Dictionary would not have a meaning in HTML/JavaScript.

I am guessing that it could be considered for inclusion in a future release as part of the CCS.

(You could submit your suggestion via the Ideas section.)

If you are using 11.4 or greater and you find a use for this property in the catalog in your framework, you could use an entity.field property annotation in your temp-table definition.

Note: Use the Edit Mobile Service dialog to ensure that the catalog file is re-generated.

Example:

   @openapi.openedge.entity.primarykey (fields="CustNum").

   @openapi.openedge.entity.field.property (field="CustNum", name="readOnly", value="true", type="boolean").

   @openapi.openedge.entity.field.property (field="Name", name="format", value="x(20)").

   DEFINE TEMP-TABLE ttCustomer BEFORE-TABLE bttCustomer

       FIELD id AS CHARACTER

       FIELD seq AS INTEGER INITIAL ?

       FIELD CustNum AS INTEGER INITIAL "0" LABEL "Cust Num"

       FIELD Name AS CHARACTER LABEL "Name"

       FIELD Country AS CHARACTER INITIAL "USA" LABEL "Country"

   ...

From the JSDO, you could then call jsdo.getSchema() or jsdo.ttCustomer.getSchema() to get an array of objects with the definition of the fields.

The custom-defined "format" and "readOnly" properties would be available.

Example:

       jsdo.ttCustomer.getSchema()[3].format

I hope this helps.

Thanks Edsel,

I did not know of the possibility to use the annotation you mentioned. I will use that for now. Easy to generate and extend. The format from the datadictionary can be used by javascript. It has to be converted to parameters that a javascript mask library can understand. The params depend on the used library so it is wise to do the conversion in your js framework.

For numbers I am using the autoNumeric library at the moment (github.com/.../autoNumeric), see for a demo www.decorplanit.com/plugin.

I think there is a strong usecase with this to add the format to the catalog

Regards, Stefan.

What about the following:

@openapi.openedge.entity.field.property (field="Name", name="mandatory", value="true", type="boolean").

UI can then define the form field as mandatory.

@openapi.openedge.entity.field.property (field="Name", name="validationRequired", value="true", type="boolean").

@openapi.openedge.entity.field.property (field="Name", name="validationFunction", value="myInvokeMethodName").

UI could then on a field blur or value changed event generically collect the required parameters for the invoke function since it already has the signature.  If the response contains error messages it could then decorate the field in the UI.

You can do it that way. When you generate the tt definition you can query _field._mandatory and add the annotation automatically. In your oe backend you could have _field._mandatory in a cache for fast access and perform the validation also.

 What I use for validations is a small business rules engine which I built in oe (no heavy, expensive, complicated corticon needed). You can maintain validationrules in a sort of querybuilder. These validations are translated to an abl validation and a JS validation and stored in the db, they are also available in a cache on the appserver for fast access. The temptable definition for fieldvalidations is this one:

 DEFINE TEMP-TABLE ttFieldValidation NO-UNDO

       FIELD FieldName    AS CHARACTER

       FIELD RuleJS       AS CHARACTER  

       FIELD RuleABL      AS CHARACTER  

       FIELD OnCreate     AS LOGICAL  

       FIELD OnUpdate     AS LOGICAL

       FIELD OnDelete     AS LOGICAL  

       FIELD ErrorMessage AS CHARACTER.

Errormessage is filled language dependent. JS validations are used with the html5 validation api in my js framework. The validations are transported in an extra output param (longchar) in the first invoke of a customread. This longchar is filled with a json.  Field validations are executed onfocusout/blur, errors are shown in tooltips (opentip.js) which are attached to the corresponding html elements. They can be executed also on commit (createevent). The json is filled with a dataset which is going to contain more than validations. In principle all ui definition can go in there, so you could have one small .html wherein every ui can be built dynamically.

 My fifty euro's CCS!  ;-)

Great suggestions.

We have considered adding mandatory, nullable, and readOnly. Perhaps, they would be added in a future version.

I like the approach with validationFunction to call an invoke method.

Depending on your goals.

If  you were generating the catalog file dynamically (which can also save and make it static) you could add these options to the generator.

The sample code in the Generic Service for the JSDO could be used as a starting point:

   community.progress.com/.../2190.aspx

Thanks.

One thing that disturbs me about  this thread is that it seems intended to replicate UI fields in the OE dictionary.  Back in the 80s, these seemed like a good idea because it meant that the quicky demo of for each customer had reasonable defaults to use for the display.  But, it is confounding UI with storage and can produce a lot of confusion when the actual UI and the dictionary definition don't match.  I suggest that we think carefully before bunging all this stuff into the same place.

Have it working. This is not a kendogrid btw. You can see a validation also, it works as described in this thread.

When actual ui formats differ from dict values it is no problem to store them elsewhere of course.

I would not choose for the invokemethod (on the server) on blur. If the validation on a field is complicated it can be servervalidation only. fieldvalidations executed on the client (html5 validation api) save roundtrips to the server moreover I see the generated businessentity with all codeexamples more as quick testcode than something for production as it does not conform to oera (you use dataaccess there etc).

You me me think a bit further Thomas. The usecase could be a format depending on currency. So it can be seen as a businessrule. If currency = some worhless coin then format = "->>>,>>>,>>9" else ">>9.99". The rule should be separated out of the code and can now be delivered apart from software-updates. Like the validationrules, implemented in the same way. I have no need for the format in the catalog anymore. :-)

Currency can be a very good example since a field might contain a standardized integer value which is displayed in different ways according to a currency symbol in a different field.   Same with unit of measure quantities.