memorycraft wiki

<< SproutCore ドキュメント翻訳トップ

ビルドツールについて

Assembling a complete JavaScript? application can involve managing quite a few resources including JavaScript?, CSS, and HTML fragments as well as images, flash and other source files. When you add the objective of delivering a multi-lingual application, the complexity of these resources can get out of hand very quickly.

SproutCore helps to solve this problem by including a set of build tools that can take a directory of source resources, sort out all of the JavaScript?, HTML, and CSS bits, and combine and repackage them into a set of static content that can be efficiently served over the web. You can use these build tools while you develop your application to avoid having to manually add <script> or <link> tags to your HTML when you add new files. You can also use the build tools when you are ready to go to production to prepare your resources for delivery over the web.

Using the Build Tools In Development

When you develop an application for SproutCore, you will often run the sc-server tool to serve your JavaScript? application. You can then load your application by visiting a URL like http://localhost:4020/my_app_name. Whenever you request a page from this server, it will automatically search your project directory to find the relevant resource and return it. The content that you get from the server is identical to what you will get in production after you build your resources except that CSS and JavaScript? files will not be combined or minified to make it easy to debug them.

Adding New Resources in Development Mode

Every time you refresh a page in development mode, the build tools search your project to find any resources that might have been updated or changed. Whenever you add or remove a new file, just hit refresh and SproutCore should automatically find the new resources and load them. All of the resources you expect to load with a particular client or framework needs to be in the directory with that name. In general, however, you can place resources anywhere you want within that directory with the following exceptions:

