…EADME in place to point to Apache
Before, it seemed to not give full context to what a build target is,
This build target is no longer (primarily) used, and now that there is a hosted build target, which can function without the chrome extension (i.e. standalone) this is no longer needed, and should be removed. This also cleans up some hacky (complexity inducing) code (such as the omnibar checks) that has never felt right.
This means you can inject Ripple's client UI into any (hosted) app, provided you use the CLI's `emulate` cmd, so you need to: a) Be running locally with the npm package installed. or.. b) Be running remotely with the npm package hosting your content. To emulate your app in a browser (ex: Safari), do something like this: cd ripple-repo jake && ./bin/ripple emulate --path to/your/app Then, open a web browser at the location logged to console, but with the `enableripple` query string param (as used in the Chrome Extension): Ex: http://localhost:4400/index.html?enableripple=true This will inject the client UI in the same way the Chrome Extension does. Note: Currently, Ripple will attempt to inject itself on any .html file with a `<head>` tag in it. Note: This only works (at the moment) in select browsers (ex ones that have WebSQL). Browsers like FireFox is a TODO. Note: Updated the README to talk about using the hosted version, and removed the reference to the `pkg/web` target (which is no longer needed now that you can use the `pkg/hosted` target). Authored By: Brent Lintner <firstname.lastname@example.org> Bryan Higgins <email@example.com>
Also, it is confusing (and more complex) to support both a `ripple` and a `require` method (for `lib/client` files), so the more lightweight implementation (of `require`) was renamed to (only) expose a method called `ripple`. i.e. If you are in `lib/client`, you _must_ use `ripple` (and `ripple.define). Note: Since we use parts of Cordova (and not just with the addition of this piece of code), the LICENSE file was updated to mention this.
This commit is directly related to: 2e22193 The re-factor in the above commit was considered sufficient, however when the package name in `package.json` was changed to something other than `ripple`, the require pattern broke down, and nothing would really work, without making drastic changes to how node based JS was executed and packaged up (as an npm package), as well as testing said code. In consideration of that, it seemed most practical to change things to be less (for lack of a better word) fragile. There are two main changes this commit introduces. 1. The way `require` is used has changed. For all node specific code, you require modules using relative paths (as usual, in node). This includes `lib/cli` and `lib/server`. See the HACKING file update for more details. For any code in `lib/client`, it is the same as before, except: You should use a global `ripple` method to require in a package relative to `ripple/client/..`. For example: var foo = ripple('foo'); Would translate to var foo = require('ripple/client/foo'); Ultimately, this gives absolute control on the method that "requires" modules, so when, say, you are testing the modules in a node environment, you can translate it to an absolute path that node will understand. The second change is that all core lib dirs are back in `lib`. This is because the main reason why code was moved out of `lib` was because of the way require was intended to be used across all (node/browser) environments, and now that it is not a necessity, having it in `lib` creates a more succinct top level directory structure, etc. Note: This also means the `npm link` step in `configure` is no longer needed. But, why have an inconsistent `require` paradigm across the project? Yes, indeed.. Well, the main reason is because this seemed the most practical, considering other alternatives, such as using relative paths in the large subset of (client) JS modules and packing it into a browser specific file that worked with relative paths, which is onerous (at best). And, because the code in the browser is ultimately different than other code in this project, and is sort of considered its own sub-project in many ways (i.e. perhaps it will become a separate project, but for now, this seemed best).
When the `server` component was created, a folder (`www`) was created in the directory (alongside the JS modules) for ease of implementation. It makes sense (in terms of consistency) to have those assets in the `assets` folder, just like the `client` component. Note: `assets/*` were moved into `assets/client`.
This is because we (as a company) will not need/have to deploy this project's NPM package to the npmjs.org registry, now that we are in the Apache Software Foundation incubator, which means there need not be an extra step (i.e. asking to accept a EULA).
Given it being a common convention, there is now a HACKING.md file in the root of the project (placed there for ease of discovery). There is also a reference to it near the top of the README.md file.