Intercepting requests with Rack Middleware OR a Before Filter
132 views
Skip to first unread message
KD
Apr 27, 2009, 1:25:11 PM4/27/09
to sinatrarb
-I've created a rack middleware in sinatra for some authentication
needs that just adds an authenticated boolean to the params hash that
can get checked down the line.
-I've created before filters to set the users language preference.
Beyond the ability to modify content post-call as you can with rack
middleware, I'm wondering what guidelines to consider in choosing one
of these approaches to intercept incoming requests?
needs that just adds an authenticated boolean to the params hash that
can get checked down the line.
-I've created before filters to set the users language preference.
Beyond the ability to modify content post-call as you can with rack
middleware, I'm wondering what guidelines to consider in choosing one
of these approaches to intercept incoming requests?
Tanner Burson
Apr 27, 2009, 2:48:03 PM4/27/09
to sina...@googlegroups.com
For me the difference is this: do you need access/modify something before the Sinatra stack has been called? If not? Make it a plugin.--
===Tanner Burson===
tanner...@gmail.com
http://www.tannerburson.com
===Tanner Burson===
tanner...@gmail.com
http://www.tannerburson.com
KD
Apr 29, 2009, 7:59:22 AM4/29/09
to sinatrarb
OK, so that's a third way.
So I guess I'm looking for this type of guidance,
If you need intercept the request to '...', use the before filter.
If you need intercept the request to '...', create a Rack Middleware
(I think this is what Tanner is saying below).
If you need intercept the request to '...', create a Sinatra
Extension (aka plugin).
On Apr 27, 2:48 pm, Tanner Burson <tanner.bur...@gmail.com> wrote:
> For me the difference is this: do you need access/modify something before
> the Sinatra stack has been called? If not? Make it a plugin.
>
So I guess I'm looking for this type of guidance,
If you need intercept the request to '...', use the before filter.
If you need intercept the request to '...', create a Rack Middleware
(I think this is what Tanner is saying below).
If you need intercept the request to '...', create a Sinatra
Extension (aka plugin).
On Apr 27, 2:48 pm, Tanner Burson <tanner.bur...@gmail.com> wrote:
> For me the difference is this: do you need access/modify something before
> the Sinatra stack has been called? If not? Make it a plugin.
>
> On Mon, Apr 27, 2009 at 12:25 PM, KD <inbox...@gmail.com> wrote:
>
> > -I've created a rack middleware in sinatra for some authentication
> > needs that just adds an authenticated boolean to the params hash that
> > can get checked down the line.
> > -I've created before filters to set the users language preference.
>
> > Beyond the ability to modify content post-call as you can with rack
> > middleware, I'm wondering what guidelines to consider in choosing one
> > of these approaches to intercept incoming requests?
>
> --
> ===Tanner Burson===
> tanner.bur...@gmail.comhttp://www.tannerburson.com>
> > -I've created a rack middleware in sinatra for some authentication
> > needs that just adds an authenticated boolean to the params hash that
> > can get checked down the line.
> > -I've created before filters to set the users language preference.
>
> > Beyond the ability to modify content post-call as you can with rack
> > middleware, I'm wondering what guidelines to consider in choosing one
> > of these approaches to intercept incoming requests?
>
> --
> ===Tanner Burson===
Tanner Burson
Apr 29, 2009, 11:39:24 AM4/29/09
to sina...@googlegroups.com
KD,
For me it falls out like this:
I consider filters a way to modify APPLICATION flow or data.
Rack Middleware for things that for some reason need to be done before Sinatra, or you want to be re-usable in generic Rack apps.
I use a plugin for something that needs to modify or extend Sinatra itself in some fashion, that I intend on re-using across multiple Sinatra apps. Note though, that a plugin can include filters.
Really I think at this point a lot of it boils down to your personal preference on where to scope your changes. I tend to avoid full on MiddleWare and lean towards Sinatra plugins, but others seem to go the other way. I'm also careful with filters, as currently they're applicable across your entire application, which makes some things a bit more difficult.
Hopefully that makes it clear as mud for you.
--Tanner
For me it falls out like this:
I consider filters a way to modify APPLICATION flow or data.
Rack Middleware for things that for some reason need to be done before Sinatra, or you want to be re-usable in generic Rack apps.
I use a plugin for something that needs to modify or extend Sinatra itself in some fashion, that I intend on re-using across multiple Sinatra apps. Note though, that a plugin can include filters.
Really I think at this point a lot of it boils down to your personal preference on where to scope your changes. I tend to avoid full on MiddleWare and lean towards Sinatra plugins, but others seem to go the other way. I'm also careful with filters, as currently they're applicable across your entire application, which makes some things a bit more difficult.
Hopefully that makes it clear as mud for you.
--Tanner
Reply all
Reply to author
Forward
0 new messages