Full rewrite

[creynders]

Hiya,

here we go: canned.js and parser.js

So in a nutshell, what I did: I turned canned into an express app and exposed a serve method which allows it to be used in express with app.use(canned.serve(myDir)) (obviously in the latter case it won't set up an express server of its own) Then, parser.js reads the contents of the to-be-serverd directory, strips the extension of the filename and maps the result to the full file path in a hash. Then when a request is made it uses the hash to look up what file it needs to read. If the file is .js it's required and the exposed function is called. In all other cases the file is read and it's contents are searched for headers:

/*headers
{
    "Content-Type": "application/vnd.custom+json",
    "Content-Disposition": "attachment"
}
*/

Headers must be declared as a json object, it has a number of benefits, but the main one is: you can create a .js file which reads a json file (depending on the route for instance, or the number of times the route is hit) and dumps it as a header in the output. If the Content-type header is not set, mime is used to determine the content type by file extension.

Routes are resolved as follows: it will always try to find the file that closest matches the entire url first. E.g: GET /foo/bar/baz?qux=something will match the files, in the following order: (the file name is code-formatted below)

• /foo/bar/baz?qux=something/GET.*
• /foo/bar/baz?qux=something.*
• /foo/bar/baz/GET.*
• /foo/bar/baz.*
• /foo/bar/GET.*
• /foo/bar.*
• /foo/GET.*
• /foo.*
• /GET.*

I know it's not backwards compatible, but IMO this is a cleaner and more flexible approach. And, there's not a large user base (yet), so I think we could get away with it. + migration is pretty easy.

It's quite a different approach, just let me know what you think!!

I haven't updated the bin nor the documentation or tests yet, I wanted to hear your opinion first...

[sideshowcoder]

Sorry to get back to you so late I just wanted to let you know I haven't forgotten about this, and will review tomorrow where I blocked some time for it! Thanks for your work in advance and I'll get back to you tomorrow.

[sideshowcoder]

Hey so I looked over the code and just wanted to give you my opinion:

First a couple things which I think are awesome to have:

• Flexible header format is great!
• Integration in express is great to have as well
• Code looks really clean so it would be great to have it just for that :)

There are a couple things I'm not sure about:

• Having a dependency to express seems like a lot of overhead for something like this and personally I would rather use some smaller router Library instead of whole express, but it really depends on what people use it for. I personally mainly use it for testing so I don't really care about pulling in express but I'm kind of unsure about it. We could have the express integration without the dependency I think by offering a small wrapper instead of wiring it in, but I haven't really investigated this yet.
• Tieing this so close to express I fear will make it harder to use in some other frameworks since express really has it's own special way of doing things
• The Matching sadly suffers from the same problem as the current implementation, which is that it does not work on windows for GET parameters see #19 and having the parameters as part of the folder seems to make it harder to get rid of this problem.

What do you think about opening a PR and we move it to a express-canned branch for now so we can try it out a little more and have it inside this repository? I feel like there is stuff to integrate from both sides and I would like to put more thought and work into it.

There is really nothing I dislike more like things I'm not sure about really how they pan out. Maybe @runemadsen has an opinion on this as well?

Thanks for all your work it's great to see such intresst in something I wrote :+1:

[creynders]

Ah, I'm glad there's stuff you like ;)

Re: express. I don't think it matters a lot in this case. The only use cases I can imagine for canned are during development in which case speed, etc isn't much of an issue. Also, most of the times this will be used stand-alone, not integrated into a project in which case again the dependency on express doesn't matter.
However it does have some benefits:

• Express is extremely wide-spread with a large community, this could boost both usage and contribution.
• It's easy to use and integrate
• No reinventing the wheel ;)

Re: the matching. Damn, hadn't realised that. We'll need to rethink how methods and query parameters are mapped.

What do you think about opening a PR and we move it to a express-canned branch for now

Will do!

[sideshowcoder]

merged in #33