simon-brooke / adl Goto Github PK

Needed for YouYesYet alpha.

We're seeing this:

CREATE VIEW lv_event_type AS
SELECT event-type.summary,
	event-type.description,
	event-type.n_holdings,
	event-type.n_pastures,
	event-type.n_animals,
	event-type.id
FROM event_type
;

Obviously, every instance of `event-type` must be `event_type`.

We're seeing this:

------------------------------------------------------------------------
--	convenience view lv_animal of entity animal for lists, et cetera 
------------------------------------------------------------------------
CREATE VIEW lv_animal AS
SELECT holding.holding_identifier ||', '|| holding.name AS holding_expanded,
	animal.holding,
	animal.animal_identifier ||', '|| animal.name AS dam_expanded,
	animal.dam,
	animal.animal_identifier ||', '|| animal.name AS sire_expanded,
	animal.sire,
	animal.born,
	animal.animal_identifier,
	animal.name,
	gender.gender AS gender_expanded,
	animal.gender,
	species.species AS species_expanded,
	animal.species,
	breed.breed AS breed_expanded,
	animal.breed,
	animal.is_pedigree,
	pasture.name ||', '|| pasture.area AS pasture_expanded,
	animal.pasture,
	animal.id
FROM species, pasture, breed, gender, animal, holding
WHERE animal.holding = holding.id
	AND animal.dam = animal.id
	AND animal.sire = animal.id
	AND animal.gender = gender.gender
	AND animal.species = species.species
	AND animal.breed = breed.breed
	AND animal.pasture = pasture.id
;

Clearly, animal.animal_identifier ||', '|| animal.name AS dam_expanded should be dam.animal_identifier ||', '|| dam.name AS dam_expanded

For forms, GET is used to open a form, either new or populated from an existing record. POST is used to submit a form. If we provide separate handlers, it makes the flow easier.

With lists, again, GET is used to just fetch the list, POST is used to search it.

If we genetate separate GET and POST handlers for everything, then in the case of pages, the POST handler can just call the GET handler, because there isn't really any point in POSTing to a page (unless the page is what you get after POSTing a form?

Auxlists are needed to get YouYesYet to alpha.

When generating cache.clj files, we generate a require list. Most of these requires appear to be unnecessary. The following commenting makes no difference to build in YouYesYet:

(ns
 youyesyet.cache
 "Caching wrappers for queries for youyesyet auto-generated by [Application Description Language framework](https://github.com/simon-brooke/adl) at 20220617T112222.113Z"
 (:require
  ;; [adl-support.core :refer :all]
  ;; [adl-support.rest-support :refer :all]
  [clojure.core.memoize :as memo]
  ;; [clojure.java.io :as io]
  ;; [clojure.tools.logging :as log]
  ;; [compojure.core :refer [defroutes GET POST]]
  ;; [hugsql.core :as hugsql]
  ;; [noir.response :as nresponse]
  ;; [noir.util.route :as route]
  ;; [ring.util.http-response :as response]
  [youyesyet.db.core :as db]))

I think (but need to check) that none of these requires are ever actually used. In which case they should not be generated.

... and I don't know why not.

Generate a re-frame skeleton.

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.

Example is roles widget on canvasser form.

Memoisation of handlers probably doesn't make sense, because every request
will be different. I don't think we can memoise HugSQL, at least not without
hacking the library (might be worth doing that and contributing a patch).
So the solution may be to generate an intervening namespace 'cache', which has one
memoised function for each hugsql query.