CoreData example not working about swiftddp HOT 7 CLOSED

For reference, this update enables fetching data from the server with the latest Todos antonioandrade@23cc42e
Since the Todos methods have changed so much, other functions probably remain broken.

from swiftddp.

Yea, you're right. It's changed a lot. it looks like they're wrapped the Mongo collection methods in regular methods with simple schema validation. Still looking it over, but if you want to create a pull request, I'll merge your changes.

from swiftddp.

Hey @siegesmund. Thanks for the #41 merge (though it doesn't bring us very far).

I've digged in some more and came up with a couple of thoughts:

• They really seem to have changed to method naming. To make List inserts work, I made this change antonioandrade@70aa111. This makes me question whether SwiftDDP is making assumptions too deeply? I mean, the dot-slash notation. I might be missing part of the protocol though.
• I don't really understand why this line https://github.com/meteor/todos/blob/b2c540a191199736c36362342f027e2df99e2061/imports/api/lists/methods.js#L15 reads new SimpleSchema({}).validator() instead of Lists.schema.validator(). Making this change allows List inserts to work, properly validated, considering the point above. Thoughts?

Cheers

from swiftddp.

Thanks for putting some thought into this.

I don't think that changing the name of the method on insert is the way to go.

The way I read it is this: When you use a client-side collection inserts, updates etc. (mini mongo for example), the collection insert/update/delete api is actually a wrapper around a regular Meteor method. That's what you saw, and what you changed in @70aa111. Changing this might make it work in this instance, but it will break inserts in every other instance.

The meteor collection api is secured using Allow/Deny rules, but Allow/Deny rules have fallen out of favor because they're confusing and easy to misconfigure. It's also hard to validate inputs. Thus, a better practice is to use plain Meteor methods and implement your authorization logic explicitly. That's what they've done here. So to access them, we need to use Meteor.call instead of Collection.insert.

Regarding your second question. It's new SimpleSchema({}).validator() because you're using SimpleSchema to merely validate the method arguments against the object you pass, rather than validating a document against the collection/document schema. So, new SimpleSchema({}).validator() indicates that it should not accept any arguments, whereas new SimpleSchema({ listId: { type: String }, newName: { type: String }, }).validator() indicates that it should accept two arguments of type string.

Thoughts?

from swiftddp.

Hey @siegesmund. I now got most SwiftDDP aspects working on my original project so this was a good learning piece. It's a really nice library.

The first point makes sense. I might be pushing some more updates to the example in that direction.

In regards to the validation point, though I believe I correctly got the concept, I still think my change makes most sense: new Lists should at least require a name and incompleteCount (the List schema), instead of validating the non-existence of arguments, right? Otherwise I get the error keyNotInSchema error below:

[Debug] [DDP] [0x7fef906f6d80] [260] ddpMessageHandler > Received message: {
    error =     {
        details =         (
                        {
                details =                 {
                    value = NewListName;
                };
                name = name;
                type = keyNotInSchema;
            },
                        {
                details =                 {
                    value = 0;
                };
                name = incompleteCount;
                type = keyNotInSchema;
            }
        );
        error = "validation-error";
        errorType = "Meteor.Error";
        message = "name is not allowed by the schema [validation-error]";
        reason = "name is not allowed by the schema";
    };
    id = C01640B20F0f48D8900E890863045794;
    msg = result;
}

from swiftddp.

Regarding your second question: Yea, maybe I misunderstood what you were asking. To be honest, I don't really understand why they've done it that way either. Maybe I would if I looked at it longer, but It looks sort of unfinished to me, unless they just wanted to demonstrate the way to validate no arguments. You could open an issue on the repo and ask/suggest a change :).

Meteor has been changing a lot lately, and I don't have as much time as I'd like to keep the examples up to date, so thanks for putting so much thought into this.

from swiftddp.

Ended up removing the examples; not enough time to keep them up to date with the changes to Meteor.

from swiftddp.