Make it possible to remove or rename the default mutator methods about guide HOT 11 CLOSED

I think ideally there'd be a way to opt out of allow/deny and thus these methods would never be created in the first place. I've no idea of the complexity of this though -- do you have an idea @stubailo?

from guide.

I think it shouldn't be too hard! Would allow/deny be a separate package then? What's the optimal UX?

from guide.

How's this:

1. There are two packages:
   • allow-deny that adds the methods, Collection.prototype.insert/update/remove on the client, Collection.prototype.allow/deny on the server.
   • insecure - which depends on the above but removes allow/deny (or whatever it does right now).
2. A new app comes with insecure turned on (shudder).
3. When you remove it, you have nothing, and you need to add allow-deny if you want it.
   • but maybe for a release or two we wire up Collection.prototype.allow/deny to print a warning that you need to add the allow-deny package.

The scary part is that packages can depend on allow-deny. I don't know what to do about that.

from guide.

The scary part is that packages can depend on allow-deny. I don't know what to do about that.

One option could be - you have to declare that you are turning on allow/deny when you initialize the colllection. That way, a package can't accidentally turn it on?

I wonder if there's a market for collection "mixins"? Because the road we are heading down includes lots of configuration and even inheritance for collections, for example to make a validated collection. If there are many packages on atmosphere that add various features to collections, for example validation, basic security, default fields, collection helpers, etc, how are they supposed to do that without overriding the prototype or inheriting?

from guide.

I think mixins make sense but maybe in a world where you inherit from mongo
collection, ala rails?

Anyway I suspect you'd want a way to turn allow/deny on for everything, at
least if consistency with the way current meteor works was desired. But
maybe that's not the case?
On Wed, 21 Oct 2015 at 5:24 PM, Sashko Stubailo [email protected]
wrote:

The scary part is that packages can depend on allow-deny. I don't know
what to do about that.

One option could be - you have to declare that you are turning on
allow/deny when you initialize the colllection. That way, a package can't
accidentally turn it on?

I wonder if there's a market for collection "mixins"? Because the road we
are heading down includes lots of configuration and even inheritance for
collections, for example to make a validated collection. If there are many
packages on atmosphere that add various features to collections, for
example validation, basic security, default fields, collection helpers,
etc, how are they supposed to do that without overriding the prototype or
inheriting?

—
Reply to this email directly or view it on GitHub
#47 (comment).

from guide.

I guess the methods could be defined at the point you first call allow for
a collection too..
On Wed, 21 Oct 2015 at 9:40 PM, Tom Coleman [email protected] wrote:

I think mixins make sense but maybe in a world where you inherit from
mongo collection, ala rails?

Anyway I suspect you'd want a way to turn allow/deny on for everything, at
least if consistency with the way current meteor works was desired. But
maybe that's not the case?
On Wed, 21 Oct 2015 at 5:24 PM, Sashko Stubailo [email protected]
wrote:

The scary part is that packages can depend on allow-deny. I don't know
what to do about that.

One option could be - you have to declare that you are turning on
allow/deny when you initialize the colllection. That way, a package
can't accidentally turn it on?

I wonder if there's a market for collection "mixins"? Because the road we
are heading down includes lots of configuration and even inheritance for
collections, for example to make a validated collection. If there are many
packages on atmosphere that add various features to collections, for
example validation, basic security, default fields, collection helpers,
etc, how are they supposed to do that without overriding the prototype or
inheriting?

—
Reply to this email directly or view it on GitHub
#47 (comment).

from guide.

Wow funny - there's already an issue for something similar on Meteor: meteor/meteor#5096

from guide.

That is in no way surprising ;)

from guide.

+1

from guide.

First step PR WIP: meteor/meteor#5559

from guide.

Going to close this since there is some work on Meteor, and it's not a blocker for the guide.

from guide.