Using CollectionExtensions instead of Meteor?
zimme opened this issue · comments
How about using your own CollectionExtensions "namespace" instead of meteor's Meteor "namespace".
They've advised against using their namespace to prevent future collisions of functionality.
CollectionExtensions.addExtension and CollectionExtensions.addPrototype would be nice.
I'm gonna look into using this package for my zimme:collection-behaviours which is a re-write of sewdn:collection-behaviours package. I've added configuration and a couple of other things and it's used by zimme:collection-timestampable and zimme:collection-softremovable, which have support for aldeed:autoform, aldeed:collection2 and aldeed:simple-schema.
I'm thinking I can use this package for automagically adding the behaviours of the packages to collections.
I just need to figure out a good way to make it respect a user configurable exception list.
This is needed because for now you may only attach a behaviour and not detach it. And even if you wanna have all your collections by default use one of the behaviours you still might not want it on a specific collection.
Oh that's nice. I was thinking of changing the namespace actually so I will definitely do that. It's good to see that you're interested in using it. I'll update it tonight.
I would recommend that you keep Meteor for at least a version or two, with a deprecation warning, as others are depending on this package now. Another option is to release a new major version and don't keep backwards compatibility.
Nevermind, I just saw that you're using development versioning. So a bump to 0.2.0 should be considered "major" and shouldn't expect backwards compatibility I believe.
I was thinking of keeping backwards compatibility. Also, I'll have to work on this tomorrow.
Okay all good now.