WIP: A more sophisticated set of blueprints #9
Conversation
|
@Globegitter please take a look at this and let me know what you think? (Also... I need to add the camelCase fix here...) |
|
👍 |
|
@mphasize Good that you are starting a discussion here. After seeing json-api/json-api#341 and emberjs/data#1988 (comment) I was thinking maybe we can have a set of jsonapi blueprints and also rename it to that, to leave it more open to a wider audience that wants to use jsonapi. I haven't looked at the latest specs properly yet and it is of course still WIP but I think it would be the most future-proof decision. So what are your thoughts about that? Also /cc @wayne-o @kriswill @mgenev But back to your original proposal, how exactly would the differentiation be between basic and advanced? Would that be two different Will also take a look at the code itself now :) |
|
I like this idea a lot and I will gladly work on it. I was extending the current blueprints yesterday to support geo querying with mongo, postgres has that ability too with with postGIS. I know that @kriswill has a good convention for a pod-like api structure which would be awesome. |
|
Wonderful! So in order:
|
|
Also check out ember-data-endpoints which is being done by @bmac, core ember and ember-data contributor, and the original author of the ember-data-sails-adapter project. |
|
I am really interested in this thread. It all sounds great. I am going to On Thu, Feb 19, 2015 at 7:56 PM, Kris Williams notifications@github.com
-------------------- w:// t: 07508 215 459 -------------------- |
|
Some more info / questions around configuring json api output: In the new blueprints I am introducing 2 ways to configure how associations are handled in the json output:
In module.exports.models = {
associations: {
list: "link",
detail: "record"
}
};An in module.exports = {
attributes: {
name : "string",
posts: {
collection: "post",
via: "user",
includeIn: {
list: "record",
detail: "record"
}
}
}
};Depending on the blueprint, it will either use the What's your take on such fine-grained control and specifying this on the |
|
@mphasize lets make a sails hook for this feature ! |
|
@albertosouza I think the scope of the "advanced" blueprints is a bit broader than what I can see in the other hooks you mentioned here https://github.com/mphasize/sails-ember-blueprints/issues/4 Or did I miss something? |
|
@mphasize yes, you are right but we can create a hook to add these blueprints in the sails, i can help with the development of the hook as it will be useful for my projects change sails-generate-ember-blueprints to sails-hook-ember-blueprints |
Setting `res.status(201)` but then using `res.ok()` afterwards would reset the status code to 200, which we don’t want.
…ed this as a function to the Ember service.
… dependencies and removes the necessity to install `lodash` and `pluralize` after installing the generator.
|
@Globegitter Any more thoughts on this? I just added the "shallow" blueprint generation we discussed earlier... |
|
@mphasize Not quite sure about the different benefits of hook vs generators at this point (even though I am using hooks and liking them). It would not fill up the blueprints folder then? And will look over the naming tomorrow if it makes intuitive sense to me :) |
|
And yes 👍 👍 on tests :P Could potentially help on that front a bit. |
| } ); | ||
| }, | ||
|
|
||
| emberizeModelIdentity: function ( model ) { |
There was a problem hiding this comment.
Now that we are using lodash 3.x we don't need that helper function anymore and could just use https://lodash.com/docs#camelCase
|
No worries. I will hold the next "publish" and version bump until we got it all figured out and we need the fix anyway. Is the whole camelCase issue resolved with that? |
|
As far as I can tell yes. But also I haven't taken a step back yet and though it these are all the cases that could come up. |
|
I was already on it lol! WORKS LIKE A CHARM!!!! Good job guys - seriously! On Wed, Feb 25, 2015 at 7:13 PM, Marcus notifications@github.com wrote:
-------------------- w:// t: 07508 215 459 -------------------- |
|
@Globegitter I will need a bit more time to think through all the ideas and suggestions - hopefully towards the end of the week, but maybe I can answer this straight away: How the sideload is performed:
Does this clarify what happens for you? |
|
@Globegitter Btw. at the point where we tell Waterline which associations to populate, we could look for further parameters in the API request to change what is included/sideloaded. |
|
@wayne-o Thanks and good to hear that it's working. :) |
|
Alright... back to this again. However, it feels like we're overloading the scope of the blueprints when we introduce all of this, so I took a step back and had another look at Sails policies (because that's where stuff like access control) should belong according to the Sails philosophy. Digging deeper I found a couple of convenient things that Sails sets in req.options and that is accessible in the policies, so I am pretty confident that I can create a policy that handles the accessControl stuff and links to functions in the Model or wherever we want to put them. It should also allow us to keep the blueprints neat and clean. I'll do some further experiments today and if everything turns out well, I will probably separate the accessControl efforts into their own project. |
…olicy. Remove the inject user into create record values (again this fits better into a policy).
| * @param {[type]} associations [description] | ||
| * @param {Function} done [description] | ||
| */ | ||
| populateIndexes: function ( parentModel, ids, associations, done ) { |
There was a problem hiding this comment.
Can anybody verify that this method runs as expected on a Mongo/NoSQL database? (It's used in find and findOne blueprints). Set sideloading to index to enable this.
There was a problem hiding this comment.
@mgenev Maybe you can give that a try at some point?
There was a problem hiding this comment.
I should be able to give this a spin later today
On Mon, Mar 2, 2015 at 2:50 PM, Markus Padourek notifications@github.com
wrote:
In templates/advanced/api/blueprints/_util/actionUtil.js
#9 (comment)
:
console.log( "Dev: Model " + model.identity + " is missing control " + action + "!" );if ( callback ) {callback( null, primaryArgument );}}return primaryArgument;- },
- /**
- * helper function to populate a record with an array for indexes for associated models, running various Waterline queries on the join tables if neccessary ( defined as: include -> index )
- * @param {Waterine Collection} parentModel [description]
- * @param {Array|Integer} ids [description]
- * @param {[type]} associations [description]
- * @param {Function} done [description]
- */
- populateIndexes: function ( parentModel, ids, associations, done ) {
@mgenev https://github.com/mgenev Maybe you can give that a try at some
point?—
Reply to this email directly or view it on GitHub
https://github.com/mphasize/sails-generate-ember-blueprints/pull/9/files#r25602915
.
--------------------
w://
t: 07508 215 459
--------------------
| if(!_.isNumber(array[0]) && !_.isString(array[0])) { // this is probably an array of records | ||
| var model = sails.models[ pluralize(key, 1) ]; | ||
| console.log("Sideloaded records model: ", model.identity); | ||
| Ember.linkAssociations(model, array); |
|
Alright, this has been an enlightening discussion throughout for me and inspired a lot of good stuff, but this PR is getting a bit heavy and difficult to navigate, so... I documented further todos in the roadmap issues #17 and #18. Please feel free to add more suggestions and continue discussion over there. Since this PR will not change existing setups, I'm going to merge it into master as soon as @mgenev or @wayne-o give us (hopefully) positive feedback on MongoDB. Then we can tackle the remaining issues in other PRs. |
|
@mphasize Yep that sounds like a good way forward :) |
…ly included in the primary record.
|
Any news on Mongo? |
|
Sorry, no, I set everything up for a test on monday, but had to go to emberconf, now I'm back and I should be able to do the test finally. |
…One) associations Also, we can always use the plural identifier for records
|
@mphasize i'm not seeing if i'm installing from the branch correctly. I downloaded this branch and put it in my new project's node_modules dir, I did generate advanced, and the crud methods now point to the /node_modules/sails-generate-ember-blueprints. However, the /api/blueprints/_util/actionUtil remained the old one and when i try to lift I get: am i missing a step somewhere, doing something wrong? _EDIT_ |
|
@mphasize If I understood you correctly you wanted to see if the array of index as an option works with mongo. To do this, I set this in the global model config: This did indeed with no visible error produce the array like this (vendors belong to users): After that I switched to: And this once again with no error produced the entire records sideloaded: As you can see above I'm also getting meta total. I tested 'link' as well and it produced: which I then hit in the browser and it gave me the list of the vendors for that user with no hesitation. Applause! This is great work and I'll be including it in app as soon as you merge it and give it a thorough test over time in different situations. My question is, and excuse me if the docs answer it but i haven't noticed, do I have a way of altering this behavior from Ember, on a per request basis like this: Or whether this clicks with the ember data's 'async' flag on associations I set on the client. This way I could finely control my app's loading behaviors and load whole records async later if I need to as each situation calls for. Once again, this is awesome! |
|
@mgenev Wonderful news! Thanks a lot for trying it out. The results look the way they should be, so I assume that there's at least no general problem and we will have to iron out bugs when they manifest. Concerning your question: At the moment you cannot control which associations will be included on a per-request basis. It's on the roadmap, but it's not in the blueprints yet. There's a bit more security thinking necessary, as people requesting data from your API can easily change the query and potentially create a situation with a lot of heavy includes. Example: // in /api/models/user.js
module.exports = {
attributes: {
// ...
posts: {
collection: "post",
via: "user",
includeIn: {
list: "link",
detail: "link"
}
}
}
}Thanks again for your feedback! I'll go ahead and merge this into master now, then I'll give it a bit more time to stew before I release it to npm. |
A more sophisticated set of blueprints, install using `sails generate ember-blueprints advanced`
|
Excellent. Please give me heads up when it's on npm and I'll add it to https://github.com/mgenev/how-to-sane which would allow a whole bunch of people to report bugs. I'll be away from computers for 2 weeks starting tonight, but i'll try to keep up with reading on my tablet |
Hej, I've been working on an "advanced" set of blueprints for some time now and I think it's time to discuss this.
As a preparation I enabled the generator to support different "flavors" of blueprints and I'm keeping the original blueprints around as a "basic" flavor and added the new blueprints as an "advanced" flavor.
So what do these new blueprints do?
metainformation tofindqueries, which enable pagination on the client sideWhat needs to be done?
lodashandpluralizeas separate dependenciesbuildResponseto remove single record output in object style. Instead use array, as it is apparently preferred by Ember Data even for single records.Happy to get some feedback on this and do some further planning...