Marnen Laibow-Koser wrote in post #955146:
Utility classes (that are not models) go in lib. I don't see what the
utility directory inside there gains you; lib is already utilities.
To me lib/ implies a library used by the application. not part of the
application itself, which is why I considered added another top level
subdirectory under app/ That way app/ is the complete contents of the
application.
A minor aside: app still won't include the complete contents, because
of config, db, public, &c.
Does that make sense or do you see a problem with that? Also does it
help with auto loading of classes?
In the sense that, by default, app is included in the autoload path,
but lib is not, for reasons that escape me.
Your view of lib is reasonable, but it is not particularly railsy:
libraries are typically loaded either via the vendor directory, or
simply as gems listed in Gemfile. 'lib' doesn't really have the same
meaning that it typically does, in say a J2EE app where it usually is
a dumping ground for third party jars.
That said, there is nothing particularly bad about adding
subdirectories in app. Just remember that if you want autoloading to
work, you have to make sure that the names match the directories, and
if you have directories that aren't included in the fully qualified
name of a class, to add those directories to the autoload path.
e.g.
app/widgets/foo.rb could have class Widgets::Foo, or it could have
class Foo if you added app/widgets to the autoload path, which IIRC,
is accomplished in config/application.rb.
config.autoload_paths += %W( #{config.root}/app/widgets )
and, again IIRC, just basically updates
ActiveSupport::Dependencies.autoload_paths