v4.0.0

Boot

• actionHero will now manage the starting/stopping of your applicaiton for you
• this means that there is no more 'main' or 'app.js' file for your projects
• you can still include and start an actionHero server programatically, and actionHero is now a prototypical object

actionHero Binary

• refactor of scripts into a general actionHero executable which can be found in ./node_modules/actionHero/bin/actionHero and ./node_modules/.bin/actionHero after npm install actionHero
• allows you to start your server with actionHero start and actionHero startCluster from your project's root
• actionHero start can be passed many options, including --config=[file] which will allow you to specify other config.json(s) (IE: for development/staging envrionments)
• you can learn more about the new CLI with actionHero help

core API

• (breaking) actionHero itself is now a prototypical object to facilitate multiple servers in one app (testing)
• if an external IP cannot be determined, 'actionHero' will be the api.id base name
• actionHero will now set pidFiles for each server, and attempt to delete them on shutdown
• (breaking) params.initFunction no longer exists. Please use a propper initializer instead
• better creation of pid files for running servers

clients

• a better client example for the browser (ajax/jsonp)
• moved websocket client to it's own includable js file (for browsers). look for it in examples/clients/web/actionHeroWebSocket.js

Other

• ensure that the file action / public path cannot be used to server files outsite of /public
• dependency updates

v3.1.6

• bug fixes and spelling mistakes corrected

v3.1.5

• allow for api.configData.webSockets.options to contain a hash of settings to be bound to the websocket initializer (along with .settings which remains an array)
• explicit call of node in package.json to enable project to run on windows
• added a generator for initializers @ npm run-script actionHero generateInitializer
• create a template readme file when generating a new project
• enable you to add custom initializers in your project

v3.1.2

• fix a bug with web socket sequencing for responses

v3.1.1

custom matchers on api.chatRoom.socketRoomBroadcast

• api.chatRoom.socketRoomBroadcast() can now send messges to only some clients that match certain params, IE: {auth: true} or {id: 123}. This will let you segment the users in your rooms who hear you broadcasts.
• connection.params.roomMatchKey and connection.params.roomMatchVale are set by the broadcaster to determine who they wish to message, along with the room.

v3.1.0

This is likley to cause many minor, but breaking changes

Pattern Consistency

• actionHero.start, actionHero.stop, and actionHero.restart's callbacks now all callback with (error, api) rather than just (api)
• Actions now have a default error of 'null' rather than 'false' and actions will not return an error object unless there is an error. Client-side checks should now look for errors with if(error != null), which makes more sense
• api.cache.save and api.cache.destroy now return with callback(error, didSave) and callback(error, didDestroy). api.cache.load now responds with next(error, cacheObj.value, cacheObj.expireTimestamp, cacheObj.createdAt, cacheObj.readAt)
• a number of other functions have also been updated to properly follow the (err, data) pattern. Check them out in the "internal methods" wiki page
• Tasks should now callback(data, toContinue) where 'toContinue' is a boolean indicating if the task ran sucessuflly, and is able to be run again
• the extra methods for socket/webSocket connections (say, roomView, etc) have been removed from the actionsView action, as they aren't really actions
• default session ID renambed from "__browser_fingerprint" to "sessionID"
• you can now pass "x-sessionID" headers as well as cookies to continue a web session with the same ID

Tasks

• api.tasks.inspect can be used to inspect all the tasks in the queue
• api.tasks.enqueue now has a callback(err, enqueued) which can be used to check if there were any errors adding your task to the queue
• anquing a non-periodic "all" task now will be sent to all servers in the actionCluster properly

v3.0.14

Refactor of servers

• Rather than having both a HTTP and HTTPS server, you now configure both the web server and socket server if you want them to be secure (tls, https) or not (tcp, http)
• the TCP server can now be upgraded to a TLS server, similar to how the https server can be enabled
• as there is now only one http server, webSockets will be bound appropriately if enabled

Other

• changing your config.js file in development mode will now reboot the server

Bugs

• reloading of tasks in development mode crashed before... now it doesn't!
• providing both a custom config.js and params.configChanges when booting actionHero didn't work (only config.js was used). Fixed
• in development mode, causing a parser error in a task or action will no longer crash the program. The action will be ignored until you fix it.

v3.0.13

Cleanup and changing our test suite to mocha

Connections

• Version 3.0.12 introduced http(s) message queues, but this created a lot of overhead for each request. We have changed this feature to "opt-in" if you want to use it.
• api.configData.commonWeb.httpClientMessageTTL will default to null (disable http client http(s) message queues). Setting it an integer (ms) will enable it again.

Other

• routes.js will now be reloaded when in development mode as the file changes

Bugs

• Fixed a header issue with mime times on flat files
• Added a helper which will ensure no duplicate headers are sent to http clients (like mime/type) except for setting cookies
• ignore the developer mode test in node < 0.7.0

v3.0.12

Connections

• Connections have been refactored to all live within api.connections, and matain an type refering to thier connection method (web, websocket, tcp)
• web clients can now also be sent messages. Web clients can retrieve pending messages with the chat api action and the method messages. The old say action has been merged into this example action.
• all connections (including web clients) will be assigned a connection.public.id to facilitate the above. actionHero will attempt to save this id within in a cookie. Options can be set in api.configData.commmonWeb.fingerprintOptions
• http client's messages will be pruned every so often as determined by api.configData.commonWeb.httpClientMessageTTL

Strict Mode

• actionHero now conforms to strict JS mode.

Bugs

• Relaxed the necessity to provide public information to mock connections when using socketRoomBroadcast problematically.

v3.0.11

RESTful Routes

• Building off of api.utils.mapParamsFromURL, you can now define named routes to your actionHero projects to help out http and https clients
• routes remain optional
• actions defiend in params directly action=theAction or hitting the named URL for an action /api/theAction will always override RESTful routing
• the hierarchy of the routes object is prefix --> REST verb -> data
• data contains the 'action' to map to, and then an optional urlMap (api.utils.mapParamsFromURL)
• only single depth routes are supported at this time
• generating a new project will create a template routes.js, but it will contain no content

An example routes.js

  exports.routes = {

    users: {
      get: {
        action: "usersList", // (GET) /api/users
      }
    },

    user : {
      get: {
        action: "userAdd",
        urlMap: ["userID"], // (GET) /api/user/123
      },
      post: {
        action: "userEdit",
        urlMap: ["userID"] // (POST) /api/user/123
      },
      put: {
        action: "userAdd",
        urlMap: ["type", "screenName"] // (PUT) /api/user/admin/handle123
      },
      delete: {
        action: "userDelete",
        urlMap: ["userID"] // (DELETE) /api/user/123
      }
    }

  };

chat & redis

• The redis pub/sub channel used for interclient communiaction is now suffiexed by your redis DB
• This means that differenet actionHero clusters using the same redis instance will no longer intercept eachother's messages

non-breaking Exceptions (node >= v0.8.0 only)

Thanks to node.js domains, exceptions in Actions and Tasks will no longer crash the application.

• Exceptions within actions will be logged, and a new api.configData.general.serverErrorMessage will be rendered to clients within an action
  • web clients will be sent the 500 (server error) header
• Exceptions created in tasks will also be logged, and the task will return
• If the Exception occured within a periodic task, the task will be re-enqueud.
• keep in mind that any applicaton-wide settings which may have been modified in this erronious action/task will not be rolled-back

Readme and Wiki

• The readme.md was gettting really long and hard to searh, so we started a github wiki!

Other

• Documentation and Tests for XML output