All js files are loaded with the exception that js files found in the “fixtures” directory will not be included in production builds. Files in the “tests” directory are ignored. This directory should contain only unit tests which you access using the test runner (http://localhost:4020/yourappname/-tests). All resources except for .js files should go into an .lproj directory. If you have a CSS, HTML, image or other resource that should be used for all languages, place it in the english.lproj directory. If you need to create a version of the same resource that differs for another language, place a file with the same name in another lproj directory.

Mixing the Build Tools with Your Backend Server

Although loading your content directly from the SproutCore server might be an easy way to get started with SproutCore, eventually you are going to want to talk to a server with access to your database and business logic. Since web browsers will not allow you to initiate cross-domain requests, you will need to blend your SproutCore server with your regular one using a reverse proxy such as Apache.

Configuring a proxy on your development machine is pretty simply, especially if you already have Apache running. For example, let’s say you are writing a SproutCore application that will communicate with a PHP backend. Since PHP generally runs through Apache, all you need to do is setup a proxy for your SproutCore app.

Most SproutCore apps have two URLs that they care about. One URL is the URL you will actually use to get to the app. For example /myapp. The other URL is the place the app will go to find its static resources such as JavaScript? and CSS. The default configuration for SproutCore places all of these resources under /static.

With this configuration, you can blend your SproutCore build tools with your backend server by adding the following to your Apache httpd.conf file (Be sure you have also turned on mod_proxy if needed):

ProxyPass /myapp http://localhost:4020/myapp
ProxyPassReverse /myapp http://localhost:4020/myapp
ProxyPass /static http://localhost:4020/static
ProxyPassReverse /static http://localhost:4020/static

Once you have added this, just restart your Apache server and now you should be able to access your app by visiting:

http://localhost/myapp

You can also access your PHP application using whatever URLs you have set up for it.

If you are using SproutCore with a backend technology that does not normally run through Apache, such as a Ruby on Rails app, you can still use this system by adding just a few more lines to your config. After the above ProxyPass? lines, simply add:

ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/

This will route all requests Apache receives that do not begin with /myapp or /static to your Rails app. Restart your Apache once more and you should now be able to access both SproutCore and your Rails app together.

One of the big benefits of using this setup to work with your front and backend components blended together is that it will let you work with your apps as they will actually function in production with your client being served from one location and your dynamic components served from another.

Using the Build Tools In Production

When you are ready to take your app into production, you will generally create a static version of your app that can be served directly out of Apache or lighttpd. SproutCore takes this approach for production apps rather than having you install the build tools themselves for a couple of reasons:

• Static content is the fastest way to serve content on the web. By making your SproutCore app a static page, you can minimize the page load time considerably. The SproutCore JavaScript? framework has been heavily optimized around this kind of deployment scenario specifically because loading as a static app guarantees the best overall performance for your users.
• By forcing you to develop your app to load a static content, your SproutCore app can take advantage of edge caching servers and other high-volume distribution networks to give you an instant, world-wide, high performance deployment for almost no cost. If your website takes off and starts growing rapidly, you will appreciate having an architecture already set up for high performance growth. To create a static build of your apps for production, all you need to do is cd into your project directory and run:

sc-build 

This will create a static build of all of the clients and frameworks currently installed on your system. If you instead would just like to build one client (say your app), you can instead use:

sc-build myappname

This will build the clients and frameworks required by the app only.

The output for this command will be found in a directory called tmp/build. It usually is stored entirely within a static directory. When you go to production, if you want users to visit a URL other than /static/myappname to get to your app, you should create a symlink from where you want the app to be accessed to this location. For example, if you install your app at /static, then you could create a symlink from /myappname -> /static/myappname and users will now be able to load your app at /myappname.

What Gets Built

When you build a SproutCore app, the build tools go through a number of steps to generate a bundle optimized for efficient delivery over the web. The build tool will do the following steps once for each language it finds in your project. The output for each project will be stored in a directory with the two letter code for the language (e.g. en, fr, de, jp):

• Assemble static resources. SproutCore will first find all resources ending in extensions other than .css, .js, and .rhtml and place them in the language directory. It will first search the default language .lproj (usually english.proj) and then look in the current language lproj. Any resources found in the current language with the same name as a resource found in the default will replace those found in the default.
• Assemble CSS. Next, SproutCore will search your .lproj directories for any files ending in a .css extension. It will then combine the files into a single resource called stylesheet.css. It will generally proceed in alphabetical order unless you place a /* require('') */ statement in the CSS which you can use to declare load-order dependencies.
• Assemble JavaScript?. Next, SproutCore will search your client for any files ending in .js. For production builds SproutCore ignores anything in the fixtures and tests directory. It also will include js files from lproj directories, but like other resources, if you have a .js file in a .lproj with the same name as a .js in the default .lproj, it will replace the default. The files are then combined into a single file using a similar method as is used with the CSS. The files are combined in alphabetical order according to their paths unless you explicitly include a call to require() in the JS file. The build tools will notice these calls and use them to determine load order. Once combined, the JS is then run through a minifier to eliminate comments and whitespace and it is finally saved into a file called javascript.js.
• Assemble the HTML. Finally SproutCore will assemble your HTML files. It does this by finding all of your .rhtml templates and executing them. These templates may include calls to view helpers and other ruby code. The last file it executes is an index.rhtml template that must be identified in your sc-config. This template will take care of actually placing all of your generated HTML into the right places on the page, including placing JavaScript? calls at the end of the page and including other important info at the top. SproutCore comes with a default index.rhtml that should generally do everything you need, though you can always override it if you need to. The output of this assembly will be saved into a file called index.html. Once it is complete, SproutCore copies the /en/index.html file to the root of your app and the build is complete.

Note that while SproutCore does minify JS it does not obfuscate it (i.e replacing variable names like “toggleSelection” with something shorter like “_b”). There are a couple of reasons for this. First, while obfuscating does reduce the size of your file, the technique it uses is nearly identical to the one used by your web server when it GZips your content. Hence obfuscating really does not save you any space when sending over the wire. It does, however, make your code harder for you to debug when you run into bugs on production and it can lead to subtle changes in behavior for your code if you have not written everything correctly. Given that there are so few benefits to obfuscating over the major drawback, SproutCore does not support this feature out of the box.

Related Links

Changing your application build root – How to change your application root from ”/static”.

このページの原文

関連ページ

1. SproutCore644日前
2. SproutCore ドキュメント翻訳1257日前