I'm interested in the same thing myself.  So I'm quite interested in
this thread.  I had a few 'fails' as well as a couple of 'wins' but I
havent' got a satisfying *feel* yet.

I show you the structure I have so far -- Suggestions for better ways
to achieve the same result are welcome.  I feel like I know what I
need to do (want to do) but not got enough Rack/Sinatra/Ruby
background.  Hopefully we can get something to work between us.

I am being a little experimental so bear with me, the objectives are
quit simple so far.  I want a stable foundation for different kinds of
apps that I might want to do.  :-)  Objectives for the small
prototype.

   1.  Keep a RESTful structure see [2]
   2.  Using just the 4 x RESful CRUD Verbs per object (POST GET PUT
DELETE)
   3.  I want to separate by Nouns (REST objects) by file and folder
-- That give
        object decomposition.
   4.  They should be able to share helper code and templates, etc.

Example:

       Application/
             |
            +--- home/   .. .. .. .. .. .. Basic web site code (e.g.
root page, about, etc.)
             |
            +--- things/  .. .. .. .. .. .. Individual noun (objects)
are stored under this tree
             |        |
             |       +--- person/  .. .. .. Person object type
methods.
             |        |         |
             |        |        +--- stuff/  .. .. .. More specific
stuff for this person.
             |        |
             |       +--- address .. .. .. Address object type
methods.
             |
            +--- public   .. .. .. .. .. .. Static pages images, etc.
                :

There would be more, common things that every app. uses, etc. like
Data, Model, Controller (or logic).  At present the notion is for REST-
services, that feed a web site.  A further step would be accessing
Nouns from controllers or views as well as just exposing an interface.

So far so good.

I took some time looking at the Sinatra::Base idea, I think that makes
a lot of sense for things to be modular rather than the flat look of
the traditional app.  I'm not too sure what I've got is effective, it
works for now.

   module Components
      class HelloBase < Sinatra::Base
           # add settings and stuff like that here

      class HelloApp < HelloBase
           # I put helpers in here so they are common
   end #module

      require 'home'
      require 'things/person/POST'
      require 'things/person/GET'
      require 'things/person/stuff'/POST'
      require 'things/person/stuff'/GET'
      require 'things/address/POST'
      require 'things/address/GET'

La la la ... In each of those little verb files (e.g. GET.rb)

   module Components
      class HelloApp < HelloBase
          #-- add person GET pattern here and other code I may need

So far, it seems that I had do extend my Application class "HelloApp"
to add my separate functions.  I thought that the idea of a
"Components" namespace was ultimately a good way to go.

What I'd have preferred is something like ...

   module Components
      class Person < HelloApp
          #-- add person GET pattern here and other code I may need

Or even better ...

   module Components
      class Person < HelloBase
          #-- add person GET pattern here and other code I may need

And keep anything I want shared like the helpers in the base class
("HelloBase").  Or something like that.

I reckon that Normally one file is enough for all POST, GET, PUT  and
DELETE because they are simple enough bits of code (most of the
time).  At first I thought I'd like to leave it granular -- See how it
works out.

For now, I don't seem to have 'visibility' to the helpers unless the
modules are part of the "Components::HelloApp" class.  I can probably
say the same if I used the HelloBase.  I haven't gone into the
visibility implications yet because I'm not sure this configuration
really give me what I'm looking for.

Comments welcome.

Cheers,
             Will

----
  > [1]  http://www.sinatrarb.com/extensions.html
     [2]  Common REST mistakes
              http://www.prescod.net/rest/mistakes

On Jul 20, 7:10 am, Marcos Vanetta <marcosvane...@gmail.com> wrote:

How do you makd your 'ascii diagrams" line-up?

w.

On Jul 30, 1:39 pm, Will <william.full.m...@gmail.com> wrote:

To take an example from a project I'm working on... I want several
helper functions called 'validate_params'.  They would be different
for each 'grouping' of actions' (roughly speaking, a controller).

How would I do this? Currently I see only one way: create subclasses
of Sinatra::Base. (If there are other ways, please let know, but I'm
skeptical, because in Sinatra::Application all helpers are global to
the application).

Here's the bummer. On my system, creating a class that inherits from
Sinatra::Base costs 13 MB. I like the idea of running a small sinatra
app at 13 MB.  I don't like the idea of running an app at 13 MB x 5 or
x 10.

At the end of the day, I don't really need all the functionality of a
sub-app -- all I want is name-spacing. I would imagine others are in
the same boat.

LoginValidator.validate(params) => true

ImageValidator.validate(params) => false
ImageValidator.errors_for(params) => [whatever, you, want, to return]

But you're right, there's no way that I can think of to namespace  
helpers the way you want.  But the trivial workaround is to have them  
be separate classes with specific roles.

Chris

On Jul 30, 2009, at 1:55 PM, David James wrote:

I'm still reading -- And looking.  How many of you have looked at
Needle?

   *  http://needle.rubyforge.org

There's an example with 'authenticator'

   *  http://needle.rubyforge.org/chapter-3.html#s2

It also seems to offer a namespace thing.

It would be interesting if there's anyone ono the list who has put
these two together?

I'm still wrapping my head around it, and I like it; it or something
like it looks like it can be very useful.

Thanks,
             Will

On Jul 31, 7:08 am, Christopher Schneider <ch...@christopher-

http://gist.github.com/159216

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.

On Jul 31, 6:16 am, Alex Chaffee <ale...@gmail.com> wrote:

It's far too heavy for the one or two page apps, but it's perfect for  
the 20-30 page apps.

Chris

On Jul 31, 2009, at 9:22 AM, Nate W wrote:

On Jul 31, 9:16 am, Alex Chaffee <ale...@gmail.com> wrote:

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?

I'm not entirely clear why the pattern below is important...  Is it to
force classic apps to register modules without an explicit call to
register?

module Sinatra
  module MyModule
    #... stuff here
  end
  register MyModule
end

Should modules be registered within the Sinatra namespace as above?
Or should they be defined as in Alex's gist, i.e. in their own
namespace with no call to register.  Either way some clarification of
these issues on the extensions page would be great! :-)

A bit of a digression here, just saying that the idea of having a
"best method" may work for some - but the "simplest" method may be the
one we want in the docs.

And you can't see it there but I do explicitly call register in my
app.rb file via "register Actions::Login".

Cheers -

module Sinatra
  module MyExtension
      # stuff here...

    self.registered(app)
       # stuff...
    end

  end

  register MyExtension
end

And this form:

module MyExtension
    self.registered(app)
       # stuff...
    end
end

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.

Thanks again,

R.