Arbitrary rack apps as subcontrollers

34 views
Skip to first unread message

Andrey Popp

unread,
Jul 24, 2013, 3:22:12 PM7/24/13
to scor...@googlegroups.com
Hello,

I wonder is it somehow possible to make Scorched::Controller to dispatch to arbitrary rack apps under some prefix?

Andrey Popp

unread,
Jul 24, 2013, 4:30:59 PM7/24/13
to scor...@googlegroups.com
I've ended with:

class Scorched::Controller
  def mount_rack(prefix, app)
    adapter = lambda do |env|
      env = env.dup
      env['PATH_INFO'] = env['PATH_INFO'][prefix.length..-1] if prefix
      app.call(env)
    end
    self << {pattern: prefix, target: adapter}
  end
end

Tom Wardrop

unread,
Jul 25, 2013, 8:04:21 PM7/25/13
to Andrey Popp, scor...@googlegroups.com
By the way, I only just realised you originally posted this to the Scorched google group. I would have replied there had I noticed. Oh well, I'll know for next time. I've also just allowed the Google Group to accept replies via email.

Tom


On Fri, Jul 26, 2013 at 12:45 AM, Andrey Popp <8ma...@gmail.com> wrote:
Hi,


On Thu, Jul 25, 2013 at 3:02 AM, Tom Wardrop <t...@tomwardrop.com> wrote:
Oh I think you know you mean. So if your Rack app was mapping in Scorched to `/sub`, and you went to the URL `/sub/new`, the Rack app would see `/sub/new` as the path instead of just `/new`. I wonder if this is something I should change?

I think the sane change would be to pass env without modification only to Scorched::Controller and mangle PATH_INFO for others:

class Scorched::Controller
  ...
  def action
    response.merge! if target === Proc
      instance_exec(env, &target)
    elsif target.is_a? Scorched::Controller
      target.call(env)
    else
      # XXX: mangle PATH_INFO to include only request.unmatched_path
      target.call(env)
    end
  end
  ...
end

BTW. Why not to make a helper for mounting subcontrollers instead of self << ?

Andrey Popp

unread,
Jul 26, 2013, 3:30:56 PM7/26/13
to Tom Wardrop, scor...@googlegroups.com
On Fri, Jul 26, 2013 at 3:21 AM, Tom Wardrop <t...@tomwardrop.com> wrote:
It's a tricky one. I'd prefer to treat Scorched::Controller like any other Rack-callable object, but then the environment hash is the only means of sharing request-state between other controllers in the pipeline, hence any dup'ing of the environment hash (for the sake of mangling PATH_INFO) would break that. Maybe special treatment does need to be made when passing a request from one Scorched::Controller to another Scorched::Controller, like you've proposed.

To be honest I don't see the value to share request state from an inner controller to an outer one. I'd dup env before passing it either to inner Scorched::Controller or arbitrary Rack app no matter. That way only parent -> child request state sharing would be possible but not vice-versa which is good, I think.

--
Andrey Popp / and...@unlikely.is

Tom Wardrop

unread,
Jul 27, 2013, 6:58:33 PM7/27/13
to scor...@googlegroups.com, Tom Wardrop
Yeah, I think I agree. I'm trying to think of a scenario where you'd want changes to the environment hash to bubble back up to `after` filters in the outer controller. Mind you, inherited `after` filters are executed in the inner-most controller anyway, so it'd only be if the sub-controller doesn't inherit from the parent that you'd ever have an `after` filter executing in the context of an outer controller.

I think I'll do this, and make PATH_INFO be equal to `unmatched_path`. The matched path or original root path can stored as a separate value in the env hash or something. I'll have a play and see what the best solution is.

Cheers,
Tom

Andrey Popp

unread,
Jul 28, 2013, 1:11:07 PM7/28/13
to Tom Wardrop, scor...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages