Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 04:52
    MikeBarberry-Flatiron starred balderdashy/sails
  • May 15 22:51
    vettloffah edited #7120
  • May 15 22:51
    sailsbot commented #7120
  • May 15 22:51
    vettloffah opened #7120
  • May 15 22:45
    hartatovich edited #7119
  • May 15 22:42
    hartatovich edited #7119
  • May 15 22:38
    hartatovich edited #7119
  • May 15 22:36
    sailsbot commented #7119
  • May 15 22:36
    hartatovich opened #7119
  • May 15 16:48
    j-elmer123 starred balderdashy/sails
  • May 15 14:58
    lululau starred balderdashy/sails
  • May 15 14:36
    phoxiao starred balderdashy/sails
  • May 15 06:54

    eashaw on disable-console-autocomplete

    pass in preview option to REPL.… (compare)

  • May 15 03:47
    jlimas closed #7114
  • May 14 17:36
    Nerah starred balderdashy/sails
  • May 14 13:31
    eashaw labeled #4592
  • May 14 13:31
    eashaw commented #4592
  • May 14 03:43
    ericdong79 starred balderdashy/waterline
  • May 13 19:45
    eashaw labeled #4632
  • May 13 19:45
    eashaw commented #4632
Gleb Vishnevsky
@kaikash
@mikermcneil wow, thanks, but.. why? For example if you have a book and there is no page #0. I think it must start with 1
Oliver Kühne
@oliverkuehne
hi
Why is foundProductAfterCreate empty?
MongoPicklistProducts.create(product).then(function(createdProduct) {
                            MongoPicklistProducts.find({_id : createdProduct.id}).then(function(foundProductAfterCreate) {
                                console.log(foundProductAfterCreate);
                            })
                        });
赵培炜
@TonyZPW
could someone tell me how to response xml format
i can use express-xml-parser to parse xml request but how to response xml format to server?
i use res.set('Content-Type', 'application/xml');
res.ok(xmlStr); but it seems not working
Alexandre Madurell
@amadurell
@TonyZPW I'm not sure this is the best way to, but I defined an 'xml' responseType that I use as possible exit in an actions2 action
Oliver Kühne
@oliverkuehne
@TonyZPW have you try res.send(xmlStr);
Alexandre Madurell
@amadurell
@TonyZPW This is my api/responses/xml.js file:
module.exports = function xml(optionalData) {

  // Get access to `req` and `res`
  let req = this.req;
  let res = this.res;

  // Define the status code to send in the response.
  let statusCodeToSet = 200;

  // If no data was provided, use res.sendStatus().
  if (optionalData === undefined) {
    sails.log.info('Ran custom response: res.xml()');
    return res.sendStatus(statusCodeToSet);
  }
  // Else if the provided data is an Error instance, if it has
  // a toJSON() function, then always run it and use it as the
  // response body to send.  Otherwise, send down its `.stack`,
  // except in production use res.sendStatus().
  else if (_.isError(optionalData)) {
    sails.log.info('Custom response `res.xml()` called with an Error:', optionalData);

    // If the error doesn't have a custom .toJSON(), use its `stack` instead--
    // otherwise res.json() would turn it into an empty dictionary.
    // (If this is production, don't send a response body at all.)
    if (!_.isFunction(optionalData.toJSON)) {
      if (process.env.NODE_ENV === 'production') {
        return res.sendStatus(statusCodeToSet);
      }
      else {
        return res.status(statusCodeToSet).send(optionalData.stack);
      }
    }
  }
  // Set status code and send response data.
  else {
    res.type('text/xml');
    res.status(statusCodeToSet);
    res.send(optionalData);
    return res;
    // return res.status(statusCodeToSet).type('text/xml').send(optionalData);
  }
};

