Tailor documentation of auto-import with dry-web-skeleton example

Support dry-web
1

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.

2

When config.ru complains that a Import request can’t be resolved, then what is the first newbie check to consider?

Boot Error

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:

module Main
  module Persistence
    module Repositories
      class Persons < Conferencer::Repository[:persons]

within it.

Is there a configuration setting somewhere that tells the auto-import process which directories to scan and is that scan recursive or only explicit?

3

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.

Oh sweet:

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.