The current HEAD of the runner branch actually has beta code that replaces the
existing logic for calculating content length when its not set with this Plack
middleware (we also replace some custom logic to remove the content body when
the request is HEAD with similar Plack middleware). So this work is useful to
help us shake out and improve the common middleware bits.
Over the coming time I plan to move more and more custom code into middleware
when it makes sense. The goal is to reduce the amount of custom code in
Catalyst and move some of the burden of maintenance onto the broader Plack
community.
However I am unclear what the failing cases is this example are... Is is
possible to contrive a failing case for the content length middleware we can
bring to #plack / miyagawa?
I recommend anyone interested to start pulling from the HEAD of the runner
branch if they want to play with it. I want to ponder the best approach to
using middleware for core app functionality (pondering how Rails middleware
stack works, and looking at PlackX::MiddlewareStack for examples.) Right now
in HEAD the core middleware is just tacked onto the top of
registered_middleware. Thoughts on the best way to architect this are very
welcome. I see in the nearish future a good chuck of stuff that is in
Catalyst.pm and related files moving into Middleware, possibly including the
debugging screens, errors screens, etc. In Rails and Django for example all
that stuff is in middleware to make it easier for people to pull out and hack
on it.
John
On Saturday, December 21, 2013 9:38 AM, Bill Moseley <[email protected]> wrote:
On Fri, Dec 20, 2013 at 8:34 PM, neil.lunn <[email protected]> wrote:
....
>
My article today actually (http://www.catalystframework.org/calendar/2013/21),
even though I'm actually talking here about the above case.
>
Just a note on the Advent article.
Thanks for writing that up. It's a well-written article and clearly explains
the issue I was facing and the fix you provided to me. One thing I really like
about the Advent articles is that I learn new ways to do things. For example,
I wasn't aware of namespace::sweep and never thought about overriding the -X
filetests. I just set the content length manually now in the Controller along
with the body.
I'm was also very happy to see you building this into a model at the end. I
sometimes wonder if that is not stressed enough when learning Catalyst. I see
a lot of code written into controllers at work that should really be models. I
will pass the link to the Advent article around.
In my specific situation for this problem I already had a model. The gzipped
files are stored on a distributed file system and I already had a model class
for fetching files. I just extended that to handle these gzipped files.
But, I think your solution is a bit more elegant and, well, more correct
because it can be used more widely.
Thanks,
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
