<commit_before>spigg.js
============
spigg.js is a simple server-side data wrapper that lets you decouple
your business logic from data persistence, to allow both code reusage and 
modularity.

spigg.js gives you **models** for data persistence and **entities** for
business logic, the cornerstones for DRY principles and modularity.


Installation
============
	
	npm install spigg


Usecase
============
You have an application that lets users signup. For each signup, you need to
apply app-specific validation rules to the user-submitted data to create a
`user` that you can persist to the database of your choice.

Mashing this together in one block is great for rapid prototyping, but problems
quickly arise when you need to unit test your code, or work with `users` as
a resource from elsewhere in your application.
If you haven't thought about separation of concerns, you quickly end up doing
integration testing instead of actual unit testing and any DRY principles
can be forgotten soon.

With *spigg* you put all your code that persist data into `models` and the
actual business logic such as data validation and filtering into `entities`. 

Imagine entities as being unaware of both the origin and destination of data.
Entities should focus on creating valid data for your application.

Models on the other hand does store your data and rely fully upon said 
entities to have dealt with validation and filtering of data. 

As long as you stick to your models for accessing and persisting data across
your application, using multiple databases and building cache-layers inside
or on top of your models should be simple.

 
Example
============
	# /entities/User.coffee
	class User extends s.Entity
	  defaults: 
	    country: "Sweden"
	    
	  isAdult: ->
	    switch @data.country
	      when "Sweden"
	        return true if @data.age >= 18
	      when "UK"
	        return true if @data.age >= 16        
	      else 
	        return false
	
	  isValid: ->
	    return false unless @data.name
	    return false unless @isAdult()
	    return true
	  
	  # Custom setter for profile
	  setProfile: (str) ->
	    str.replace(/&/g, '&amp;').replace(/>/g, '&gt;')
	    str.replace(/</g, '&lt;').replace(/"/g, '&quot;');
	    @data["profile"] = str
	  
	  module.exports = User
	  
	# /models/User.coffee
	db = require("mongo")
	class UserModel extends s.Model
   
      save: (doc, fn) ->
        db.users.save doc

	module.exports = UserModel

	# /app.js
	express =   require('express')
    user =      require("./entities/User.coffee")
	userModel = require("./models/User.coffee")
	app =       express()
	
	app.post "/users", (req, res) ->
	  user = new User req.body
	  userModel.save user if user.isValid() 
	  res.send "", 201

    app.listen(80)

<commit_msg>Minor update in documentation for last version<commit_after>spigg.js
============
spigg.js is a simple server-side data wrapper that lets you decouple
your business logic from data persistence, to allow both code reusage and 
modularity.

spigg.js gives you **models** for data persistence and **entities** for
business logic, the cornerstones for DRY principles and modularity.


Installation
============
	
	npm install spigg


Usecase
============
You have an application that lets users signup. For each signup, you need to
apply app-specific validation rules to the user-submitted data to create a
`user` that you can persist to the database of your choice.

Mashing this together in one block is great for rapid prototyping, but problems
quickly arise when you need to unit test your code, or work with `users` as
a resource from elsewhere in your application.
If you haven't thought about separation of concerns, you quickly end up doing
integration testing instead of actual unit testing and any DRY principles
can be forgotten soon.

With *spigg* you put all your code that persist data into `models` and the
actual business logic such as data validation and filtering into `entities`. 

Imagine entities as being unaware of both the origin and destination of data.
Entities should focus on creating valid data for your application.

Models on the other hand does store your data and rely fully upon said 
entities to have dealt with validation and filtering of data. 

As long as you stick to your models for accessing and persisting data across
your application, using multiple databases and building cache-layers inside
or on top of your models should be simple.

 
Example
============
	# /entities/User.coffee
	class User extends s.Entity
	  defaults: 
	    country: "Sweden"
	    
	  isAdult: ->
	    switch @data.country
	      when "Sweden"
	        return true if @data.age >= 18
	      when "UK"
	        return true if @data.age >= 16        
	      else 
	        return false
	
	  isValid: ->
	    return false unless @data.name
	    return false unless @isAdult()
	    return true
	  
	  module.exports = User
	  
	# /models/User.coffee
	db = require("mongo")
	class UserModel extends s.Model
   
      save: (doc, fn) ->
        db.users.save doc

	module.exports = UserModel

	# /app.js
	express =   require('express')
    user =      require("./entities/User.coffee")
	userModel = require("./models/User.coffee")
	app =       express()
	
	app.post "/users", (req, res) ->
	  user = new User req.body
	  userModel.save user if user.isValid() 
	  res.send "", 201

    app.listen(80)


{'fraction_non_alphanumeric': 0.08602749907097733, 'fraction_numerical': 0.0033444816053511705, 'mean_word_length': 3.2252747252747254, 'pattern_counts': {'":': 0, '<': 4, '<?xml version=': 0, '>': 17, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1100438', 'n_tokens_mistral': 1563, 'n_tokens_neox': 1435, 'n_words': 684}