Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Added package.json for npm #1

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants
Contributor

maritz commented Oct 5, 2010

Hey,

I added this basic package.json for you so adding to npm is a step closer.

What are you thinking about changing the use of globals in the example to adding a registry to ni? I'd do it if you'd give it an okay.

Hope it helps,
Moritz Peters

Owner

chetan51 commented Oct 5, 2010

Hey,

Thanks so much! I'll add more information to the package.json and publish it to npm.

Sure, go ahead and do it, and I'll try it out and make it mainstream if that approach is better.

How did you like Ni by the way? Do you have any further suggestions on improving it? I'm glad you decided to contribute :)

Thank you,
Chetan

Contributor

maritz commented Oct 5, 2010

I like it and will probably use it in my next big project with maybe some changes.

For example I'll need some custom home routes. Meaning: example.com/logout will route to example.com/user/logout by defining it somewhere as a special route by something like Ni.addRoute('logout', 'user/logout');

Owner

chetan51 commented Oct 5, 2010

That's a good idea, I'll work on implementing that soon.

I'll also wait on publishing it to npm until after you've implemented your registry idea, so that we can have a consistent method of using it before making it mainstream.

Also let me know if you come across any bugs while using / trying out Ni.

Thanks!
Chetan

Owner

chetan51 commented Oct 5, 2010

Moritz,

What did you mean by adding a registry to Ni btw? I'm just curious as to how you can replace the use of globals in the example. (I'm quite new to Node.)

Thanks,
Chetan

Contributor

maritz commented Oct 5, 2010

I'm still thinking about how much to actually do with this.

Either just a simple array in Ni that then could be accessed by Ni.reg['something'] or something more complex that ties in with the router and adds request/response as context which would enable something like:

Ni.reg('someFunction', function (argument) {
  if (argument) {
    this.result.redirect('somewhere');
  } else if (this.request.session.something) {
    // some bla
  }
});

And then in a request handler:

Ni.reg('someFunction')(true);

However I'm still not very happy with that either...

Owner

chetan51 commented Oct 5, 2010

I'm a little confused; what would the registry be used for again? The use of globals in example/app.js is so that all those modules are available to the controllers / models / etc without each of them having to re-require them. How would the Ni registry attend to this need? Unless you were talking about something else, in which case I'm sorry for the miscommunication.

Contributor

maritz commented Oct 5, 2010

Globals have several problems, amongst them scope collisions and (according to some quite knowledgeable people in #node.js) V8 garbage collection doing bad stuff with it.

Every other language I know (including browser js) tries to avoid globals for good reasons and node.js shouldn't be any different.

Owner

chetan51 commented Oct 5, 2010

Ah, I see. So what other options are there to make sure that the Ni object required in app.js is available to all the controllers / models / etc that it is including?

Is there a way for it to pass a reference to itself when it's bootstrapping all your controllers, models and stuff to all of them?

Contributor

maritz commented Oct 5, 2010

require('ni'); in the controller/model/etc where you need it should do the trick.

Owner

chetan51 commented Oct 5, 2010

But would that require('ni')ed Ni contain all the controllers, views, etc that the booted Ni would contain, or would it be a new, unbooted Ni instance?

I figured out that I can just add a reference to the booted Ni to all the controllers, models, helpers and libraries that it loads, so that each of them can access Ni with this.Ni. That way, Ni doesn't have to be global, and the controllers, models, etc don't have to re-require it for each one.

But what about the other modules that a user might want access to? Their favorite templating engine, for instance? Would they have to re-require it for every controller, model, etc that they have? Would that also be inefficient in terms of performance, since it would be loading multiple instances of the same templating engine into memory?

Contributor

maritz commented Oct 5, 2010

require is buffering meaning that if you require('ni') in a controller/model/etc it has access to the registry stuff you set in other files.

Personally I'd store the templating engine in the registry or response object. But I wouldn't put that in ni, there are other frameworks (like express) that handle this stuff.

You'd only have to re-require ni and then fetch models from that. That's the way ni does it right now though, isn't it?! No need to change model handling if you ask me. :)

Owner

chetan51 commented Oct 5, 2010

Awesome!

I've updated the code and the README to remove the use of globals and just require Ni and other modules as needed.

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment