Your documentation at http://dry-rb.org/gems/dry-system/auto-import/ would be easier to follow if it used example structure and files from the operational
raygun -p icelab/dry-web-skeleton sample project.
As it is, a reader has to try to match up differently named partial relative paths and has to factor in the differences of not using or of using the other dry-* components that also impose conventions on the example documentation and the actual sample project.
When config.ru complains that a Import request can’t be resolved, then what is the first newbie check to consider?
Something went wrong while loading config.ru
Dry::System::ComponentLoadError: could not load component #<Dry::System::Component identifier="persistence.repositories.persons" path="/persistence/repositories/persons">
The project has a lib/main/persistence/repositories/persons.rb class with the preamble:
class Persons < Conferencer::Repository[:persons]
Is there a configuration setting somewhere that tells the auto-import process which directories to scan and is that scan recursive or only explicit?
Using pry, I can see that the Main::Import container, when referenced in the View class at runtime, has a map of “Strategies”, each one keyed off the name of the path and file for the classes out of the apps/main/lib directory tree. So, that’s cool. (I was thinking maybe it was a nil emptyset map.)
The key strings are “main.subdir.subdir.file” and not the shortened form of “subdir.subdir.file” shown in the example and in the somewhat similar “berg” project.
ROM::Registry::ElementNotFoundError: :persons doesn’t exist in ROM::RelationRegistry registry
/Users/lonniev/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rom-support-2.0.0/lib/rom/support/registry.rb:33:in `block in fetch’
So it was the lack of “main.” in the key. The next issue is: how to register relations.
That involves the addition of schema-like classes in the outer lib/persistence/relations directory. When a Relation class is added there (with the right name), the reference to it in the specification of the View class resolves completely.
I have to go have a Think on what is the difference in ROM between an Entity class and a Relation class. (I thought Relation was akin to a UML Association while Entity was akin to a UML Class. However, Relation is more like a physical data model for the logical data model of the Entity.)
Think or read. Reading helps: http://hawkins.io/2015/04/better-persistence-with-rom/
I’m a little closer to understanding WTH.