Arbitrary rack apps as subcontrollers

[Andrey Popp]

Hello,

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

[Andrey Popp]

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]

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,

CCed scor...@googlegroups.com

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]

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]

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]

I've sent a pull request https://github.com/Wardrop/Scorched/pull/16