vn-toolbox-common is neither available publicly nor via the volusion-angular group. Please grant access to this project.

I believe we all agreed on a hybrid approach to sending messages. @kevinsproles agreed that at least the add to cart command should send a message. @prabinv and I have been discussing how we might want to standardize the sending of messages, not only for ourselves, but when 3rd-party components are involved. Here is what we are thinking.

We could create some kind of service that may, if one decides, stand in-between the vnApi service and whatever service is calling the API. The purpose of this service would be to establish a standard for sending messages in relation to API requests, specifically. Here's how it would work for the Cart service.

foo.beforeSend('VN_ADD_TO_CART', data);
// Prepare cart data for XHR request.
foo.send('VN_ADD_TO_CART', data);

The foo service would be the one sending specific messages in relation to different points in the XHR response. The beforeSend method would send the following message:

$rootScope.$emit('VN_ADD_TO_CART_BEFORE', data);

As you can see, it appends _BEFORE to the original message.

The send method would send 3 messages, similar to jQuery.ajax:

$rootScope.$emit('VN_ADD_TO_CART_COMPLETE', {
  status: 'success|notmodified|error|timeout|abort|parseerrror'
});

$rootScope.$emit('VN_ADD_TO_CART_SUCCESS', {
  warningMessages: [];
  infoMessages: [];
});

$rootScope.$emit('VN_ADD_TO_CART_FAIL', {
  status: 'notmodified|error|timeout|abort|parseerror',
  errorMessages: [];
  warningMessages: [];
  infoMessages: [];
});

The interfaces could be described as such:

interface ICompleted {
  status: string; // success|notmodified|error|timeout|abort|parseerror
}

interface ISucceeded extends ICompleted {
  warningMessages: string[];
  infoMessages: string[];
}

interface IFailed extends ISucceeded {
  errorMessages: string[];
}

NOTE: @prabinv says an AngularJS Interceptor might be more appropriate than a service here.

Looping in @hippee-lee @tsanko @texasag

I thought we had all agreed to submit pull requests from now on. This has not been the case. @tsanko and @hippee-lee have both broken the build by pushing commits w/o running a test locally or submitting a PR for Travis CI to run the build. This is not acceptable.

Please refer to #31 for more details on the process.

Somehow, the publishing of gh-pages on TravisCI build was broken. It might be as simple as @kevinsproles creating a new key, encrypting it and replacing the existing one in the .travis.yml file.

There shouldn't be any need to make any code changes for this to happen. The .travis.yml file should be good to go!

It might be time to rename master old-master or something and rename refactor2 to master.

@hippee-lee @tsanko @prabinv @texasag @kevinsproles

I suggest we use this angular-html5 task so we don't have to prefix ng- attributes with data- in our source code.

Thoughts? @prabinv @texasag @kevinsproles @hippee-lee @tsanko

You might find it helpful to add some bash aliases that I've accumulated over time.

Just a recap on what was said over the stand-up, with respect to process. Since we haven't been pushing directly upstream, the process is this:

First, Create a fork of method, if you haven't already.

I find it helpful to set master to track upstream, like so:

$ git remote -v
$ git remote add upstream https://github.com/volusion-angular-themes/method.git
$ co -b foo
$ gb -D master
$ co -b master --track upstream/master
$ gb -D foo
$ pull

This way, master is always set to track upstream. Since you shouldn't be working on master directly, master will always have clean pulls. I know how to set tracking directly, but I just find this method easier to remember.

Once master is set to track upstream/master, you'll want to work on a feature branch:

$ co -b fix-something

When you're done with your commits, do a blam, as seen in the aliases referred to above. This will push your local branch to your remote origin (not upstream). From here, just go to https://github.com/volusion-angular-themes/method and see that there's a new green button that says "Compare & pull request". Make sure your branch is set to be merged into upstream/master and submit the request.

Refresh the page and you'll see a little orange dot. This dot represents your TravisCI build. You can open it up in a new tab to monitor it, but when it's done, it'll give you the green merge button, if successful.

Let me know of any other process questions here.

Looping in @hippee-lee @tsanko

I'd like to spark a discussion about why or why not to store all templates in $templateCache. There are pros and cons to either approach. If the templates build up to a significant size, it could lead to an initial page-load performance hit. Clicking between pages, however, if all templates were in $templateCache, would be faster than waiting for a page request.

Thoughts? @prabinv @kevinsproles @texasag @hippee-lee @tsanko