But there’s just one problem… you have to use the embedded web server started with the
sencha app watch command. Which is fine if all you’ve got is a webpage, but if you’re dealing with web services (as so many web apps do), it’s a bit restricting – at least if you don’t want to configure your app or server to allow cross-site scripting.
But Live Update is too awesome to forego! What to do?
How Does Live Update Work?
Live Update works in two ways:
sass-compiler.js. These bring in the necessary “smarts” for the browser to compile SCSS source files into CSS in-memory.
- it also polls periodically to an update servlet running in the
sencha app watchweb server. When that server detects changes, the update servlet will provide the changed files to the browser the next time it is polled.
These services are provided off
~sass paths, so it’s highly unlikely to conflict with anything you’ve got set up in your app. Unfortunately, it’s not configurable, so if it does conflict, your only solution is either to change your app or patch the
So How Do You Solve The Problem?
But the Fashion Live Update is implemented via normal HTTP calls. So I add a
WEB-INF folder to my unpackaged front-end code, and installed a proxy servlet1 to redirect requests to
~sass over to the
sencha app watch server running on a different port. This was simple and effective.
This approach, if not the exact solution, is also applicable to other environments, such as .NET programming, or if you’re using a front-end such as Apache or nginx to serve up Ruby, PHP, or Node.
Flushed with the success of getting Live Update to work inside my app, I then went to put it into my test pages. These are standalone HTML pages that use ExtJS as a normal library, and aren’t packaged by Sencha Cmd, which bring in unit tests written in Jasmine. (The pages themselves are generated from the unit test files, using a template). Because they don’t use the generated
bootstrap.js file, they don’t bring in Fashion by themselves.
All I had to do, though, was add the imports to the page template, and then re-generate:
I then accessed the test pages via the
sencha app watch server, instead of going via Apache as I had before. With that, the test pages started to load in the SASS files, and I could do live editing of my SCSS files and see the results reflected within a couple of seconds.
(The includes are fail-safe; if they can’t be found – e.g. inside my automated test runner, or if I go via Apache instead, it just falls back to the previously generated CSS, and I get two 404 errors)
I’m still amazed at how neat this is. My biggest2 gripe, by far, with ExtJS has been with how annoying it is to work with a custom theme – the tooling support wasn’t good, it would swallow syntax errors without reporting anything, and the turnaround time was really annoying, seeing as how you need to refresh the page. (That may not sound like much, but in a web app where it can take a minute or two to get back to the state you had before refreshing, it’s a big overhead). This, however, removes a lot of that drudgery. Now all I need to do is actually become decent at using SASS and CSS to style my pages. 🙂
- I used the proxy server provided by Jason Edwards, because Tomcat doesn’t have one built-in. That’s a server-agnostic version. Some Java web servers – e.g. Jetty – have built-in proxy support – check your server’s documentation. ↩
- Alas, my second biggest complaint still applies – Sencha change the generated HTML of their widgets a lot during releases. This makes custom themes fairly fragile when upgrading. ↩