Alloy widgets vs JS controllers assets/lib

I'm trying to find the best way to use multiple controllers in my alloy project so I can reuse pieces of application logic. So far I have come up with three different ways to achieve the desired result, but I'm unsure which is the best way. Hopefully someone can help give me a better idea. I will try to give you an idea of my issue. To start with, I have two files:

HTTP.js - a simple wrapper for titanium HTTPClient functionality

PlacesAPI.js - makes use of the HTTP.js functionality to communicate with my application server

These files do not have any UI directly associated with them so do not fit into the Alloy MVC model. My goal is to fit this functionality into an Alloy project. Ideally I would like to keep the functionality broken up similar to how it is in the two files to maintain maintainability and reusability. For purposes of illustration I will access the functionality from the index.js file.

Solution 1:

Put the two files in the app/lib directory:

HTTP.js:

exports.GET = function (_url, _callback) {
    var client = Ti.Network.createHTTPClient({
        onload : function() {
            return _callback(null, this.responseText);
        }
    });
    client.open('GET', _url);
    client.send();
}

PlacesAPI.js:

var http = require('./HTTP');
exports.getPlaces = function (callback) {
    var url = 'http://foo.com/places';
    http.GET(url, function(err, response) {
        callback(null, response);
    });
}

index.js:

var places = require('PlacesAPI');
places.getPlaces(function(err, response) {
    $.label.text = response;
});
$.index.open();

Solution 2:

This is the same as Solution 1 except I put the files in app/assets/components instead of app/lib. The only difference from the above code is the require statement in index.js looks like this: var places = require('components/PlacesAPI');

Solution 3:

I worked the two files into simple widgets:

app/widgets/http/controllers/widget.js: (same as HTTP.js above)

exports.GET = function (_url, _callback) {
    var client = Ti.Network.createHTTPClient({
        onload : function() {
            return _callback(null, this.responseText);
        }
    });
    client.open('GET', _url);
    client.send();
}

app/widgets/http/views/widget.xml:

<Alloy></Alloy>

Note: Even though my widget does not have any view components, I had to include the stub widget.xml file and empty widget.tss file in order for the project to successfully compile.

app/widgets/placesapi/widget.json:

...
"dependencies": {
    "http":"1.0"
}
...

app/widgets/placesapi/views/widget.xml:

<Alloy>
    <Require type="widget" src="http" id="http"/>
</Alloy>

app/widgets/placesapi/controllers/widget.js:

exports.getPlaces = function (callback) {
    var url = 'http://foo.com/places';
    $.http.GET(url, function(err, response) {
        callback(null, response);
    });
}

config.json:

...
"dependencies": {
    "placesapi":"1.0"
}
...

index.xml:

<Alloy>
    <Window class="container">
        <Require type="widget" src="placesapi" id="places"/>
        <Label id="label">Hello, World</Label>
    </Window>
</Alloy>

index.js:

$.places.getPlaces(function(err, response) {
    $.label.text = response;
});
$.index.open();

Summary

While solutions 1 and 2 both achieve the desired result, they don't seem to fit into the Alloy framework very nicely. One of the issues I see is that I would not be able to interact with other widgets from my controllers in the the first two solutions. If I started putting controllers in app/lib or app/assets it would turn into a bit of an all-or-nothing situation.

Solution 3 is the best way I could figure out to implement this type of functionality within the Alloy framework. The possible issue that I see is that widgets seem to be meant for UI functionality. I am forced to create at least a stub widget.xml file and a blank widget.tss file. This makes me ask the question, am I incurring significant overhead by using widgets to solve a simpler problem than they were meant for? Is there a better way to achieve what I want within the Alloy framework?

Tony Lukasavage answered a similar question for me on the Google Group for Alloy:

"If the code has no associated markup or tss styling, then yes, a commonjs module in app/lib would be the right choice"

https://groups.google.com/forum/?fromgroups=#!topic/appc-ti-alloy/pSlB5elTans