@TonyZPW Within my action:

  exits: {
    error: {
      responseType: ''
    },
    success: {
      responseType: 'xml'
    },
...

and within the fn: function (inputs, exits) {

...
return exits.success(abre);
...

where abre is an xml string.

martskins
@martskins
@kaikash I kinda feel the same way about the page number thing
but I can make peace with it if I interpret pageNum as pageIndex or something like that, cause I do realize that changing that pageNum to start at 1 could potentially break a lot of stuff for those who update
Alexandre Madurell
@amadurell
@TonyZPW In summary, I think this is what you need:
  res.type('text/xml');
  res.status(200);
  res.send(xmlStr);
  return res;
赵培炜
@TonyZPW
@amadurell @oliverkuehne thanks very much. it works
Alexandre Madurell
@amadurell
@TonyZPW @oliverkuehne :)
Oliver Kühne
@oliverkuehne
:)
Jordi Hereu
@jhereu
@ChrisWorks you can use async to acomplish the same result
ChrisWorks
@ChrisWorks
@jhereu Do you have an example? I know I can just have a more complicated afterCreate function, but I find the other way was much nicer. Especially when extending objects. E.g. if you have a Person model it was easy to extend it (e.g. Child) and also add special afterCreate functions only for the Child.
martskins
@martskins
I would avoid calling the afterCreate of Person (in your example) cause it could get messy with the next calls but it should look something like this
// Child.js
afterCreate: async function (values, next) {
    await Person.someCommonMethod(values);  // Assuming all these return promises
    await Child.someOtherMethod(values);
    await finallyDoThisToo(values);
    next();
}
it's kinda messy by itself though, cause of the next callback and async/await mix up
that would be nice to see, promisified lifecycle callbacks
ChrisWorks
@ChrisWorks
@martskins This does not really fix the principle I think. The Child.js should not have to know the functions needed to be called on the Person.js. I think a more generalized approach would be better. Would this be legal:
// Child.js
afterCreate: async function (values, next) {
    await Super.afterCreate(values);  // Assuming all these return promises
    await Child.someOtherMethod(values);
    await finallyDoThisToo(values);
    next();
}
martskins
@martskins
it will probably fail due to the missing next param, but anyway .. even if it does work it's really untidy.. because for that to work Super.afterCreate should return a promise.. and calling next() (inside Super.afterCreate) and returning a Promise after that seems like a mess to me
mixing callbacks and promises is generally a bad idea
what I would do is move the logic in Super.afterCreate to another method.. Super.postCreate or something.. and call postCreate both in Super.afterCreate and Child.afterCreate
martskins
@martskins
it doesn't really solve the mess all the way (promisified lifecycle callbacks would) but it's better in my opinion
ChrisWorks
@ChrisWorks
@martskins Yes, it is perhaps the least messy option, but it is a shame there is not a cleaner way. It is annoying the old way of injecting functions into a lifeCycle array is not supported anymore as this now also creates a lot more work when migrating from 0.12 to v1
Jordi Hereu
@jhereu
@ChrisWorks Sure! Having async, you could use sails lifecycle as a caller to this secuence of functions you had before, as in:
afterCreate: function (values, next) {
         var async = require("async");
         async.waterfall([
                  function myFunctionOne (callback) {
                            // whatever logic
                            return callback(err, data1);        
                  },
                  function myFunctionTwo(data1, callback) {
                           // whatever logic
                           // arg data1 is the returned arg from myFunctionOne
                           return callback(err, data2);
                  },
         ...
        ], function onDone(err, data) {
                  // finished
                  // err is whichever error you returned. Once a function from the waterfall fails, process is stopped and onDone is called
                  // data is the returned data from the last function of the waterfall
                  return next();
         });
}
for more intel about async, here you have the docs http://caolan.github.io/async/
ChrisWorks
@ChrisWorks
@jhereu Thanks, but I was looking for if you meant that async could do the same as defining the afterCreate as an array of functions. And your async approach cannot do that. As per discussion with @martskins this is not a callback vs async issue but how the old "way" allowed me NOT to worry about what other functions needing called.
@jhereu @martskins I dont really know why the array declarations for lifeCycle functions was removed. It could have been implemented to allow async functions to be added instead of callbacks if that was the issue.
@mikermcneil Why was the array declaration of lifeCycle functions removed?
Jordi Hereu
@jhereu
@ChrisWorks Oh, then I would do a custom global function to pass the array of functions you used before as arguments and call them synchronously as I said before with the async method, to change your current code the less as possible

something like...

