dependency_injection.html

<!--
 After talking to drew, we decided that we would need more precision in creating widgets. Making so many resources private poses the problem of interchangeability. I propose we allow variables in our dependency code to determine which level of resource use when we create the widget. for example -->

<script type="text/mint-customer-something">
  {
   dependencies:{
     model:{
       Base: "$mint/src/models/model.Base.js",
       Address: "$global/src/model/model.Base.js",
       CustomerSomething: "$module/model/model.CustomerSomething.js"
     }
  }
}
</script>

<!-- thoughts? -->

structure.js

'proposed module structure

1. widgets are modules
2. widgets have resources(models/views/controllers) that are owned by the widget (other modules cant access because they are declared privately)
3. widgets can share resources when they are declared and registered via a "manager" (mint.widget,mint.model). shared resources are declared outside of the scope of the module
4. dependency management can include modules which include their resources and their resources dependencies
5. at the mint level, each store has a directory which holds widget overrides for a widget, or a widget resource.'

proposed structure:

.. src
`-- models // shared resources
`-- store_widgets
|   `-- homemint
|      `--checkout_form
|          `-- models
|             `-- model.coupon.js
|
`-checkout_form
  `--models
    `--- model.coupon.js
  `--views
    `-- view.coupon.js
  `--controllers
  `forms.js


// src/widgets/checkout_form/models/model.coupon.js
exp.CouponModel = ready.model.Base.extend({
  initialize:function(){}
});

// src/store_widgets/homemint/checkout_form/models/model.coupon.js
exp.CouponModel = CouponModel.extend({
  initialize:function(){ alert("hello world")}
});

// src/widgets/checkout_form/form.js
mint.widget.register('checkout-form',{
  dependencies:{
    model:{
      Base:"model/model.Base.js"
    }
  },
  init:function(){ this.loadDependencies();}
  ready:function(errors,data){
    var resources = populate(data);
    this.CouponModel = new resources.CouponModel();
  }
});


// js.php turns a modules directory into something like.
(function(){
  var populate = function(ready){
      var exp = {};
      exp.CouponModel = ready.model.Base.extend({ ...
      ....
      exp.CouponView = Backbone.View.extend({...
      ....

      // start store specific loading of resources
      exp.CouponModel = CouponModel.extend({ ...
      .... 

      return exp;
    }

mint.widget.register('checkout-form',{ .....
.....
  ready:function(errors,data){
    var resources = populate(this,data);

    // should alert "hello world" from mint specific overwritten resource
    this.CouponModel = new resources.CouponModel();
   
  }
.....
});

That's not to say that an instantiated module from the manager could not be registered privately in the widgets closure, btw

@8bitDesigner would likely play out very differently depending on how we implemented decorators and / or widgets on a page... I was envisioning a view file looking something like:

<script type="mint-catalog-product-breadcrumbs">
  {
    mintSpecificSettings : false  
  }
</script>

<script type="mint-xmint-util-carousel">
  { images : <?php echo $this->images ?> }
</script>

<script type="mint-catalog-product-details_portrait_layout">
  {
    titleDecorator: 
      [ 'views-util-label'
      , mint.decorator( 'text', { content: 'Buy Now!' } )
      ]
  }
</script>

// omit product blurb script here since we don't want to show it
<!--script type="mint-xmint-catalog-product-blurb"></script-->

And in xmint/util/carousel.js:

...
options: {
  decorators: {
     imageThumbDecorator :
       [ 'views-util-carousel-imageThumb',
       , mint.decorator('tag',
            { 'class' : 'blah minty-blah'
            , 'tag' : 'caption'
            }
         )
       , 'views-util-row'
       ]

}
...

Which I realize seems verbose, but also means that we can mix and match features by mint without having to modify code too much, and common views like a row or image caption could be reused. Also what we wouldn't see any more are essentially duped templates for every mint (though Jeremy probably already helped quite a bit with that).

@dstokes. i think it promotes DRY modules by making it easier to develop DRY modules. a good example of this is https://github.com/beachmint/mint-js/blob/master/src/models/model.Address.js and https://github.com/beachmint/mint-js/blob/master/src/widgets/customer/address.js. if you look at the content and directory structure of the two files, it speaks volumes to what is a natural inclination of devs.
the private vars in a file system do seem scary without the proper glue code, the inherit import/export structure alleviates the worry of the timing/scoping issues that happen with privat vars. i also believe that knowing that all you have access to is the variables in the file itself promotes a better separation of concerns. we have invested heavily in a framework that uses these separation of concerns, i think that this helps create code that utilizes the work we have done.