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'.
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.
The pattern of one package defining Spacebars and another augmenting it with methods like Spacebars.parse is too confusing.
The symbols `parse`, `compile`, `TemplateTag` are now on `SpacebarsCompiler`. You can now access `SpacebarsCompiler.optimize`, and we can start exposing more symbols.
Some failing tests, which are hopefully mostly just tests of the modified code that need to be ported.
The main work was replacing the use of pseudo-attributes $special and $dynamic with the new HTML.Attrs(...) / array representation. Some functions were also rewritten to use Visitors (`toJS`, old `toHTML`/`toText`/`evaluateAttributes`, `replaceSpecials` in the compiler, but not `optimize` yet or `materialize`).
Create the "blaze-tools" package to hold toJS and other functions that are useful for template parsers/compilers that need to read or generate JS.
- Depend on ui in webapp because we use UI.component
- Use eval rather than new Function because we *do* need the local
environment (to get HTML, UI, etc)
- Log errors from running the template
These issues were not visible in normal apps because normal apps use
'ui' (implied by standard-app-packages) which makes UI a *global*. Ditto
for 'htmljs' (implied by ui) and the HTML symbol.
This breaks a strong dependency between the webapp package and the
bundler. Now we can change the standard page format, add more hooks,
etc without changing the tools (and hot code push works properly).
This is an incompatible change to the definition of the
browser-program-pre1 format: it no longer contains a "page" field
pointing to a boilerplate defined using ad hoc ##FOO##
substitution. Instead, the manifest can contain "head" and "body"
entries for data added with compileStep.appendDocument(). (Note that in
Blaze, <body> in a template file no longer calls appendDocument.)
WebApp.addHtmlAttributeHook callbacks now return attribute objects (like
those that Spacebars supports) rather than strings.
The tool no longer uses it. Simplify webapp_server to do a dumb check
for a flag instead of using optimist.
ctl-helper still uses optimist; ideally it should use our parser from
main.js instead.
Also, remove a debugging "|| true" that was causing "LISTENING" to be
output even without --keepalive.
I am not actually planning to rebuild the dev bundle just to drop
optimist.
