They may not be so easy to read, but we do support CIF files for importing model information.

Theo Neeskens said They may not be so easy to read, but we do support CIF files for importing model information.

But CIF syntax is not documented and there is no supporting editor. This DSL makes even meaninful text files for non-IT personnel. In fact the DSL generates a CIF file to be loaded into uniface, at least as long as "CASE Load" will be supported in Uniface (afterwards, we have to find a handcrafted loader)

I agree with the 'type yourself to death' pains when defining a new model... I've taken a slightly different approach in the past - defining the entity in an XLS file, importing the XLS file into SQL server and doing a 'load-def' from SQL server to Uniface. Not sexy, sophisticated or particulary crafty - but it does 75-80% of the legwork for me.... Uli - I remember there being a 'case cookbook' years ago - I think it was updated to CIF 2.0 as well - although I haven't seen the title for a number of years...

Hi Knut, you remembered it well: in 7.2 there was a "case bridge cookbook" (cbc.pdf) in the normal distribution set. But now this is no longer updated / maintained by CPWR: "We are not planning on publishing details on CIF or samples, it will be removed from the product in the future." One reason for going the DSL route was to ease the way documentation (Descriptions, Labels, Comments) is added to the uniface datamodel without the "retype the text into the IDF" and is fed back to the end-users for proof-reading and corrections. The beauty of the DSLs is that "the end-users" can play a more important role in application development: Model/Entity/Field Descriptions, Labels, Comments can be maintained by a simple text file which is easy to read and understand, can be transported by simple email, and can be processed in diff/merge. And all we as developers have to do is to load the information into the uniface datamodel, regenerate the DSL and pass it back to the end-users for proof-reading in the next iteration. Please download the complete pack from www.uli-merkel.de to see more use cases for the DSLs

An example for specifying labels (returned from the end users, not 100% correct because quotes in quoted strings): datamodel SPRINT_TARIC "Grundlagen TARIC" entity TBL_ABG_ART "TBL_Abg_Art [T23000]" { field ABG_SATZ_KOMP_ANW_CODE "Code der Anwendbarke" label="Code Anwendbarkeit" field ABG_SATZ_KOMP_ID "Abgabenart-Id (TARIC" label="Abgabenart-Id" field AKRONYM "Abkürzung (TARIC2)" label="Abkürzung" field DAT_END "Datum Gültigkeitsend" label="Ende Gültigkeit" field DAT_START "Datum Gültigkeitsbeg" label="Anfang Gültigkeit" field KURZ_BESCHR "Kurztext (TARIC2)" label="Kurzbeschreibung" maybe we find a better one field MASS_EINH_ANW_CODE "Anwendbarer Code der" label="Maßeinheit "CODE"" field WAEHR_EINH_ANW_CODE "Anwendbarer Code der" label="Währung "CODE"" } ****************** but it's much faster to correct the errors (the DSL based editor will assist us) and load the whole bunch as to type all the label infos into the uniface repository.

I agree that filling the model is paintfull. A lot of click and mouse move. That's why in the CHUI times we did our own forms on the dictionnary. Rmemeber that the source are data in the database so you can use Uniface to create forms on the dictonnary. So our Mass Update form showed all fields with with their properties as records with their fields. Of course you have to be carefull to implement correct validation triggers to avoid putting garbage in the dictonnary.

daeneb said Rmemeber that the source are data in the database so you can use Uniface to create forms on the dictonnary

But it's still we, the developers, have to type all that stuff in. The trick with the DSL is: - let the customers do all the work, - have your DSL based editor to check for syntax-problems and solve these - and just load their modifications into the repository. If you have a look at the "sprint" screencasts from www.uli-merkel.de it's a matter of minutes to do so. The domain-experts do not have to learn uniface, they just have some easy to read textfile to process. If they like to have other keywords, it just takes minutes to change this.