jbueza / blastmojo Goto Github PK

In Controller.Initialize() there's an issue where

if a mojo application spins up and does its dependency injection thing, the application-specific controllers get copied over to the mojo.controller namespace -- this is good but happens at the wrong time.

It should happen when the controller gets instantiated, not when the app boots up.

Suggested change to Application.configure()

Developers should have the capability to specify "*" as plugins

app.configure('plugins', '*');

This should go out and fetch plugins from a web service using JSONP.

Implementation

Write and deploy on Amazon EC2 as a node instance that can stitch together all the plugins. Upon completion of all plugins being injected, it should invoke an onComplete callback so we can observe it application or system wide.

JSONP Callback

MOJO.mount({
  plugins: [
    { name: 'jCarousel', code: '....' }
    { name: 'jqModal', code: ' .... ' }
  ]
});

Logging

> MOJO fetching all plugins ...
> Fetched: jCarousel, jqModal

Advantages

• Increase productivity
• Simplify agency-style software deployments by decreasing project structure (no need to think about what creative functionality will be needed: carousels, modal dialogs, templating)
• Guarantees plugin functionality, no divorce between versioning between jQuery and plugin.

Disadvantages

• Increase Mojo core by 1-2 KB (minified, gzipped)
• Decrease performance as we need to pull those plugins into the application asynchronously
• Will not be able to block on JSONP requests -> developer lead needs to indoctrinate the team into using pubsub
• Provides a bit too much "magic", doesn't exactly tell the developer what is going to be injected into their application unless they check console or fiddler or charles

Assumptions

• Deployments should always upgrade to the latest version of jQuery as soon as Microsoft/Google CDNs spin out those versions
• jQuery plugins (carousel, modal dialogs, templating, publish subscribe, cross-frame messaging, animation) should work in latest versions of jQuery (community driven)
• If web service is down, it should throw an error in console, as well as, fallback to including a basic set of jQuery plugins (most likely carousel, modal dialog, templating, pubsub)

To stop the madness of having two libraires that conflict with $ (MooTools/jQuery) and to reduce repetitiveness -- Here's the solution:

mojo.define("resaas.controller.LoginController", function($) {

  var LoginController = {
    events: [], methods: {}
  };

  return LoginController;
});

Description

Fix the annoying bug when trying to POST to a regular HTML file instead of a JSON web service. Right now, the Service Locator makes a massive assumption that whatever Service objects are in its registry are JSON and only accept application/json.

Solution

This needs to be handled in "contentType" parameter in the Service Map.

• Should handle all content types
• Should not assume that the service it is talking to is a JSON web service
• Should not break compatibility with current sites powered by Mojo and its Service Locator

Blast Mojo already provides implementation silos as Controllers.

Purpose

• To provide developers with the ability to write structured, robust JavaScript-heavy applications that involve complex interactions and integration
• To take a more mature approach to software engineering by indoctrinating MVC architecture
• To absorb knowledge into the community and company

Advantages

• Structural integrity
• Easier to refactor
• More abstraction, provide an easier API to follow for model-driven development

Disadvantages

• Increases barrier of entry to Blast Mojo
• Increases size of Mojo Core

Ideas & Investigation

• Use dust.js for asynchronous view components?
• Suggested API: mojo.Model.set('view.Members', {});

Provide documentation in the wiki instead. Make build file clean and lean.

Makes things easier in terms of implementation and readability.

//adding a service
ServiceLocator.addService(new Service("GetUserInfo", "mydataz.com/api/?jsonp=render", { jsonp: true });


//invoking a service
ServiceLocator.getService("GetUserInfo").invoke(params, function(err, data) {

}, this); //make scope (last parameter here) optional in mojo core

Puke. Let's make them more hawt plez.

Happens on a current project where the user has the ability to "Follow" or "Unfollow" users. The follow/unfollow controller seems to not be smart enough to know that when mapped like this:

app.map('.btn-follow', ['myapplication.user.FollowController']);

and having an events map within the controller like this:

  events: [
      ['context', '.btn-follow', 'click', 'Follow']
  ]

When we dig into the magic, it actually gets implemented like this:

 $(root).delegate(selector, eventName, function(evt) {
 
      var requestObj = new Request({}, this, evt, self);
      
      if (typeof self.before != 'undefined' && typeof self.before[commandName] != 'undefined') self.before[commandName].call(self, requestObj);
      self.methods[commandName].call(self, requestObj);
      if (typeof self.after != 'undefined' && typeof self.after[commandName] != 'undefined') self.after[commandName].call(self, requestObj);
    });

By passing in the values for "root", it would be ".btn-follow", and "selector", would also be ".btn-follow".

After talking with several developers internally, they prefer to use a common core API instead of including pubsub plugin every time.

API Example

MOJO.Messaging.publish('/app/start');

Core Topics in Mojo Core

When all plugins have loaded

MOJO.Messaging.publish("/appName/plugins/loaded");

When all controllers have been mapped

MOJO.Messaging.publish("/appName/controllers/loaded");

When application has started

MOJO.Messaging.publish("/appName/start");

Makes sense!

Current doesn't allow using jsonp as a Service in the Service Locator (brought up internally in a project).

Gross.

When a user instantiates a Service and adds it to the Service Locator

var myNewService = new mojo.Service("getUserInfo", "/api/user", { method: "post"} );

It will still do a GET even though I've passed in the method.

This should be bugged when parsing the options hash after the regex gets matched against the prefix of the service name.