On frameworks

###Introduction

Lately I've been receiving a lot of positive feedback when I propose that mean.io should become a framework. I'd like to define what I mean by the term "framework" so that you can check if we're on the same page.

If mean.io were a framework, I would:

1. git clone https://github.com/linnovate/mean myMean
2. cd myMean
3. npm install

if I grunt now, I'd see nothing (ok, nothing useful; in other words, a white screen, but not a white screen of death). But the server would not crash. At this point, I install all the mean packages I need.

4. mean install package1
5. mean install packageN

I also add some packages of mine. And my server works as expected. Then, after some time, I find out that mean.io repository has some (more or less) important updates. So I simply 6. git pull And now I have the latest mean.io and my server continues working.

###How to achieve this? If you like the idea proposed above, here's the story. Spoiler alert: it's not that simple. mean.io needs refactoring.

####Think framework mean.io is a two-headed beast: it contains server-side and client-side code. Server side code resides in the server directory. It is (of course) executed on the server. Client side resides in the public directory. This code needs to be sent to the browser and will be ran there.

Now, all the code provided by mean.io needs to be Object Oriented, and here's why: mean.io needs to expose all the functionality so it can be overriden.

####What cannot be overriden? #####routes On the server side, you cannot override routes. Once you make a route on the server, you establish a relationship between an incoming url and the function that will handle the route. mean.io should introduce no routes, or introduce just those routes that need not be overriden.
A typical route that mean.io should introduce is _getModules. _getModules is a function that a Web page needs to call. Server side will respond with a list of modules loaded. Client side will use the response from the server to create all the Angular modules corresponding to the names of the loaded modules. Packages need not interfere with this functionality.
Another example of a mean.io route is aggregated.

#####Controllers On the client side, you cannot override a controller. By making a controller, you establish a relationship between a name for the controller and the creation function for the controller. Once this relationship is established, the only thing a Web page can do is use the name of the controller in the markup in order to consume the controller's functionality. mean.io shouldn't introduce any controllers. But it should provide basic classes for controllers. Packages will then be free to introduce their own controllers. Packages will associate controller names to functions that will instantiate controllers from the classes provided by mean.io. If the basic class provided by mean.io does not suffice, package should be free to alter/augment the basic class, and instantiate a controller from the newly produced class.
This is where Angular factory comes into the game. mean.io should declare Angular factories to expose basic classes for all the provided functionality.

###Solution proposed So, how should mean.io look like? Let's take a look at what we have in the 0.4.x branch. #####0.4.x structure Now you have the core (in node_modules/meanio), the configuration files (in config), and the packages (in packages). The packages are the 4 basic ones (system, users, theme and articles). All of the 4 basic packages do the final job (they introduce routes and controllers; controllers are used by markup provided by these packages, so the system is closed, and can be re-used only as a boilerplate)

#####Proposed structure First of all, the articles have nothing to do with the mean.io framework, so they need to go from mean.io. articles is just a showroom.
The theme package is the most obscure to me; for a final decision on how this package should be used in the mean.io framework, a wider discussion within the community is needed.
The system package and the users package perform certain fundamental processing. That fundamental functionality needs to be moved to mean.io framework packages (I would call these framework packages the core packages). Anything that is not fundamental needs to go to external packages (for example, system_example and users_example)
Finally, mean.io should have:

1. Core in node_modules/meanio
2. Configuration in config. This directory cannot be a part of the repository, but the default files with default values should be produced in the npm's postinstall phase.
3. Core packages system_core and users_core (theme_core remains "uncharted territory" still)

For "vanilla" functionality, npm postinstall may install system_example and users_example packages - just to show how mean.io should be used. Whoever starts tinkering with mean.io will start modifying the system_example and users_example packages. All these changes will not be affected by git pull. Moreover, all the changes may easily be saved under a different package name, so that the developer easily comes up with a package of his own. Scaffolding procedures might also be made smarter so that you can roll your own package as a clone of an already existing package, but that might turn out into a big task...