search

balderdashy / sails

Realtime MVC Framework for Node.js
https://sailsjs.com
MIT License
22.86k stars 1.95k forks source link

Grouped (Modular) Directory Structure #594

Closed bgrawi closed 10 years ago

bgrawi commented 11 years ago

Hello,

I come from a php and Zend Framework 2 background and I have come to like their directory structure a lot which modularizes and groups related code together, giving it a nice collected namespace. Assets, templates, polices, etc, perhaps even images and other static content could all be under one "module". I really like this way and think that it keeps things very neatly organized.

See this example:

api
  |-Chat
    |-Controller.js
    |-OtherHelpers.js
    |-MoreHelpers.js
    |-models
      |-User.js
      |-Window.js
      |-Server.js
    |-views
      |-message.ejs
      |-window.ejs
      |-modals.ejs
      |-partials
        |-name.ejs
        |-windowstyle.ejs
    |-polices
      |-guest.js
      |-authenticated.js
    |-assets
      |-templates
        |-index.html
        |-signin.html
      |-js
        |-chat.js
      |-styles
        |-chat.css
  |-MessageBoard
    |-Controller.js
    |-OtherHelpers.js
    |-MoreHelpers.js
    |-models
      |-Post.js
      |-Forum.js
      |-Thread.js
    |-views
      |-post.ejs
      |-forum.ejs
      |-thread.ejs
      |-partials
        |-info.ejs
        |-threadList.ejs
    |-polices
      |-guest.js
      |-authenticated.js
      |-moderator.js
    |-assets
      |-templates
        |-index.html
        |-help.html
      |-js
        |-forum.js
        |-post.js
      |-styles
        |-chat.css

I could always edit some Sails.js code on my own fork and edit some of the paths, which is what I think would be necessary. Again, I come from a PHP background, but this directory structure seems the most logical to me. Please, what can I do to achieve this method of organization? Is it even possible?

mikedevita commented 11 years ago

isnt this similar to "hmvc" ? I like the idea but i've yet to see a js framework do such a thing

t73biz commented 11 years ago

IMHO, what is currently implemented for Sails, maintains a DRY principle. I'm a huge fan of DRY (Don't Repeat Yourself) and hope that the structure remains as it is. VOTE +1 to stay as it is.

Thanks, Ron Chaplin =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Tenacious, Experienced PHP Developer

On Tue, Jul 16, 2013 at 6:26 AM, Mike DeVita notifications@github.comwrote:

isnt this similar to "hmvc" ? I like the idea but i've yet to see a js framework do such a thing

— Reply to this email directly or view it on GitHubhttps://github.com/balderdashy/sails/issues/594#issuecomment-21041475 .

bgrawi commented 11 years ago

@mikedevita Essentially, yes, and I still cannot believe no one in the js community has thought of this organization. I used to use MVC until I started using zf2 and fell in love with the architecture.

@t73net I swear by DRY code, don't get me wrong. If anything, this enforces that principle even more. By modularizing, you are essentially creating mini-reusable packages within your project. You not only gain the benefit of namespaces, but directories are much less cluttered and you can always find files much easier. It forces abstraction more-so than current MVC, which makes it much more DRY. The whole idea is that you keep everything related to a controller within the controller's namespace allowing a much nicer file structure and allowing way more abstraction to be done.

For instance, if I wanted an object that could perform authentications on users, in the Users module I could create a helper authentication.js and could require it through "/Users/authentication.js". Helper objects now become much more feasible instead of jamming up the global namespace with utility objects. This makes code MUCH more DRY in my opinion. I have always been a follower of "Skinny Controllers and Fat Models" which enforces abstraction to its fullest extent. Unfortunately, the current MVC file structure does not easily or cleanly allow for this.

Thanks

t73biz commented 11 years ago

@diger44 Thanks for the response. I was looking at your example you had supplied, and had seen several files and folders named the same , even though their namespace is different. I guess this is what I was looking at when making reference to it not being DRY.

Thanks, Ron Chaplin =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Tenacious, Experienced PHP Developer

On Tue, Jul 16, 2013 at 6:45 AM, diger44 notifications@github.com wrote:

@mikedevita https://github.com/mikedevita Essentially, yes, and I still cannot believe no one in the js community has thought of this organization. I used to use MVC until I started using zf2 and fell in love with the architecture.