function execute (funcs) {
   async.waterfall(funcs, function onDone() {
      return cb();
   );
}

and model:

{
   ...
   afterCreate: exec([func1, func2, func3...])   
}
Daniel Elidio Mendes Jr.
@danielelidio
Hi everyone
I have a question over here regarding v1.x
is this version supposed to accept create nested associated objects in a single request? I mean, let suppose that we have a model 'person' which has many 'addresses'
if I send a post like:
{
"first_name": '...', "last_name": '...',
"addresses": [{addressLine1: "...", "city": "..."}]
}
I got an error telling me that sails was waiting to receive an array of primary keys for addresses...
Mike McNeil
@mikermcneil

@chrisworks the team’s philosophy with v1 any time we discovered a bug, or major inconsistency, or recommendation we found confusing was “Why should we keep this in core?”

Sails is huge, spanning many repos. It’s super easy for us to forget something exists if we never use it ourselves on the core team. So if we run across something that encourages patterns we no longer advocate, it’s tricky. We want backward compatibility as much as possible, but the code that implements said backwards compatibility is heavy and it dramatically slows down how long it takes us to add new features— or worse, we add them but with bugs. (I can’t imagine how long it would have taken to add soft deletes and at-rest encryption this Fall if we hadn’t cleaned things up first)

And also at the same time, it’s not just about compatibility— it’s about convention over configuration for consistency between projects, having better error messages for bad usage or mismatched config, and ensuring that the framework you’re placing your trust in has as few “unconsidered edge cases” as possible.

For example, who knows whether we did an isArray check for lifecycle callbacks before? If we had done if (_.isFunction(lc)) { /*...*/ } else { /* ...handle array of functions */ } then who knows what would happen if you passed in a dictionary like {}? Or like... NaN? Worst of all, you might not see an error at all, and then later on get really confused by several little things like that stacked on top of each other. And that’s a terrible experience for any developer to have to go through! Plus it chews up engineering hours— a perfect example of “technical debt”.

So in Sails v1, we’re laying down the law. Anytime there was an opportunity to simplify something like that and eliminate some bloat, we weighed the compatibility cost and in many cases, made breaking change.

If something was an experimental feature we didn’t advocate using, or that was never documented because it was too hacky, it was out. Any feature that was originally a from a “guilt merge” PR instead of based on its merits: that was out too. And, most numerous of all, things that were originally my “brilliant” idea, and that I advocated for fervently, but was flat out wrong about 😫 (eg the whole custom adapter methods thing 😣). We axed those too

I realize it’s kinda annoying right now as you upgrade your app to v1. Sorry about that. Please just keep in mind that, when you’re finished, there’ll be a much better chance that the features you’re using in Sails are things that its author and maintainers understand and use almost every day. And you won’t have to do it anything like it again for a long while— not until sails 2.0 becomes a thing– and even then, it’ll probably never be to this extent again. (Like Node core, our contribution guidelines and processes have matured a lot over the last 5 years)

Alexandre Madurell
@amadurell
Sargo Darya
@SargoDarya
And here I am being glad that this is just being maintained xD
Alexandre Madurell
@amadurell
@SargoDarya is right, @mikermcneil Next time either of you is around Milan, I'll gladly invite you to italian icecream. :)
Jonathan Leek
@mrjonleek
Hey all, using Sails 1 finally (it’s great!) - I’m used to relying on the beforeValidate method to normalize some data before “insert” but I can’t seem to access that hook in 1. Is there an alternative approach?
ChrisWorks
@ChrisWorks
@mikermcneil I get what you are saying and your points are valid, and though backwards compatibility would be ideal I understand that with the resources available it will not be possible. I do think it would be beneficial for the sails community if there were more information on best-practices when trying to re-implement / migrate some 0.12 code to v1. For instance with the array declarations of the lifeCycle callbacks in v.12, what are the options in v1? and what is the preferred pattern from the experts? :smile: I wish we had a community place (or do we?) to contribute / discuss design patterns and best practices for Sails apps. The official doc is great for syntax but does not go deep enough into app architecture and examples are pretty basic. Issues in the repo are for something else. Stackoverflow is flooded with old information and people trying to quick-fix your issue. Am I alone in this? :worried:
martskins
@martskins
@ChrisWork that would be awesome
ChrisWorks
@ChrisWorks
@martskins I think so too. It should be a place of structure (some at least) but where everyone can contribute and comment. We should be able to categorize / tag, mark things as current, old, unproven, needs updating to latest version, whatever. I would like to find patterns on authentication, single sign-on, database related stuff, model structure and optimization, pub-sub patterns and more. Much of it can be links-wrappers to some of the great articles already written, but could be commented on and perhaps marked as "working for v1", "needs rework for latest version", etc. Right now I spend way too much time googling for how to do this and that. This could also include a list of sails modules that are still supported, what version they support and what alternatives exists, etc.
ChrisWorks
@ChrisWorks
@martskins @mikermcneil I like this channel, but things gets lost here and you are at the mercy of whoever is awake at the time of your question and follow up debate is almost impossible. Do you have any ideas on how we could achieve something like that? We would need both the sails community and the core sails team support and "stamp of approval"
Eden Corbin
@edencorbin
Somebody posted here a few weeks back about a sails community site, not sure how big/used it is, it had a few howto articles.
martskins
@martskins
I believe it was a facebook group/page
http://sailsit.com <-- that one
Eden Corbin
@edencorbin
is that a facebook page? I would have guessed wordpress, but I'm not familiar with facebook page customization. I don't much like that you have to scroll through post style entries, a contents/directory, or better way to search articles would be critical.