[ALOY-150] Change the current hidden exports to be explicit just as in regular commonjs

Description

Comments

1. Tony Lukasavage 2012-07-31 I'd like to go beyond just renaming $ to exports and do some restructuring based on feedback from the google groups (Rick). Specifically, I'd like to support controller inheritance. Since we are already using Backbone and it has a very simple inheritance format for Models and Collections, I'm proposing we do the same with Alloy's controllers. backbone does this:

      var MyModel = Backbone.Model.extend({});
      var instance = new MyModel();
      

   perhaps we should follow suit:

      // make the getController return a controller definition instead of
      // an instance of a controller.
      var MyController = Alloy.getController('myController');
      
      // we could then use an extend function, just like Backbone, to allow
      // a new derivative controller to inherit from another.
      var MyDerivativeController = MyController.extend({
          customProperty: 1,
          customFunction: function() {}
      });
      
      // use new to create an instance
      var controller = new MyDerivativeController();
      
      // Or if you prefer a single assignment
      var controller = new Alloy.getController('myController').extend({
          customProperty: 1,
          customFunction: function() {}
      });
      

   for reference, the above code would look like the below code now, and would not cleanly support controller inheritance:

      var controller = Alloy.getController('myController').create({});
      

2. Russell McMahon 2012-07-31 I like it. I think Backbone's method of extending the base is good. It allows both instance and class but maybe class is not needed now. But for reference: var Model = Backbone.Model.extend(extendObj, extendClass); ... model = new Model({});
3. Rick Blalock 2012-08-01 I like this too. It's semi-close to how I code already in Ti apps. It's also similar to a lot of JS frameworks that do this as well (e.g. Mootools, JQuery). I also like the fact that I know I'm getting a new instance.
4. Tony Lukasavage 2012-08-02 The most relevant changes that removed unnecessary "magic", added the Backbone eventing and inheritance model, and provided much more extensibility to controllers: - new controller boilerplate: https://github.com/appcelerator/alloy/blob/master/Alloy/template/controller.js - new generated runtime controller template: https://github.com/appcelerator/alloy/blob/master/Alloy/template/component.js (devs won't see this) - BaseController.js: https://github.com/appcelerator/alloy/blob/master/Alloy/lib/alloy/controllers/BaseController.js (devs won't see this either) All samples in [alloy/test/apps](https://github.com/appcelerator/alloy/tree/master/test/apps) have been updated to use the new controller syntax. Check there to see it in action. Also, the [default generated index.js](https://github.com/appcelerator/alloy/blob/master/Alloy/template/default/index.js) for new projects has A LOT of inline documentation to get devs started until we have solid docs to reference. Anyone peeking in here, please let me know if they make sense, and if we need more or less description. Again, this will only be put into the default index.js controller when a new project is created. All other generated controllers will use the minimal boilerplate from the list above.
5. Tony Lukasavage 2012-08-02 Things that need to be added: - life cycle events should be optional. Controller code can be defined without preLayout() and postLayout() - Add "extends" attribute to \ tag for defining the parent controller (defaults to BaseController) - Add magic variable "arguments" to the lifecycle-less controllers
6. Russell McMahon 2012-08-02 1) Keep the preLayout and postLayout functionality as is. 2) Make "alloy new ." just return controller with postLayout(args) {...} all the comments were good but better in docs. 3) Remove $.parentController = Alloy.getController('BaseController'); from the controller generated from "alloy generate controller". For extending the controller object (controller, style and view) open another ticket. Then let's close the ticket. We can review with team during sprint Demo.
7. Tony Lukasavage 2012-08-03 OK, one more time around the bend on this one. * Flatten controller files. All code in the controller file is executed after the view hierarchy is established. ** The lone exception to this rule will be the *optional* init() function. This function will not be part of the code executed ater the view hierarchy. It is instead executed when the controller class itself is created. This function will return the base controller definition for this class. From here you can extend the base class definition, add lifecycle functions, or establish inheritance from a controller other than BaseComponent. Again, all optional.

   function init() {
          return Alloy.getController('MySuperController').extend({
              customProperty: 123,
              customFunction: function(){},
              preLayout: function(args) { 
                  // execute code before view hierarchy is established 
              }
          });
      }

   * Markup events need to be reworked as private functions will no longer be available on the module and instead are wrapped up in a function for the base controller. *
8. Tony Lukasavage 2012-08-06 OK, once more, as per instruction * All commonjs module constructs will remain hidden. $ is still used as a reference to the controller triad object. * Inheritance will be instance-based. This will no longer use the Backbone-like class-based extend() inheritance.

   function Controller() {
          Alloy.getController('BaseController').call(this); // can eventually be set by markup
          var $ = this;
      
          // the rest of the view and controller code
      }
      

   * A parent controller must be assigned in markup. We currently have no means to do so in the controller code itself. This means if you want a pure code controller as a subclass, you would still have to create an empty view file that looked like this:

   <Alloy parentController="MyParentController"/>

   * Controller code will be flattened. No special functions and/or syntax. All code in controllers ends up executed after the view hierarchy is created. * No lifecycle functions * The "arguments" variable is available in the controller, despite the fact that developers can't see the containing function. See also, "magic".
9. Tony Lukasavage 2012-08-07 Now implementing the style shown in this gist: https://gist.github.com/3248559 and the lifecycle events will look like this now: https://gist.github.com/3285234 This will be done in a new branch called *explicit_controller*. Both the current and this new method will be compared and evaluated to see which better suits the goals of Alloy.
10. Tony Lukasavage 2012-08-08 git branch "ALOY-150" created: https://github.com/appcelerator/alloy/tree/ALOY-150 Development on explicit controllers as listed in the previous comment will be done here.
11. Tony Lukasavage 2012-08-10 changes have been implemented in ALOY-150 branch of the repo. Will merge into master after the changes have been discussed.

JSON Source