In order to generate the admin routes, the Trestle reloader must read each admin file when routes are loaded (which is at startup in most cases). However we can defer the lookup and constantization of the admin resource's model until the Trestle::Registry#lookup_model method is called. This fixes issues such as #482 where an error in loading a model can mask the root cause of the exception.
Unfortunately an error in an admin definition will still cause a failure at startup time. I don't know at this point whether that is resolvable (in a way that is desirable, i.e. don't just rescue any exceptions).
This PR also pushes the logic of whether an admin resource should register itself for model lookup out of the Trestle::Registry class and down to the Trestle::Resource itself where it is a better fit.
coverage: 91.494% (+0.006%) from 91.488%
when pulling 845c3c6718edcc71e4e792b2d8f9dfce331213f0 on defer-admin-model-registration
into dfc360a349dd0dbad5eeeb39e5e1ac87522d20df on main.
In order to generate the admin routes, the Trestle reloader must read each admin file when routes are loaded (which is at startup in most cases). However we can defer the lookup and constantization of the admin resource's model until the
Trestle::Registry#lookup_model
method is called. This fixes issues such as #482 where an error in loading a model can mask the root cause of the exception.Unfortunately an error in an admin definition will still cause a failure at startup time. I don't know at this point whether that is resolvable (in a way that is desirable, i.e. don't just rescue any exceptions).
This PR also pushes the logic of whether an admin resource should register itself for model lookup out of the
Trestle::Registry
class and down to theTrestle::Resource
itself where it is a better fit.