I guess it was easier to make reports require a single, global resolver. Then query params are your only option to influence its output. You could write your own version of reports that does the mapping of routing params to resolvers differently. Or you could make both global and ident resolvers and make the former fall back to the latter by returning just {<id prop> <id value>} based in the query params.

Yeah, reports were not designed to be a route that was for a specific thing, but a collection of things. To me, what you are describing is a read-only form of an invoice.

The line is gray though

it’s ok to have :invoice/id as a control, send that as a parameter to the route, and fix up the resolver to deal with it (by inventing a report kw for that use-case), but that does mean that you report routing gets a little strange.

I find this cardinality mapping thing between forms and reports to be a curious choice. I know the API around reports and containers is still in an early stage, and I wonder if your mind is made up around this design decision. Much of my pre-Clojure experience is with Python + Django. One of the parts of Django that is well-liked is the auto-generated admin views that get created from the underlying data model. A common way to structure these views is with a formset up top which allows edit of the fields directly on the main thing, and then "tabular inlines" down below. The inlines are the related model objects of the main thing, like author->books. Sometimes the inlines are read-only, and sometimes there is some edit functionality/actions allowed. The inlines remind me of RAD reports, and the admin panels generally remind me of RAD itself. It ends up looking like the attached screenshot. Perhaps forms and reports can work together in a similar fashion under containers? In any case, this is just some of my own thinking on the subject and however you decide RAD should be is the best choice anyway, but I thought the pointer to Django Admin might be good food for thought. https://docs.djangoproject.com/en/4.1/ref/contrib/admin/#django.contrib.admin.TabularInline

I’m aware of this kind of thing. My intention for forms/reports is different, BUT not incompatible with your example/goal. I think that is just a different set of constructs. You’re talking about a pure CRUD back-end interface. RAD is meant for rapid prototyping and even production implementation of real user-facing features, and happens to make CRUD interfaces for support/admin relatively easy. But, autogenerating a compelte UI/resolver/mutation set for a pure db editing system is well within (someones) reach with RAD’s approach. I just will not be writing that part myself.

It's not so much of the autogeneration I'm pointing out, as much as the construct that contains both "specific thing ... a collection of things". In the message above you seem to separate specific thing vs. collection of things -> form & report. But yes, of course RAD's flexibility allows for this to be done by customizing containers a bit, I just wonder if would help with the rapid prototyping aspect if forms and reports played together nicely like this out of the box. Maybe it is just a minority use case and keeping it out of the main design - but totally doable with the provided bells and whistles - is the pragmatic approach and keeps the RAD code manageable. Thanks for entertaining the notion 🙂

Correct. My notion of a report is a mostly-read-only view of mostly-derived information. A common case happens to be a list of single things which are real entities in the db, and for which very little of the info is derived. The “view” of a single thing is a read-only form, esp since “single things” in a graph world is a nested concept that requires the facilities of the form. Reports are row-oriented things that have a single conceptual source (sales data) that results in often-derived data. The further you stray from that, the more you want your own custom “thing”, but the patterns of creation for such new macros is obvious and straightforward once you see the patterns.