@t73net https://github.com/t73net I swear by DRY code, don't get me wrong. If anything, this enforces that principle even more. By modularizing, you are essentially creating mini-reusable packages within your project. You not only gain the benefit of namespaces, but directories are much less cluttered and you can always find files much easier. It forces abstraction more-so than current MVC, which makes it much more DRY. The whole idea is that you keep everything related to a controller within the controller's namespace allowing a much nicer file structure and allowing way more abstraction to be done.

For instance, if I wanted an object that could perform authentications on users, in the Users module I could create a helper authentication.js and could require it through "/Users/authentication.js". Helper objects now become much more feasible instead of jamming up the global namespace with utility objects. This makes code MUCH more DRY in my opinion. I have always been a follower of "Skinny Controllers and Fat Models" which enforces abstraction to its fullest extent. Unfortunately, the current MVC file structure does not easily or cleanly allow for this.

Thanks

— Reply to this email directly or view it on GitHubhttps://github.com/balderdashy/sails/issues/594#issuecomment-21042671 .

bgrawi commented 11 years ago

@t73net That's basically the point of an hierarchical-MVC (modularized) folder structure, you keep the same folder names in order to maintain hierarchy within the module, but this is not a hindrance and it is not reptititve, it is just a nice way (IMO) to organize what your files do simply by their location, keeping everything clutter-free. It becomes MUCH easier to use a module's dependencies var Users = require('api/Users'); for example.

dubcanada commented 11 years ago

The main reason why PHP is laid out that way is namespaces, and the fact that PSR-0 requires it to be done that way for autoloading to work.

The problem with doing said layout in JS, is just that... Namespaces do not exist.

bgrawi commented 11 years ago

@dubcanada I know PSR-0 requires it to be that way, but I have grown to really like the organization on my PHP projects. I am trying to transition to Node.js, but the way all js frameworks are laid out seems really messy compared to what I am used to.

Namespaces might not exist in JS, but module.exports is the next best thing, grouping directories into single variables is what we have to deal with; and I am ok with that.

I agree that the boilerplate is strict, but I honestly don't see a huge problem in changing where sails looks for controllers and models and such.

xdissent commented 11 years ago

I could be missing something, but the only thing you'd break by moving things out of the current structure is the auto loader. And like you mentioned, you're free to organize things however you'd like if you're willing to use require. You may have to wrap your standard sails models etc in a touch of boilerplate, but you've already chosen a trade off of hierarchy over DRY, so whatever, right?

xdissent commented 11 years ago

It looks like you might be able to trick the 0.9 module loader into doing this automatically via your configuration. I think you could set all of the config paths (controllers, services, models) to the same top-level folder and alter the filter or pathFilter to pick out the appropriate files within your different "modules". The federated option for the module loader may also do the trick.

bgrawi commented 11 years ago

@xdissent Thanks! I'll look into what you have suggested.

Does anyone know when 0.9 will be released? I see it is in its release candidate phase, but the build is failing, when should we see a final release?

mikedevita commented 11 years ago

Don't quote me as I'm not a core contrib but I heard this week

On Tuesday, July 16, 2013, diger44 wrote:

@xdissent https://github.com/xdissent Thanks! I'll look into what you have suggested.

Does anyone know when 0.9 will be released? I see it is in its release candidate phase, but the build is failing, when should we see a final release?

— Reply to this email directly or view it on GitHubhttps://github.com/balderdashy/sails/issues/594#issuecomment-21093399 .

xdissent commented 11 years ago

According to #596 today may be the day.

mikermcneil commented 11 years ago

re federated loader-- haven't documented that one because we haven't thoroughly tested it internally, but that is an advanced option you can look at. Basically it just lets you use separate files for each controller action, nothing fancy.

@xdissent is right-- you can use sails.config.paths to set the source dir for each type of module. I haven't tried the approach you're suggesting w/ Sails yet myself, but it's a reasonable use case. Might make sense to add the ability to specify a list of paths for each type of module instead of just one.

re 0.9: should be tomorrow (err.. this?) morning?! I hope. Ready now IMO, minus rehashing i18n and more docs. We've used it on a few client projects now, and I've gone through and built a couple of sample apps on it this week, and it's feeling really solid.

