raix/Meteor-CollectionFS — pull request #48 by aldeed (2013-06-12 01:25:51+00:00)
Title: Built-ins, fixes, etc.

This isn't quite ready for pulling yet, but I wanted to start the request so that you know what I'm working on. I needed to do similar things for a project I'm working on, so I figured I might as well do it all generically for the benefit of all.

Unfortunately, I somehow messed up my git tracking, so it's not showing the individual line changes for any of the files. I changed quite a bit in several files, though. I apologize. I'll try to point out the places in which files I changed.

I think I'll have time to finish up the rest later this week. You may want to pull this before your rewrite, or maybe into a separate branch for the rewrite? Not sure what your plans are in that respect. Also, I don't know what your preferences are for code formatting. My editor autoformats files the way I like them when I save, so the files may not be what you like. If you let me know what you prefer, I can reformat them to match.

- [x] Added many built-in handlebar helpers. In a new file: collectionFS_handlebars.js. (The fileInput one isn't working yet. Still messing around with ideas.)
- [x] Created a new project in the examples folder, illustrating usage of the built-in helpers and other stuff. This still needs work, and drag/drop copy/paste aren't implemented yet.
- [x] Added underscore dependency. I read that meteor soon won't include this in the core.
- [x] Fixed some Deps issues in collectionFS_client.api.js. Also reworked some of the code that didn't seem to be working quite right.
- [x] Added isUploading in collectionFS_client.api.js.
- [x] Added CollectionFS.fileFilter and CollectionFS.fileIsAllowed in common.js. These provide a quick way to prevent certain file types or extensions from being uploaded. It's easier than checking in the allow.insert function. To use this feature, you call fileFilter with an object that defines which file types should be allowed or denied. You can mix and match filtering based on extension or content types. The `contentTypes` array also supports "image/*" and "audio/*" and "video/*" like the "accepts" attribute on the HTML file element. CollectionFS.fileIsAllowed checks a given file against these rules.
- [x] In common.js, I changed the find(), etc. passthrough functions. The way they were before, you had to do `find({})`, for example. Now, `find()` will work and they are more future-proof.

```javascript
{
allow: {
extensions: [],
contentTypes: []
},
deny: {
extensions: [],
contentTypes: []
},
}
```

- [x] Added numeral.js file and use it to support the new {{formattedSize}} built-in helper. Gives the user lots of options

Still need to do:
- [ ] Built-in filehandlers for images using GraphicsMagik
- [ ] Built-in filehandlers for saving to some common cloud drives
- [ ] Finish the new example app. Add drag/drop and copy/paste support.

Questions:
* Should we prefix the handlebar helper names with "cfs"?
* Should examples be moved to another github repo or their own branch? It doesn't make much sense to have the examples copied into your project folder when you `mrt add collectionFS`

Ideas:
* Maybe rather than defining a single function per filehandler, the user should define an "insert" filehandler and a "remove" filehandler. This could replace the somewhat hackish code that deletes cached files from the local filesystem when .remove is called. The idea being that the user could define a filehandler group where the insert function saves to S3, for example, and the delete function deletes from S3. Haven't thought this through much, so there may be gotchas.
* Some kind of auto-recaching? Somewhere in the flow, maybe when retrieving file info from the DB, CFS could automatically try to access each filehandler.url. If not present, re-run the filehandler to recreate it? Basically some insurance against accidental deletion of the cached files. Probably would be opt-in.