Cordova projects often have a different set of files than web targets,
so we would like to be able to target different client architectures in
our bundles. Ideally, we allow the user to use arbitrary client
architectures - but this patch is a step in the right direction by
abstracting out more of the hard coded "browser"/"os" lines.
We accomplish this separation in a backwards compatible way by allowing
api.___ commands to target a "client" architecture. For example,
api.addFiles('a.js', 'client') adds 'a.js' to both the 'client.browser'
and 'client.cordova' targets.
Effects on 0.9 packaging stuff: packages don't have to change, but the
"data.json" file in ".meteor0" has "browser" in some places. We think we
have to fix the troposphere code where this data.json is created.
Some plugins will also be backwards-incompatible with this change, since
many have a "clientArch.matches("browser")" line in the plugin
code. Ideally, we fix plugins so that this stops being an issue, but for
now package authors can just patch that line.
At the compiled (unipackage) level the new names are 'web.browser' and
'web.cordova', replacing 'browser'. In package.js, the new names are
'client.browser' and 'client.cordova', serving as an adjunct to 'client'.
For several client programs 'client.browser', 'client.cordova', etc, build and
bundle manifest files and programs.
Then serve all client programs' static files on their subpaths except for the
default one served on root.
Ex.:
/app/code.js
/packages/client-package/code.js
/cordova/packages/cordova-package/code.js
This confirms that we can convert complicated templates (including #if, #each, and dynamic attributes) into HTML using Views.
Template#__lookup was moved to View#lookup, since webapp_server is an example of a case where we have lookup but no template!
Next steps: get rid of the “3” after some names, the OLDSTYLE flag, and dead code in the blaze package. Then make Template features like events, `helper`, etc. work.
Making webapp_server work requires #if and #each that work with toHTML. Don’t want to have to write that code just to be able to run client code again.
Mutating global state in tests is still not a good idea. (Specifically,
in the previous version of the test, changing the value of
`WebAppInternals.inlineScriptsAllowed()` could mess with other
client-side tests that depend on it being one way or another -- of which
there are currently probably none, but there could be in theory.)
Instead, export the exact things we want to test (boilerplate HTML
generation and the static file handler). Now we are still mutating the
global `inlineScriptsAllowed()` state, but we don't yield before setting
it back to what it was.
Also simplify the reload-safetybelt test: instead of sending an HTTP
request, just check that the script gets adding to
`WebAppInternals.additionalStaticJs`.
Now webapp doesn't need to know anything about the reload safetybelt; it
just exposes a generic interface that any package can use to include
additional static JS (inlined when possible) in the boilerplate
HTML. reload-safetybelt uses this interface, instead of webapp
weak-depending on reload-safetybelt.
Some tests were actually passing because they used old code! Not anymore.
Create Blaze.toHTML(func) and Blaze.toText(func), like Blaze.render. Generally you should always build the HTMLjs from inside the func — and our tests should always be wrapping test content in a function literal, not passing around unrendered HTMLjs trees — but if you’re just using tags and Isolate, it doesn’t matter.