Biggest thing is docs. The team and I have been burning the candle at both ends for the last couple of weeks, and we can use all the help we can get! Any help you guys can spare today getting v0.9 docs sexy is 1000% appreciated, seriously. (especially around checking out the Migration Guide)

Here are the docs we have so far:

Note: they're on the 0.9 branch (please feel free to send a pull request if you see anything to add, or any issues) http://github.com/balderdashy/sails-wiki/tree/0.9

To install v0.9 RC, you've got to link a lot of things, unfortunately! This all gets better as soon as we release, but for now it's an unfortunate consequence of maintaining a decoupled architecture:

Now you should be able to use sails globally!

Thanks guys-- talk to you soon

xdissent commented 11 years ago

Also, use npm install --production; sudo npm link --production for sails-disk, since the dev dependencies ask for waterline, which won't be available/linked yet.

mikedevita commented 11 years ago

this is what i did... for others who just want to copy/paste.. It uses @mikermcneil and @xdissent instructions just combines them together.

## Run this as one comand, if you dont want to use ~/web/frameworks, change that.
mkdir ~/web/Frameworks; cd $_; git clone git://github.com/balderdashy/waterline-criteria; git clone git://github.com/balderdashy/sails-disk; git clone git://github.com/balderdashy/anchor; git clone git://github.com/balderdashy/anchor; git clone git://github.com/balderdashy/waterline; git clone git://github.com/balderdashy/sails -b development sails; 

## Run each of these line by line.
cd waterline-criteria; npm install; npm link; cd ../;
cd sails-disk; npm link waterline-criteria; npm install --production; sudo npm link --production; cd ../;
cd anchor; npm install; npm link; cd ../;
cd waterline; npm link anchor; npm install; npm link; cd ../;
cd sails; npm link sails-disk; npm link waterline; npm install; npm link;
bgrawi commented 11 years ago

I don't need 0.9.x immediately, it looks like it is just in the process of getting updated on github. The npm module states 0.9.2 is the current version but is still listed as "edge" and development, so I'm not really sure what to do here. I'd rather not have to go through all the trouble of installing the RC if its literally about to be relased and all compiled together so I can just npm update sails hopefully. I have not started any serious projects yet, so I may just start fresh and try to work out my desired directory structure.

mikedevita commented 11 years ago

0.9.2 is on npmjs right now. They just havent merged the master branch yet. I have a full build from npm thats working and its at 0.9.2

DrSparkles commented 11 years ago

Hey Folks! I realize this issue is near closed out, yet I have a related question. If it's already been addressed - I apologize - I've looked through everything yet might have missed it. If you'd like me to move it to it's own issue (assuming it's not already addressed), I'm happy to.

I'd like to make sub-folders of controllers and models, but not for separate modules. Rather, I'd like to have them for logical separation of related functionality inside the controller and models folders themselves. Here's an example / use-case:

In a decently sized analytics site, I may have many behaviors related around events, many around user sessions, many around account activity, etc. Each behavior has it's own DB table, and thus it's own controller and model file to go with it. Inside the controllers folder, I would like to have an events folder, and put all event-related controllers in there; in the models folder, I'd put all the event-related model files. With me? This allows me to have all models with other models and controllers with all the other controllers, but still have some organization when the number of files gets large.

So - this kind of relates to the original posters question in that it has to do with sub-folders and alternate site organization...

I've tried simply applying this structure, but find that I get some lovely errors: 1) explicitly putting things into config/routes.js with the sub-folders fails, 2) trying call normal get / put / post / delete functionality of sub-foldered files results in a 404, etc.

I've tracked down where controllers are auto-loaded in the actual sails files - and see at least some of how the framework is trying to load things. I poked around, and tried to see if I could finangle it to load sub-folders, but met with some failure... before I totally tore it apart, I figured I should just ask. I'm uncertain if there is something I'm just missing due to lack of documentation or something.

A nudge in the right direction would be grand! As I said, I'm happy to open a new issue if this is totally unrelated, or just go where lead if this issue is resolved / already part of the framework :)

Thanks gang!

anatolly commented 11 years ago

+1 Out team have started a serious project and number of files is getting large. This feature is quite helpful.

CWyrtzen commented 10 years ago

We're closing this to keep things tidy around here. It has been tracked as a feature request. Thank for sharing your ideas and feedback.