This lets me split actions into related chunks and put them in their
own namespace (a module) and subdirectory, which is basically all I
was asking for.
We're also beginning to find ourselves in this position. My original
idea was to split our application into a number of small sinatra apps
and tie them together with rackup URL maps. However, it seems that
Rack's url-mapping features are more cumberosome than sinatra's path
DSL, and given the point you've raised about the costs of inheriting
from Sinatra::Base, I'm beginning to wonder what advantages there are
to splitting a monolithic app into multiple apps, rather than adopting
the modular approach?
What is it that a modular app gives you over a registered module? Is
it simply the ability to have different options set, such as views,
sessions, logging etc?
It's because it's not really an extension, but an integral part of my
app. (It refers to my own domain objects like User and Views::Login.)
So I'm kind of misusing the feature... or, let's say, innovating! I
think that namespace rule was more of a suggestion anyway, right?
And you can't see it there but I do explicitly call register in my
app.rb file via "register Actions::Login".
Yes, I see that. I guess my question was more as to what the
differences are between this form:
# stuff here...
And this form:
i.e. is there a difference between defining an extension inside the
Sinatra module (and calling register from within it), and defining it
outside of the Sinatra namespace and not explicitly calling
register??? My guess is that the later approach won't register
automagically for classic apps. Is this true?? The page at
http://www.sinatrarb.com/extensions.html doesn't seem to explain this,
but appears to favour the former approach.