Request.stream doesn't trigger('response')

[astro]

Implication: when I use stream() plugins such as Cookie don't work.

[aheckmann]

It is currently being triggered? http://github.com/visionmedia/express/blob/master/lib/express/request.js#L251
How do you have it set up?

[astro]

I'm just using stream() in combination with the Session plugin, requiring the Cookie plugin.

The problem with line 251 is that 'response' is now triggered on 'end'. The Cookie 'response' handler wants to add response headers (Set-Cookie:), so this needs to happen before sendHead().

[aheckmann]

ooh yeah. yuck. I think we should hold off a bit on this until TJ is finished rewriting Express to use Connect next week. It would be best addressed there I think

[astro]

Nope, like this:

http://github.com/astro/express/commit/2ec9db859fce124739fd694b828c5b0ff487143e

[tj]

Yeah I'm not accepting patches on this branch. Also re your tweet feel free to work on the "crappy view system" in the connect branch.

[astro]

The master branch wasn't visibly abandoned to me. Now that I know connect I found it sufficient for my tasks.

The view system is crappy because it isn't asynchronous, node's most prominent code pattern.

[aheckmann]

if you take a closer look you'll see that all views and partials are cached when running in production and are also configurable. this works well b/c it keeps the code simple and fast. we had truly async partials but the code got more complex for no real benefit. async in development mode doesn't matter.

[tj]

yeah exactly. it is easy to argue that views should have async support, and in some cases I totally agree, however for rendering html I find the use case for this extremely low. Mu is no faster (infact slower) than haml.js for example.

Logic should be in the "route" handler, I dont like the idea of views hitting the database etc. When a practical need for async support exists then I will gladly support it, however at the moment I dont see the need for this. If you are generating a feed or something, its great, but then there is also not really a need to use the view system at all

[tj]

blah lol github didnt post my reply. There is very little (practical) need for async views, I dont want that sort of logic in views, and Mu is no faster (infact slower) than haml.js. There is no reason you cant do async stuff before handing over to the view system, which IMO is the way it should be. If / when practical use cases appear I will happily support async template engines.

We have already been discussing this in IRC, and many of us agree that flushing the document HEAD early should be obtainable, but all of these async partial hacks etc are completely unnecessary

[aheckmann]

i got the email tho

[tj]

weird lol