diff --git a/.gitignore b/.gitignore
index 0303f5a..43b9a5b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -25,3 +25,9 @@ node_modules/
generated/
+
+
+
+*.orig
+
+*.out
diff --git a/CHANGELOG.md b/CHANGELOG.md
new file mode 100644
index 0000000..3f0f86a
--- /dev/null
+++ b/CHANGELOG.md
@@ -0,0 +1,22 @@
+# Change Log
+All notable changes to this project will be documented in this file. This change log is intended to follow the conventions of [keepachangelog.com](http://keepachangelog.com/).
+
+## Release 1.4.6, 2018-09-22
+
+Beta release; improved documentation.
+
+## Release 1.4.5, 2018-09-20
+
+Generation of skeleton Clojure webapp is now largely complete; this release is not the final 'beta' release of this functionality, but is a dummy run towards that release.
+
+## Release 1.4.1
+
+Release 1.4.1 adds a 'magnitude' element to entities, in order to provide a pragma for when
+to switch to asynchronous select widgets.
+
+It also provides a family of transforms, written in Clojure, to generate a skeleton Clojure
+web app from an ADL specification.
+
+## Release 1.4
+
+Release 1.4 adds an 'order' element as a possible child of the 'list' element, in order to specify the default order of lists. Otherwise unchanged from 1.3.
diff --git a/README.md b/README.md
index 602fa9d..f7e2e5d 100644
--- a/README.md
+++ b/README.md
@@ -4,9 +4,23 @@ A language for describing applications, from which code can be automatically gen
[](https://clojars.org/adl)
+## Contents
+
+1. [Usage](#user-content-usage)
+2. [History](#user-content-history)
+3. [Why this is a good idea](#user-content-why-this-is-a-good-idea)
+4. [What exists](#user-content-what-exists)
+5. [Future direction](#user-content-future-direction)
+6. [Contributing](#user-content-contributing)
+
+
## Usage
-A document describing the proposed application should be written in XML using the DTD `resources/schemas/adl-1.4.1.dtd`. It may then be transformed into a C# or Java application using the XSL transforms, see **History** below, but this code is very out of date and the resulting application is unlikely to be very usable. Alternatively, it can be transformed into a Clojure [Luminus](http://www.luminusweb.net/) application using the Clojure transformation, as follows:
+A document describing the proposed application should be written in XML using the DTD `resources/schemas/adl-1.4.1.dtd`. It may then be transformed into a C# or Java application using the XSL transforms, see **History** below, but this code is very out of date and the resulting application is unlikely to be very usable.
+
+### Clojure
+
+Alternatively, it can be transformed into a Clojure [Luminus](http://www.luminusweb.net/) application using the Clojure transformation, as follows:
simon@fletcher:~/workspace/adl$ java -jar target/adl-[VERSION]-standalone.jar --help
Usage: java -jar adl-[VERSION]-standalone.jar -options [adl-file]
@@ -17,7 +31,61 @@ A document describing the proposed application should be written in XML using th
-p, --path [PATH]: The path under which generated files should be written; (default: generated)
-v, --verbosity [LEVEL], : Verbosity level - integer value required; (default: 0)
-This is not yet complete but it is at an advanced stage and already produces code which is useful.
+Of more simply using the [leiningen](https://leiningen.org/) plugin, see [lein-adl](https://github.com/simon-brooke/lein-adl).
+
+#### What is generated for Clojure
+
+The following files are generated:
+
+* `resources/sql/queries.auto.sql` - [HugSQL](https://www.hugsql.org/) queries for selection, insertion, modification and deletion of records of all entities described in the ADL file.
+* `resources/sql/[application-name].postgres.sql` - [Postgres](https://www.postgresql.org/) database initialisation script including tables for all entities, convenience views for all entities, all necessary link tables and referential integrity constraints.
+* `resources/templates/auto/*.html` - [Selmer](https://github.com/yogthos/Selmer) templates for each form or list list specified in the ADL file (pages are not yet handled).
+* `src/clj/[application-name]/routes/auto.clj` - [Compojure]() routes for each form or list list specified in the ADL file (pages are not yet handled).
+* `src/clj/[application-name]/routes/auto-json.clj` - [Compojure]() routes returning JSON responses for each query generated in `resources/sql/queries.auto.sql`.
+
+*You are strongly advised never to edit any of these files*.
+
+* To override any query, add that query to a file `resources/sql/queries.sql`
+* To add additional material (for example reference data) to the database initialisation, add it to a separate file or a family of separate files.
+* To override any template, copy the template file from `resources/templates/auto/` to `resources/templates/` and edit it there.
+* To override any route, write a function of the same name in the namespace `[application-name].routes.manual`.
+
+#### Some assembly required
+
+It would be very nice to be able to type
+
+ lein new luminus froboz +adl
+
+and have a new Luminus project initialised with a skeleton ADL file, and all the glue needed to make it work, already in place. [This is planned](https://github.com/simon-brooke/adl/issues/6), but just at present it isn't there and you will have to do some work yourself.
+
+Where, in `src/clj/[application-name]/db/core.clj` [Luminus]() would autogenerate
+
+ (conman/bind-connection *db* "sql/queries.sql")
+
+You should substitute
+
+ (conman/bind-connection *db* "sql/queries.auto.sql" "sql/queries.sql")
+ (hugsql/def-sqlvec-fns "sql/queries.auto.sql")
+
+You should add the following two stanzas to the `app-routes` definition in `src/clj/[project-name]/handler.clj`.
+
+ (-> #'auto-rest-routes
+ (wrap-routes middleware/wrap-csrf)
+ (wrap-routes middleware/wrap-formats))
+ (-> #'auto-selmer-routes
+ (wrap-routes middleware/wrap-csrf)
+ (wrap-routes middleware/wrap-formats))
+
+Finally, you should prepend `"adl"` to the vector of `prep-tasks` in the `uberjar` profile of you `project.clj` file, thus:
+
+ :profiles {:uberjar {:omit-source true
+ :prep-tasks ["adl"
+ "compile"
+ ["npm" "install"]
+ ["cljsbuild" "once" "min"]]
+ ...
+
+The above assumes you are using Luminus to initialise your project; if you are not, then I expect that you are confident enough using Clojure that you can work out where these changes should be made in your own code.
## History
@@ -73,6 +141,8 @@ Back in 2007, XSLT seemed a really good technology for doing this sort of thing.
Ultimately ADL will probably transition from XML to [EDN](https://github.com/edn-format/edn).
+I plan to generate a [re-frame](https://github.com/Day8/re-frame) skeleton, to support client side and [React Native](https://facebook.github.io/react-native/) applications, but this is not yet in place.
+
This doesn't mean you can't pick up the framework and write transforms in other languages and/or to other language ecosystems. In fact, I'd encourage you to do so.
## Contributing
diff --git a/RELEASENOTES.md b/RELEASENOTES.md
deleted file mode 100644
index 2cb9c4c..0000000
--- a/RELEASENOTES.md
+++ /dev/null
@@ -1,12 +0,0 @@
-# Release 1.4.1
-
-Release 1.4.1 adds a 'magnitude' element to entities, in order to provide a pragma for when
-to switch to asynchronous select widgets.
-
-It also provides a family of transforms, written in Clojure, to generate a skeleton Clojure
-web app from an ADL specification.
-
-# Release 1.4
-
-Release 1.4 adds an 'order' element as a possible child of the 'list' element, in order to specify
-the default order of lists. Otherwise unchanged from 1.3.
diff --git a/doc/intro.md b/doc/intro.md
deleted file mode 100644
index 2e730b8..0000000
--- a/doc/intro.md
+++ /dev/null
@@ -1,765 +0,0 @@
-# Introduction
-
-**NOTE**: *this markdown was automatically generated from `adl_user_doc.html`, which in turn was taken from the Wiki page on which this documentation was originally written.*
-
-Application Description Language framework
-==========================================
-
-## Contents
---------
-
-* [1 What is Application Description Language?](#What_is_Application_Description_Language.3F)
-* [2 Current versions](#Current_versions)
-* [3 What is the Application Description Language Framework?](#What_is_the_Application_Description_Language_Framework.3F)
-* [4 Why does it matter?](#Why_does_it_matter.3F)
- * [4.1 Automated Application Generation](#Automated_Application_Generation)
- * [4.2 Integration with hand-written code](#Integration_with_hand-written_code)
- * [4.3 High quality auto-generated code](#High_quality_auto-generated_code)
-* [5 What can the Application Description Language framework now do?](#What_can_the_Application_Description_Language_framework_now_do.3F)
- * [5.1 adl2entityclass.xsl](#adl2entityclass.xsl)
- * [5.2 adl2mssql.xsl](#adl2mssql.xsl)
- * [5.3 adl2views.xsl](#adl2views.xsl)
- * [5.4 adl2controllerclasses.xsl](#adl2controllerclasses.xsl)
- * [5.5 adl2hibernate.xsl](#adl2hibernate.xsl)
- * [5.6 adl2pgsql.xsl](#adl2pgsql.xsl)
-* [6 So is ADL a quick way to build Monorail applications?](#So_is_ADL_a_quick_way_to_build_Monorail_applications.3F)
-* [7 Limitations on ADL](#Limitations_on_ADL)
- * [7.1 Current limitations](#Current_limitations)
- * [7.1.1 Authentication model](#Authentication_model)
- * [7.1.2 Alternative Verbs](#Alternative_Verbs)
- * [7.2 Inherent limitations](#Inherent_limitations)
-* [8 ADL Vocabulary](#ADL_Vocabulary)
- * [8.1 Basic definitions](#Basic_definitions)
- * [8.1.1 Permissions](#Permissions)
- * [8.1.2 Data types](#Data_types)
- * [8.1.3 Definable data types](#Definable_data_types)
- * [8.1.4 Page content](#Page_content)
- * [8.2 The Elements](#The_Elements)
- * [8.2.1 Application](#Application)
- * [8.2.2 Definition](#Definition)
- * [8.2.3 Groups](#Groups)
- * [8.2.4 Enities and Properties](#Enities_and_Properties)
- * [8.2.5 Options](#Options)
- * [8.2.6 Permissions](#Permissions_2)
- * [8.2.7 Pragmas](#Pragmas)
- * [8.2.8 Prompts, helptexts and error texts](#Prompts.2C_helptexts_and_error_texts)
- * [8.2.9 Forms, Pages and Lists](#Forms.2C_Pages_and_Lists)
-* [9 Using ADL in your project](#Using_ADL_in_your_project)
- * [9.1 Selecting the version](#Selecting_the_version)
- * [9.2 Integrating into your build](#Integrating_into_your_build)
- * [9.2.1 Properties](#Properties)
- * [9.2.2 Canonicalisation](#Canonicalisation)
- * [9.2.3 Generate NHibernate mapping](#Generate_NHibernate_mapping)
- * [9.2.4 Generate SQL](#Generate_SQL)
- * [9.2.5 Generate C# entity classes ('POCOs')](#Generate_C.23_entity_classes_.28.27POCOs.27.29)
- * [9.2.6 Generate Monorail controller classes](#Generate_Monorail_controller_classes)
- * [9.2.7 Generate Velocity views for use with Monorail](#Generate_Velocity_views_for_use_with_Monorail)
-
-## What is Application Description Language?
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
-Application Description Language is an XML vocabulary, defined in a [Document Type Definition](http://en.wikipedia.org/wiki/Document_Type_Definition "http://en.wikipedia.org/wiki/Document_Type_Definition"), which declaratively describes the entities in an application domain, their relationships, and their properties. Because ADL is defined in a formal definition which can be parsed by XML editors, any DTD-aware XML editor (such as that built into Visual studio) can provide context-sensitive auto-completion for ADL, making the vocabulary easy to learn and to edit. It would perhaps be desirable to replace this DTD at some future stage with an XML Schema, since it is desirable to be able to mix HTML in with ADL in the same document.
-
-ADL is thus a '[Fourth Generation Language](http://en.wikipedia.org/wiki/Fourth-generation_programming_language "http://en.wikipedia.org/wiki/Fourth-generation_programming_language")' as understood in the 1980s - an ultra-high level language for a specific problem domain; but it is a purely declarative 4GL.
-
-## Current versions
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
-* The current STABLE version of ADL is 1.1.
- * The namespace URL for ADL 1.1 is [http://libs.cygnets.co.uk/adl/1.1/](http://libs.cygnets.co.uk/adl/1.1/ "http://libs.cygnets.co.uk/adl/1.1/")
- * Transforms for ADL 1.1 can be found at [http://libs.cygnets.co.uk/adl/1.1/ADL/transforms/](http://libs.cygnets.co.uk/adl/1.1/ADL/transforms/ "http://libs.cygnets.co.uk/adl/1.1/ADL/transforms/")
- * The document type definition for ADL 1.1 can be found at [http://libs.cygnets.co.uk/adl/1.1/ADL/schemas/adl-1.1.dtd](http://libs.cygnets.co.uk/adl/1.1/ADL/schemas/adl-1.1.dtd "http://libs.cygnets.co.uk/adl/1.1/ADL/schemas/adl-1.1.dtd")
-* the current UNSTABLE version of ADL is 1.2. The namespace URL for ADL 1.2 is [http://libs.cygnets.co.uk/adl/1.2/](http://libs.cygnets.co.uk/adl/1.2/ "http://libs.cygnets.co.uk/adl/1.2/")
- * The namespace URL for ADL 1.2 is [http://libs.cygnets.co.uk/adl/1.2/](http://libs.cygnets.co.uk/adl/1.2/ "http://libs.cygnets.co.uk/adl/1.2/")
- * Transforms for ADL 1.2 can be found at [http://libs.cygnets.co.uk/adl/1.2/ADL/transforms/](http://libs.cygnets.co.uk/adl/1.2/ADL/transforms/ "http://libs.cygnets.co.uk/adl/1.2/ADL/transforms/")
- * The document type definition for ADL 1.2 can be found at [http://libs.cygnets.co.uk/adl/1.2/ADL/schemas/adl-1.2.dtd](http://libs.cygnets.co.uk/adl/1.2/ADL/schemas/adl-1.2.dtd "http://libs.cygnets.co.uk/adl/1.2/ADL/schemas/adl-1.2.dtd")
-
-\ What is the Application Description Language Framework?
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
-The Application Description Language Framework is principally a set of XSL transforms which transform a single ADL file into all the various source files required to build an application.
-
-## Why does it matter?
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
-The average data driven web application comprises pages (lists) which show lists of entities, pages (forms) that edit instances of entities, and pages (inspectors) that show details of instances of entities. That comprises 100% of many applications and 90% of others; traditionally, even with modern tools like Monorail, coding these lists, forms and inspectors has taken 90% of the development effort.
-
-I realised about three years ago that I was doing essentially the same job over and over again, and I don't like doing that. I see my mission in life as being to automate people out of jobs, and that includes me. So the object of the Application Description Language is to raise the level of abstraction with which we define data driven applications one level higher, and automate the process we have thus far done as programmers. This isn't a new insight; it's fundamentally the same insight that led machine code programmers to develop the first macro assembler, and led assembly language programmers to write the first high level language compiler. Computers are tools which can be used to mung information from one representation to another, and all we need to do is to work out how to write a powerful enough representation, and how to transform it.
-
-The whole purpose of ADL is to increase productivity - mine, and that of anyone else who chooses to follow me down this path. It is pragmatic technology - it is designed to be an 80/20 or 90/10 solution, taking the repetitious grunt-work out of application development so that we can devote more time to the fun, interesting and novel bits. It is not intended to be an academic, perfect, 100% solution - although for many applications it may in practice be a 100% solution.
-
-### Automated Application Generation
-
-Thus to create a new application, all that should be necessary is to create a new ADL file, and to compile it using a single, standardised \[[NAnt](http://nant.sourceforge.net/ "http://nant.sourceforge.net/")\] (or \[[Ant](http://ant.apache.org/ "http://ant.apache.org/")\]) build file using scripts already created as part of the framework. All these scripts (with the exception of the PSQL one, which was pre-existing) have been created as part of the [C1873 - SRU - Hospitality](http://wiki.cygnets.co.uk/index.php/C1873_-_SRU_-_Hospitality "C1873 - SRU - Hospitality") contract, but they contain almost no SRU specific material (and what does exist has been designed to be factored out). Prototype 1 of the SRU Hospitality Application contains no hand-written code whatever - all the application code is automatically generated from the single ADL file. The one exception to this rule is the CSS stylesheet which provides look-and-feel and branding.
-
-### Integration with hand-written code
-
-Application-specific procedural code, covering specific business procedures, may still need to be hand written; the code generated by the ADL framework is specifically designed to make it easy to integrate hand-written code. Thus for example the C# entity controller classes generated are intentionally generated as _partial_ classes, so that they may be complemented by other partial classes which may be manually maintained and held in a version control system.
-
-### High quality auto-generated code
-
-One key objective of the framework is that the code which is generated should be as clear and readable - and as well commented - as the best hand-written code. Consider this example:
-
- ///
- /// Store the record represented by the parameters passed in an HTTP service
- /// Without Id -> it's new, I create a new persistent object;
- /// With Id -> it's existing, I update the existing persistent object
- ///
- \[AccessibleThrough( Verb.Post)\]
- public void Store()
- {
- ISession hibernator =
- NHibernateHelper.GetCurrentSession( Session\[ NHibernateHelper.USERTOKEN\],
- Session\[NHibernateHelper.PASSTOKEN\]);
-
- SRU.Hospitality.Entities.Event record;
-
-
- if ( Params\[ "instance.Date" \] == null)
- {
- AddError( "You must supply a value for Date");
- }
-
-
- if ( Params\[ "instance.Description" \] == null)
- {
- AddError( "You must supply a value for Description");
- }
-
-
-
- string id = Params\["instance.EventId"\];
-
- if ( String.IsNullOrEmpty( id))
- {
- /\* it's new, create persistent object */
- record = new SRU.Hospitality.Entities.Event();
-
- /\* perform any domain knowledge behaviour on the new record
- \* after instantiation */
- record.AfterCreationHook();
- }
- else
- {
- /\* it's existing, retrieve it */
- record =
- hibernator.CreateCriteria(typeof(Event))
- .Add(Expression.Eq("EventId", Int32.Parse(id)))
- .UniqueResult();
- }
-
- if ( record != null)
- {
- /\* perform any domain knowledge behaviour on the record prior to updating */
- record.BeforeUpdateHook();
-
- /\* actually update the record */
- BindObjectInstance( record, ParamStore.Form, "instance");
-
-
-
- /\* write the record to the database, in order to guarantee we have a valid key */
- hibernator.Save(record);
- hibernator.Flush();
-
- /\* perform any domain knowledge behaviour on the record after updating */
- record.AfterUpdateHook();
-
- PropertyBag\["username"\] = Session\[ NHibernateHelper.USERTOKEN\];
- PropertyBag\["instance"\] = record;
-
-
- RenderViewWithFailover("edit.vm", "edit.auto.vm");
- }
- else
- {
- throw new Exception( String.Format( "No record of type Event with key value {0} found", id));
- }
- }
-
-This means that it should be trivial to decide at some point in development of a project to manually modify and maintain auto-generated code.
-
-## What can the Application Description Language framework now do?
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
-Currently the framework includes:
-
-### adl2entityclass.xsl
-
-Transforms the ADL file into C# source files for classes which describe the entities in a manner acceptable to [NHibernate](http://www.hibernate.org/ "http://www.hibernate.org/"), a widely used Object/Relational mapping layer.
-
-### adl2mssql.xsl
-
-Transforms the ADL file into an SQL script in Microsoft SQL Server 2000 syntax which initialises the database required by the application, with all relationships, permissions, referential integrity constraints and so on.
-
-### adl2views.xsl
-
-Transforms the ADL file into [Velocity](http://velocity.apache.org/ "http://velocity.apache.org/") template files as used by the [Monorail](http://www.castleproject.org/monorail/index.html "http://www.castleproject.org/monorail/index.html") framework, one template each for all the lists, forms and inspectors described in the ADL.
-
-### adl2controllerclasses.xsl
-
-Transforms the ADL file into a series of C# source files for classes which are controllers as used by the Monorail framework.
-
-### adl2hibernate.xsl
-
-Transforms the ADL file into a Hibernate mapping file, used by the [Hibernate](http://www.hibernate.org/ "http://www.hibernate.org/") ([Java](http://java.sun.com/ "http://java.sun.com")) and [NHibernate](http://www.hibernate.org/ "http://www.hibernate.org/") (C#) Object/Relational mapping layers. This transform is relatively trivial, since ADL is not greatly different from being a superset of the Hibernate vocabulary - it describes the same sorts of things but in more detail.
-
-### adl2pgsql.xsl
-
-Transforms the ADL file into an SQL script in [Postgres](http://www.postgresql.org/ "http://www.postgresql.org/") 7 syntax which initialises the database required by the application, with all relationships, permissions, referential integrity constraints and so on.
-
-## So is ADL a quick way to build Monorail applications?
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
-Yes and no.
-
-ADL _is_ a quick way to build Monorail applications, because it seemed to me that as Monorail/NHibernate are technologies that the company is adopting and it would be better to work with technologies with which we already have expertise - it's no good doing these things if other people can't maintain them afterwards.
-
-However ADL wasn't originally conceived with Monorail in mind. It was originally intended to generated LISP for [CLHTTPD](http://www.cl-http.org:8001/cl-http/ "http://www.cl-http.org:8001/cl-http/"), and I have a half-finished set of scripts to generate Java as part of the Jacquard2 project which I never finished. Because ADL is at a level of abstraction considerably above any [3GL](http://en.wikipedia.org/wiki/Third-generation_programming_language "http://en.wikipedia.org/wiki/Third-generation_programming_language"), it is inherently agnostic to what 3GL it is compiled down to - so that it would be as easy to write transforms that compiled ADL to [Struts](http://struts.apache.org/ "http://struts.apache.org/") or [Ruby on Rails](http://www.rubyonrails.org/ "http://www.rubyonrails.org/") as to C#/Monorail. More importantly, ADL isn't inherently limited to Web applications - it doesn't actually know anything about the Web. It should be possible to write transforms which compile ADL down to Windows native applications or to native applications for mobile phones (and, indeed, if we did have those transforms then we could make all our applications platform agnostic).
-
-## Limitations on ADL
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
-### Current limitations
-
-Although I've built experimental systems before using ADL, the SRU project is the first time I've really used it in anger. There are some features I need which it can't yet represent.
-
-#### Authentication model
-
-For SRU, I have implemented an authentication model which authenticates the user against real database user accounts. I've done this because I think, in general, this is the correct solution, and because without this sort of authentication you cannot implement table-layer security. However most web applications use application layer authentication rather than database layer authentication, and I have not yet written controller-layer code to deal with this. So unless you do so, ADL applications can currently only authenticate at database layer.
-
-ADL defines field-level permissions, but the current controller generator does not implement this.
-
-#### Alternative Verbs
-
-Generically, with an entity form, one needs to be able to save the record being edited, and one (often) needs to be able to delete it. But sometimes one needs to be able to do other things. With SRU, for example, there is a need to be able to export event data to [Perfect Table Plan](http://www.perfecttableplan.com/ "http://www.perfecttableplan.com/"), and to reimport data from Perfect Table Plan. This will need custom buttons on the event entity form, and will also need hand-written code at the controller layer to respond to those buttons.
-
-Also, a person will have, over the course of their interaction with the SRU, potentially many invitations. In order to access those invitations it will be necessary to associate lists of dependent records with forms. Currently ADL cannot represent these.
-
-### Inherent limitations
-
-At this stage I doubt whether there is much point in extending ADL to include a vocabulary to describe business processes. It would make the language much more complicated, and would be unlikely to be able to offer a significantly higher level of abstraction than current 3GLs. If using ADL does not save work, it isn't worth doing it in ADL; remember this is conceived as an 80/20 solution, and you need to be prepared to write the 20 in something else.
-
-## ADL Vocabulary
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
-This section of this document presents and comments on the existing ADL document type definition (DTD).
-
-### Basic definitions
-
-The DTD starts with some basic definitions
-
-
-
-
-
-
-
-
-
-
--->
-
-
-#### Permissions
-
-Key to any data driven application is who has authority to do what to what: 'permissions'.
-
-
-
-
-#### Data types
-
-ADL needs to know what type of data can be stored on different properties of different entities. The data types were originally based on JDBC data types:
-
-
-
-#### Definable data types
-
-However, in order to be able to do data validation, it's useful to associate rules with data types. ADL has the concept of definable data types, to allow data validation code to be generated from the declarative description. These definable data types are used in the ADL application, for example, to define derived types for phone numbers, email addresses, postcodes, and range types.
-
-
-
-
-
-
-
-
-
-
-
-
-#### Page content
-
-Pages in applications typically have common, often largely static, sections above, below, to the left or right of the main content which incorporates things like branding, navigation, and so on. This can be defined globally or per page. The intention is that the `head`, `top` and `foot` elements in ADL should be allowed to contain arbitrary HTML, but currently I don't have enough skill with DTD design to know how to specify this.
-
-
-
-
-
-
-
-
-
-
-### The Elements
-
-#### Application
-
-The top level element of an Application Description Language file is the application element:
-
-
-
-
-
-#### Definition
-
-In order to be able to use defined types, you need to be able to provide definitions of these types:
-
-
-
-
-
-#### Groups
-
-In order to be able to user permissions, we need to define who has those permissions. Groups in ADL map directly onto groups/roles at SQL level, but the intention with ADL is that groups should be defined hierarchically.
-
-
-
-
-
-
-
-
-#### Enities and Properties
-
-A thing-in-the-domain has properties. Things in the domain fall into regularities, groups of things which share similar collections of properties, such that the values of these properties may have are constrained. This is a representation of the world which is not perfect, but which is sufficiently useful to be recognised by the software technologies which ADL abstracts, so we need to be able to define these. Hence we have entities and properties/
-
-
-
-
-
-
-
-
-
-
-#### Options
-
-Sometimes a property has a constrained list of specific values; this is represented for example in the enumerated types supported by many programming languages. Again, we need to be able to represent this.
-
-
-
-
-
-
-#### Permissions
-
-Permissions define policies to allow groups of users to access forms, pages, fields (not yet implemented) or entities. Only entity permissions are enforced at database layer, and field protection is not yet implemented at controller layer. But the ADL allows it to be described, and future implementations of the controller generating transform will do this.
-
-
-
-
-
-#### Pragmas
-
-Pragmas are currently not used at all. They are there as a possible means to provide additional controls on forms, but may not be the correct solutions for that.
-
-
-
-
-
-#### Prompts, helptexts and error texts
-
-When soliciting a value for a property from the user, we need to be able to offer the user a prompt to describe what we're asking for, and we need to be able to offer that in the user's preferred natural language. Prompts are typically brief. Sometimes, however, we need to give the user a more extensive description of what is being solicited - 'help text'. Finally, if the data offered by the user isn't adequate for some reason, we need ways of feeding that back. Currently the only error text which is carried in the ADL is 'ifmissing', text to be shown if the value for a required property is missing. All prompts, helptexts and error texts have locale information, so that it should be possible to generate variants of all pages for different natural languages from the same ADL.
-
-
-
-
-
-
-
-
-
-
-
-
-
-#### Forms, Pages and Lists
-
-The basic pages of the user interface. Pages and Forms by default show fields for all the properties of the entity they describe, or they may show only a listed subset. Currently lists show fields for only those properties which are 'user distinct'. Forms, pages and lists may each have their own head, top and foot content, or they may inherit the content defined for the application.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## Using ADL in your project
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
-### Selecting the version
-
-Current versions of ADL are given at the top of this document. Historical versions are as follows:
-
-* **Version 0.1**: Used by the SRU Hospitality application only. The Hospitality Application will be upgraded to the current version whenever it has further work done on it.
- * You cannot access Version 1.0 at all, as nothing in current development should be using it. It is in CVS as part of the SRU Hospitality application
- * As soon as SRU Hospitality has been updated to **stable**, version 0.1 will be unmaintained.
-* **Version 0.3**: Identical to Version 1.0, except that the obsolete _transforms01_ directory has not been removed.
- * You can access 0.3, should you need to, here: [http://libs.cygnets.co.uk/adl/0.3/ADL/](http://libs.cygnets.co.uk/adl/0.3/ADL/ "http://libs.cygnets.co.uk/adl/0.3/ADL/")
- * I do not plan to maintain 0.3 even for bugfixes; you should ensure your project builds with 1.0
-* **Version 1.0**: Identical to Version 3.0, except tidied up.
- * * the obsolete _transforms01_ directory has been removed.
- * _adl2entityclass.xslt_ has been renamed to _adl2entityclasses.xslt_, for consistency
- * This is the current **stable** branch; it is the HEAD branch in CVS.
- * If there are bugs, I (sb) will fix them.
- * If you want new functionality, it belongs in 'unstable'.
- * You can access 1.0 here: [http://libs.cygnets.co.uk/adl/1.0/ADL/](http://libs.cygnets.co.uk/adl/1.0/ADL/ "http://libs.cygnets.co.uk/adl/1.0/ADL/")
- * Projects using ADL 1.0 should be built with the 1.0 version of CygnetToolkit
-* **unstable**: this is the current development branch, the branch tagged **b_development** in CVS.
- * It should be backwards compatible with 1.0 (i.e. anything which builds satisfactorily with 1.0 should also build with unstable)
- * It may have additional features
- * It is not guaranteed to work, and before a final release of a product to a customer we may wish to move changes into a new 'stable' branch.
- * You can access the unstable branch here: [http://libs.cygnets.co.uk/adl/unstable/ADL/](http://libs.cygnets.co.uk/adl/unstable/ADL/ "http://libs.cygnets.co.uk/adl/unstable/ADL/")
- * The version at that location is automatically updated from CVS every night
- * Projects using the **b_development** branch of ADL should be built against the **b_development** branch of CygnetToolkit.
-
-### Integrating into your build
-
-To use ADL, it is currently most convenient to use NAnt. It is probably possible to do this with MSBuild, but as of yet I don't know how.
-
-#### Properties
-
-For the examples given here to work, you will need to set up at least the following properties in your NAnt `.build` file:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-where, obviously, **YourProjectName**, **YourSourceDir** and **YourADL.adl.xml** stand in for the actual names of your project, your source directory (relative to your solution directory, where the .build file is) and your ADL file, respectively. Note that if it is to be used as an assembly name, the project name should include neither spaces, hyphens nor periods. If it must do so, you should give an assembly name which does not, explicitly.
-
-#### Canonicalisation
-
-The first thing you need to do with your ADL file is canonicalise it. You should generally not need to alter this, you should copy and paste it verbatim:
-
-
-
-
-
-#### Generate NHibernate mapping
-
-You should generally not need to alter this at all, just copy and paste it verbatim:
-
-
-
-
-
-#### Generate SQL
-
-
-
-
-
-#### Generate C# entity classes ('POCOs')
-
-Note that for this to work you must have the following:
-
-* '[Artistic Style](http://astyle.sourceforge.net/ "http://astyle.sourceforge.net/")' installed as `c:\Program Files\astyle\bin\astyle.exe`
-
-
-
-
-
-
-
-
-
-
-
-
-
-#### Generate Monorail controller classes
-
-Note that for this to work you must have
-
-* '[Artistic Style](http://astyle.sourceforge.net/ "http://astyle.sourceforge.net/")' installed as `c:\Program Files\astyle\bin\astyle.exe`
-* The 'fetchtasks' target from the 'entity classes' stanza, above.
-
-
-
-
-
-
-
-
-
-#### Generate Velocity views for use with Monorail
-
-Note that for this to work you must have
-
-* The 'fetchtasks' target from the 'entity classes' stanza, above.
-
-
-
-
-
-
-
-
-
diff --git a/docs/adl.main.html b/docs/adl.main.html
new file mode 100644
index 0000000..7c8aea4
--- /dev/null
+++ b/docs/adl.main.html
@@ -0,0 +1,10 @@
+
+adl.main documentation
Application Description Language - command line invocation.
+
-main
(-main & args)
Parses options and arguments. Expects as args the path-name of one or more ADL files.
+
adl->canonical
A function which takes ADL text as its single argument and returns canonicalised ADL text as its result.
+
canonicalise
(canonicalise filepath)
Canonicalise the ADL document indicated by this filepath (if it is not already canonical) and return a path to the canonical version.
+
cli-options
Command-line interface options
+
process
(process options)
Process these parsed options.
+
usage
(usage parsed-options)
Show a usage message. parsed-options should be options as parsed by clojure.tools.cli
+
\ No newline at end of file
diff --git a/docs/adl.to-cache.html b/docs/adl.to-cache.html
new file mode 100644
index 0000000..a6437ab
--- /dev/null
+++ b/docs/adl.to-cache.html
@@ -0,0 +1,7 @@
+
+adl.to-cache documentation
Application Description Language: generate caching layer for database requests.
+
file-header
(file-header application)
Generate an appropriate file header for JSON routes for this application.
+
handler
(handler query)
Generate declarations for handlers for this query. Cache handlers are needed only for select queries.
+
to-cache
(to-cache application)
Generate a /cache.clj file for this application.
+
\ No newline at end of file
diff --git a/docs/adl.to-hugsql-queries.html b/docs/adl.to-hugsql-queries.html
new file mode 100644
index 0000000..f6a7565
--- /dev/null
+++ b/docs/adl.to-hugsql-queries.html
@@ -0,0 +1,18 @@
+
+adl.to-hugsql-queries documentation
Application Description Language - generate HUGSQL queries file.
+
delete-query
(delete-query entity)
Generate an appropriate delete query for this entity
+
expanded-token
*TODO: write docs
+
foreign-queries
(foreign-queries entity application)
Generate any foreign entity queries for this entity of this application.
+
generate-documentation
(generate-documentation query)
Generate, as a string, appropriate documentation for a function wrapping this query map.
+
insert-query
(insert-query entity)
Generate an appropriate insert query for this entity. TODO: this depends on the idea that system-unique properties are not insertable, which is… dodgy.
+
list-query
(list-query entity)
Generate a query to list records in the table represented by this entity. Parameters :limit and :offset may be supplied. If not present limit defaults to 100 and offset to 0.
Generate an appropriate where clause for queries on this entity; if properties are passed, filter on those properties, otherwise the key properties.
+
\ No newline at end of file
diff --git a/docs/adl.to-json-routes.html b/docs/adl.to-json-routes.html
new file mode 100644
index 0000000..916a080
--- /dev/null
+++ b/docs/adl.to-json-routes.html
@@ -0,0 +1,12 @@
+
+adl.to-json-routes documentation
Generate declarations for handlers from query with this query-key in this queries-map taken from within this application. This method must follow the structure of to-hugsql-queries/queries quite closely, because we must generate the same names.
+
make-handlers-map
(make-handlers-map application)
Analyse this application and generate from it a map of the handlers to be output.
+
to-json-routes
(to-json-routes application)
Generate a /routes/auto-json.clj file for this application.
+
\ No newline at end of file
diff --git a/docs/adl.to-psql.html b/docs/adl.to-psql.html
new file mode 100644
index 0000000..34be32e
--- /dev/null
+++ b/docs/adl.to-psql.html
@@ -0,0 +1,26 @@
+
+adl.to-psql documentation
Compose the FROM list of an SQL SELECT statement for a convenience view of this entity within this application, recursively. top-level? should be set only on first invocation.
Compose an SQL WHERE clause for a convenience view of this entity within this application. TODO: does not correctly compose links at one stage down the tree. See lv_electors, lv_followuprequests for examples of the problem.
+
construct-link-property
(construct-link-property entity)
Create a dummy property for a link-table referencing this entity, in order that the field generation functions already defined may be applied to it.
+
emit-application
(emit-application application)
Emit all SQL declarations required to initialise a Postgres database for this application.
Emit a link table for the specified property of the entity e1 within this application, provided that such a table has not already been emitted from the other end. The argument emitted-link-tables contains an atom which references a set of the names of all those link tables which have already been emitted, and this is modified in the execution of this function.
Emit an appropriate grant of permissions on this table-name at this privilege level given these permissions. privilege is expected to be one of #{:SELECT :INSERT :UPDATE :DELETE}. TODO: more thought needed here.
Emit a table declaration for this entity of this application, documented with this doc-comment if specified.
+
field-name
(field-name property)
Return the appropriate field name for this property. TODO: really belongs in adl-support.utils.
+
to-psql
(to-psql application)
Generate a complete Postgres database initialisation script for this application.
+
\ No newline at end of file
diff --git a/docs/adl.to-reframe.html b/docs/adl.to-reframe.html
new file mode 100644
index 0000000..be3171e
--- /dev/null
+++ b/docs/adl.to-reframe.html
@@ -0,0 +1,7 @@
+
+adl.to-reframe documentation
Generate an appropriate file header for a re-frame view.
+
generate-form
(generate-form form entity application)
Generate as re-frame this form taken from this entity of this application.
+
TODO: write it!
+
\ No newline at end of file
diff --git a/docs/adl.to-selmer-routes.html b/docs/adl.to-selmer-routes.html
new file mode 100644
index 0000000..50dcd41
--- /dev/null
+++ b/docs/adl.to-selmer-routes.html
@@ -0,0 +1,21 @@
+
+adl.to-selmer-routes documentation
Compose Clojure code to fetch data to populate this auxlist of a form editing a record of this entity within this application.
+
compose-fetch-record
(compose-fetch-record e a)
Compose Clojure code to retrieve a single record of entity e in application a; in addition to the fields of the record in the database, the record should also contain the values of the link and list properties of the entity, retrieved from their tables. TODO: what about entity properties?.
Compose Clojure code to fetch from the database menu options for this property within this application.
+
file-header
(file-header application)
*TODO: write docs
+
generate-handler-resolver
(generate-handler-resolver application)
Dodgy, dodgy, dodgy. Generate code which will look up functions in the manual and in this namespace. I’m sure someone who really knew what they were doing could write this more elegantly.
+
handler-name
(handler-name f e a m)
Generate the name of the appropriate handler function for form f of entity e of application a for method m, where f, e, and a are expected to be elements and m is expected to be one of the keywords :put:get.
+
make-defroutes
(make-defroutes application)
Generate a defroutes declaration for all routes of all forms, pages and lists within this application.
+
make-form-get-handler-content
(make-form-get-handler-content f e a n)
Compose Clojure code to form body of an HTTP GET handler for the form f of the entity e within application a. The argument n is not used.
+
make-form-post-handler-content
(make-form-post-handler-content f e a n)
Generate the body of the post handler for the form f of entity e in application a. The argument n is bound to the name of the function, but is not currently used.
+
Literally the only thing the post handler has to do is to execute the database store operation. Then it can hand off to the get handler.
+
make-get-handler
(make-get-handler f e a)
Generate a Clojure function to handle HTTP GET requests for form, list or page f of entity e within application a.
+
make-handlers
(make-handlers e application)
Generate all the Selmer route handlers for all the forms, lists and pages of the entity e within this application.
+
make-list-get-handler-content
(make-list-get-handler-content f e a n)
Compose Clojure code to form body of an HTTP GET handler for the list f of the entity e within application a. The argument n is ignored.
+
make-page-get-handler-content
(make-page-get-handler-content f e a n)
Compose Clojure code to form body of an HTTP GET handler for the page f of the entity e within application a. The argument n is ignored.
+
make-post-handler
(make-post-handler f e a)
Generate an HTTP POST handler for the page, form or list f of the entity e of application a.
+
make-route
(make-route m n)
Make a route for method m to request the resource with name n.
+
to-selmer-routes
(to-selmer-routes application)
Generate a /routes/auto.clj file for this application.
+
\ No newline at end of file
diff --git a/docs/adl.to-selmer-templates.html b/docs/adl.to-selmer-templates.html
new file mode 100644
index 0000000..9067370
--- /dev/null
+++ b/docs/adl.to-selmer-templates.html
@@ -0,0 +1,43 @@
+
+adl.to-selmer-templates documentation
Application Description Language - generate Selmer templates for the HTML pages implied by an ADL file.
+
application-to-template
(application-to-template application)
*TODO: write docs
+
back-link
(back-link content url)
Generate a retrograde primary navigation link with this content to this url, indicating a backward move through the appliication.
+
big-link
(big-link content url)
Generate a primary navigation link with this content to this url. TODO: should be renamed. primary-link would be better.
+
compose-form-auxlist
(compose-form-auxlist auxlist form entity application)
Compose an auxiliary list from this auxlist specification of dependent records (i.e. the far side of a one-to-many link) of the record of this entity within this application being edited in this form
+
compose-form-auxlists
(compose-form-auxlists form entity application)
Generate all auxiliary lists required for this form of this entity within this application.
+
compose-form-content
(compose-form-content form entity application)
Compose the content for this form of this entity within this application.
+
compose-form-extra-head
(compose-form-extra-head form entity application)
Compose any extra-head declarations (i.e. special Javascript tags) required for this form of this entity within this application.
+
compose-form-extra-tail
(compose-form-extra-tail form entity application)
Compose any extra-tail declarations (i.e. special Javascript tags) required for this form of this entity within this application.
+
compose-if-member-of-tag
(compose-if-member-of-tag privilege & elts)
Generate an appropriate ifmemberof tag (see adl-support.tags) given this privilege for the ADL elements listed in elts, which may be fields, properties, list, forms, pages or entities.
+
compose-input-widget-para
(compose-input-widget-para property form entity application widget-name)
Generate an input widget for this field-or-property of this form for this entity taken from within this application, in context of a para also containing its label.
+
compose-list-search-widget
(compose-list-search-widget field entity)
Compose a list search widget for this field referencing a property within this entity.
+
compose-readable-or-not-authorised
(compose-readable-or-not-authorised p f e a w)
Compose content to emit if the user is not authorised to write, or not authorised to read, property p in form, list or page f of entity e within application a, while generating a widget with id w.
+
compose-widget-para
(compose-widget-para p f e a w content)
Compose a widget paragraph for property p in form, list or page f of entity e within application a, with id w and this content.
+
csrf-widget
(csrf-widget)
For the present, just return the standard cross site scripting protection field statement
+
delete-widget
(delete-widget form entity application)
Return an appropriate ‘save’ widget for this form operating on this entity taken from this application.
Return the content of the file at resource-path, with these substitutions made into it in order. Substitutions should be pairs patternvalue, where pattern is a string, a char, or a regular expression.
Generate a header for a template file with this filename for this spec of this entity within this application.
+
form-to-template
(form-to-template form entity application)
Generate a template as specified by this form element for this entity, taken from this application. If form is nill, generate a default form template for the entity.
+
get-options
(get-options property form entity application)
Produce template code to get options for this property of this entity taken from this application.
+
get-size-for-widget
(get-size-for-widget property)
Return, as an integer, the fieldwidth for the input widget for this property.
+
list-tbody
(list-tbody source list-spec entity application)
Return a table body element for the list view for this list-spec of this entity within this application, using data from this source.
+
list-to-template
(list-to-template list-spec entity application)
Generate a template as specified by this list element for this entity, taken from this application. If list is nill, generate a default list template for the entity.
+
page-to-template
(page-to-template page entity application)
Generate a template as specified by this page element for this entity, taken from this application. If page is nil, generate a default page template for the entity.
+
TODO: not yet written.
+
save-widget
(save-widget form entity application)
Return an appropriate ‘save’ widget for this form operating on this entity taken from this application. TODO: should be suppressed unless a member of a group which can insert or edit.
+
select-field-name
(select-field-name entity)
*TODO: write docs
+
select-property
(select-property entity)
Return the property on which we will by default do a user search on this entity.
+
select-widget
(select-widget property form entity application)
Generate an HTML SELECT widget for this property of this entity within this application, to be used in this form. TODO: Many selectable things are potentially too numerous to be simply represented in a simple static SELECT, it needs some asynchronous fetching. See issue 47.
+
to-selmer-templates
(to-selmer-templates application)
Generate all Selmer templates implied by this ADL application spec.
+
widget
(widget field-or-property form entity application)
Generate a widget for this field-or-property of this form for this entity taken from within this application, in context of a para also containing its label.
Wrap this content in an if-member-of tag; if writeable? is true, allow those groups by whom it is writeable, else those by whom it is readable. context should be a sequence of adl elements from which permissions may be obtained.
Write a template file with this filename from this template in the context of this application.
+
\ No newline at end of file
diff --git a/docs/adl.to-swagger.html b/docs/adl.to-swagger.html
new file mode 100644
index 0000000..9df3d9b
--- /dev/null
+++ b/docs/adl.to-swagger.html
@@ -0,0 +1,5 @@
+
+adl.to-swagger documentation
\ No newline at end of file
diff --git a/docs/adl.validator.html b/docs/adl.validator.html
new file mode 100644
index 0000000..e75000f
--- /dev/null
+++ b/docs/adl.validator.html
@@ -0,0 +1,162 @@
+
+adl.validator documentation
Application Description Language: validator for ADL structure. TODO: this is at present largely a failed experiment.
+
all-data-types
*TODO: write docs
+
application-validations
*TODO: write docs
+
auxlist-validations
a subsidiary list, on which entities related to primary entities in the enclosing page or list are listed
+
+
property: the property of the enclosing entity that this list displays (obviously, must be of type=‘list’)
+
onselect: the form or page of the listed entity to call when an item from the list is selected
+
canadd: true if the user should be able to add records to this list
+
+
cascade-actions
actions which should be cascaded to dependent objects. All these values except ‘manual’ are taken from Hibernate and should be passed through the adl2hibernate mapping transparently. Relevent only for properties with type=‘entity’, type=‘link’ and type=‘list’
+
+
all: cascade delete, save and update
+
all-delete-orphan: see hibernate documentation; relates to transient objects only
+
delete: cascade delete actions, but not save and update
+
manual: cascading will be handled in manually managed code, code to handle cascading should not be generated
+
save-update: cascade save and update actions, but not delete.
+
+
complex-data-types
data types which are more complex than SimpleDataTypes… * entity : a foreign key link to another entity (i.e. the ‘many’ end of a one-to-many link); * list : a list of some other entity that links to me (i.e. the ‘one’ end of a one-to-many link); * link : a many to many link (via a link table); * defined : a type defined by a typedef.
+
content
content, for things like pages (i.e. forms, lists, pages)
+
content-validations
*TODO: write docs
+
defineable-data-types
data types which can be used in a typedef to provide validation - e.g. a string can be used with a regexp or a scalar can be used with min and max values * string: varchar java.sql.Types.VARCHAR * integer: int java.sql.Types.INTEGER * real: double java.sql.Types.DOUBLE * money: money java.sql.Types.INTEGER * date: date java.sql.Types.DATE * time: time java.sql.Types.TIME * timestamp: timestamp java.sql.Types.TIMESTAMP * uploadable: varchar java.sql.Types.VARCHAR * image: varchar java.sql.Types.VARCHAR
+
uploadable is as string but points to an uploaded file; image is as uploadable but points to an uploadable graphical image file.
+
disjunct-valid?
(disjunct-valid? o & validations)
Yes, this is a horrible hack. I should be returning the error structure not printing it. But I can’t see how to make that work with bouncer. OK, so: most of the validators will (usually) fail, and that’s OK. How do we identify the one which ought not to have failed?
+
documentation-validations
contains documentation on the element which immediately contains it. For the time being, HTML markup is not permitted within documentation, but Markdown (which may include a string representation of HTML markup) should be.
+
entity-validations
an entity which has properties and relationships; maps onto a database table or a Java serialisable class - or, of course, various other things
table: the name of the table in which this entity is stored. Defaults to same as name of entity. Strongly recommend this is not used unless it needs to be different from the name of the entity
+
foreign: this entity is part of some other system; no code will be generated for it, although code which links to it will be generated
+
+
field-stuff
*TODO: write docs
+
field-validations
a field in a form or page
+
+
property: the property which this field displays/edits.
+
+
fieldgroup-validations
a group of fields and other controls within a form or list, which the renderer might render as a single pane in a tabbed display, for example.
+
foot-validations
content to place in the bottom of the body of the generated document; this is any HTML block or inline level element.
+
form-validations
a form through which an entity may be added or edited
+
generator-actions
*TODO: write docs
+
generator-validations
marks a property which is auto-generated by some part of the system. This is based on the Hibernate construct, except that the Hibernate implementation folds both its internal generators and custom generators onto the same attribute. This separates them onto two attributes so we can police values for Hibernate’s ‘builtin’ generators.
+
+
action: one of the supported Hibernate builtin generators, or ‘manual’. ‘native’ is strongly recommended in most instances
+
class: if action is ‘manual’, the name of a manually maintained class conforming to the Hibernate IdentifierGenerator interface, or its equivalent in other languages.
+
+
group-validations
a group of people with similar permissions to one another
+
+
name: the name of this group
+
parent: the name of a group of which this group is subset
+
+
head-validations
content to place in the head of the generated document; normally HTML.
+
help-validations
helptext about a property of an entity, or a field of a page, form or list, or a typedef. Typically there will be only one of these per property per locale; if there are more than one all those matching the locale may be concatenated, or just one may be used.
+
+
locale: the locale in which to prefer this prompt
+
+
ifmissing-validations
helpful text to be shown if a property value is missing, typically when a form is submitted. Typically there will be only one of these per property per locale; if there are more than one all those matching the locale may be concatenated, or just one may be used. Later there may be more sophisticated behaviour here.
+
+
locale: the locale in which to prefer this prompt
+
+
in-implementation-validations
information about how to translate a type into types known to different target languages. TODO: Once again I’m not wholly comfortable with the name; I’m not really comfortable that this belongs in ADL at all.
+
+
target: the target language
+
value: the type to use in that target language
+
kind: OK, I confess I don’t understand this, but Andrew needs it…
+
+
key-validations
*TODO: write docs
+
list-validations
a list on which entities of a given type are listed
+
+
onselect: name of form/page/list to go to when a selection is made from the list
+
+
option-validations
one of an explicit list of optional values a property may have NOTE: whether options get encoded at application layer or at database layer is UNDEFINED; either behaviour is correct. If at database layer it’s also UNDEFINED whether they’re encoded as a single reference data table or as separate reference data tables for each property.
+
+
value: the value of this option.
+
+
order-validations
an ordering or records in a list * property: the property on which to order * sequence: the sequence in which to order
+
page-content
*TODO: write docs
+
page-stuff
*TODO: write docs
+
page-validations
a page on which an entity may be displayed
+
param-validations
A parameter passed to the generator. Again, based on the Hibernate implementation.
+
+
name: the name of this parameter.
+
+
permission-validations
permissions policy on an entity, a page, form, list or field
+
+
group: the group to which permission is granted
+
permission: the permission which is granted to that group
+
+
permissions
permissions a group may have on an entity, list, page, form or field permissions are deemed to increase as you go right. A group cannot have greater permission on a field than on the form it is in, or greater permission on form than the entity it belongs to
+
+
none: none
+
read: select
+
insert: insert
+
noedit: select, insert
+
edit: select, insert, update
+
all: select, insert, update, delete
+
+
pragma-validations
pragmatic advice to generators of lists and forms, in the form of name/value pairs which may contain anything. Over time some pragmas will become ‘well known’, but the whole point of having a pragma architecture is that it is extensible.
+
prompt-validations
a prompt for a property or field; used as the prompt text for a widget which edits it. Typically there will be only one of these per property per locale; if there are more than one all those matching the locale may be concatenated, or just one may be used.
+
+
prompt: the prompt to use
+
locale: the locale in which to prefer this prompt.
+
+
property-validations
a property (field) of an entity (table)
+
+
name: the name of this property.
+
type: the type of this property.
+
default: the default value of this property. There will probably be magic values of this!
+
typedef: name of the typedef to use, it type = ‘defined’.
+
distinct: distinct=‘system’ required that every value in the system will be distinct (i.e. natural primary key); distinct=‘user’ implies that the value may be used by users in distinguishing entities even if values are not formally unique; distinct=‘all’ implies that the values are formally unique /and/ are user friendly (NOTE: not implemented).
+
entity: if type=‘entity’, the name of the entity this property is a foreign key link to. if type=‘list’, the name of the entity that has a foreign key link to this entity
+
farkey: if type=‘list’, the name of farside key in the listed entity; if type=‘entity’ and the farside field to join to is not the farside primary key, then the name of that farside field
+
required: whether this propery is required (i.e. ‘not null’).
+
immutable: if true, once a value has been set it cannot be changed.
+
size: fieldwidth of the property if specified.
+
concrete: if set to ‘false’, this property is not stored in the database but must be computed (manually written code must be provided to support this)
+
cascade: what action(s) on the parent entity should be cascaded to entitie(s) linked on this property. Valid only if type=‘entity’, type=‘link’ or type=‘list’.
+
column: name of the column in a SQL database table in which this property is stored. TODO: Think about this.
+
unsaved-value: of a property whose persistent value is set on first being committed to persistent store, the value which it holds before it has been committed
+
+
reference-validations
The ‘specification’ and ‘reference’ elements are for documentation only, and do not contribute to the engineering of the application described.
+
A reference element is a reference to a specifying document.
+
+
abbr: The abbreviated name of the specification to which this reference refers
+
section: The ‘anchor part’ (part following a hash character) which, when appended to the URL, will locate the exact section referenced.
+
entity: A reference to another entity within this ADL document
+
property: A reference to another property within this ADL document; if entity is also specified then of that entity, else of the ancestor entity if any
+
+
sample-option
*TODO: write docs
+
sequences
*TODO: write docs
+
simple-data-types
data types which are fairly straightforward translations of JDBC data types * boolean: boolean java.sql.Types.BIT or char(1) java.sql.Types.CHAR * text: text or java.sql.Types.LONGVARCHAR memo java.sql.Types.CLOB
+
special-data-types
data types which require special handling - which don’t simply map onto common SQL data types * geopos : a latitude/longitude pair (experimental and not yet implemented) * image : a raster image file, in jpeg, gif, or png format (experimental, not yet implemented) * message : an internationalised message, having different translations for different locales
+
specification-validations
The ‘specification’ and ‘reference’ elements are for documentation only, and do not contribute to the engineering of the application described.
+
A specification element is intended chiefly to declare the reference documents which may be used in documentation elements later in the document.
+
+
url: The URL from which the document referenced can be retrieved
+
name: The full name (title) given to this document
+
abbr: A convenient abbreviated name.
+
+
top-validations
content to place in the top of the body of the generated document; this is any HTML block or inline level element.
+
try-validate
(try-validate o validation)
Pass this validation and the object o to bouncer
+
typedef-validations
the definition of a defined type. At this stage a defined type is either * a string in which case it must have size and pattern, or * a scalar in which case it must have minimum and/or maximum pattern must be a regular expression as interpreted by org.apache.regexp.RE minimum and maximum must be of appropriate format for the datatype specified. Validation may be done client-side and/or server-side at application layer and/or server side at database layer.
+
+
name: the name of this typedef
+
type: the simple type on which this defined type is based; must be present unless in-implementation children are supplied
+
size: the data size of this defined type
+
pattern: a regular expression which values for this type must match
+
minimum: the minimum value for this type (if base type is scalar)
+
maximum: the maximum value for this type (if base type is scalar)
+
+
valid-adl?
(valid-adl? src)
Return true if src is syntactically valid ADL.
+
validate-adl
(validate-adl src)
*TODO: write docs
+
validate-adl-file
(validate-adl-file filepath)
*TODO: write docs
+
verb-validations
a verb is something that may be done through a form. Probably the verbs ‘store’ and ‘delete’ are implied, but maybe they need to be explicitly declared. The ‘verb’ attribute of the verb is what gets returned to the controller
+
+
verb what gets returned to the controller when this verb is selected
+
dangerous true if this verb causes a destructive change.