public
Description: Sample applications for the SproutCore JavaScript Framework
Homepage: http://www.sproutcore.com
Clone URL: git://github.com/sproutit/sproutcore-samples.git
sproutit (author)
Mon Jun 29 11:30:30 -0700 2009
commit  84e57fcb37af820249b4abfaf4acf4058d6b9572
tree    9b5aab38d34a7e13e83e391698bbf4150f75e863
parent  7fda98e2e4f651ce8296d1b326664b20e067804a
name age message
file .gitignore Mon May 11 10:37:34 -0700 2009 Add .svn to .gitignore [sproutit]
file Buildfile Loading commit data...
file HISTORY Mon Jun 30 23:38:09 -0700 2008 sc-config now proxies only /statuses urls to tw... [sproutit]
file README Thu Dec 18 12:08:21 -0800 2008 Fix broken link in readme [sproutit]
directory apps/
directory frameworks/ Sat Feb 28 18:04:22 -0800 2009 remove stale sprout_debug framework [Erich Ocean]
README
== Welcome to SproutCore Sample Applications

This is a samples application package for building a SproutCore applications.
To get started, edit your JavaScript application in the clients directory
(we've already created one for you.)

== BEFORE YOU CONTINUE

If you just cloned this samples directory using Git, you need to run the
following two commands to get the latest version of SproutCore JavaScript:

git submodule init
git submodule update

== Getting Started

To try the samples, start the SproutCore Dev Server by running from this
directory:

sc-server

This takes all the same arguments as mongrel.  You can now test any of the
following sample apps:

http://localhost:4020/contacts
http://localhost:4020/demo
http://localhost:4020/hello_world
http://localhost:4020/photos
http://localhost:4020/sample_controls
http://localhost:4020/twitter

You can also view the SproutCore docs or run the unit tests:

http://localhost:4020/sproutcore/-docs (click Rebuild Docs)
http://localhost:4020/sproutcore/-tests

== What Goes Where

Here is a brief description of the various parts of the SproutCore app:

* *clients:*  Each folder in the clients directory contains a single-page
  application you can load in your web browser.  By default the URL to reach
  each application is the /directory-name.  You will do most of your editing
  here.

* *frameworks:* Each folder in the frameworks directory is a SproutCore
  library that your client applications can use.  No HTML will be generated
  for these frameworks, but any JavaScript, CSS or other images you place
  in here will be accessible through your web browser.

* *public:* This directory contains any other static resources your other
  apps needs to be able to use.  If you have static HTML or other basic
  files you want to have access to.  If you start your server in production
  mode, cached output will also be saved into this directory.

* *lib:* Any ruby files you place in this directory will be automatically
  loaded when the sproutcore server start or when you do a static build.
  If you write any custom view helpers, you can place them here.

* *setup.yaml:* This is a config file that you can use to set various load
  options for the clients and frameworks in your app.  The default options are
  specified in the default: group.  You can override the default for specific
  frameworks or clients by naming them.

== Using Frameworks

Frameworks are automatically available in your app.  You can
also name frameworks available anywhere in your load path (including those
installed in gems).

The SproutCore gem comes with the latest versions of prototype, sproutcore,
and sproutapp frameworks installed.  All you need to do is indicate that
you require them.

== Deploying your SproutCore App

Normally you will use the sc-server to host your application while you are
developing your code.  Once you are ready to deploy, however, there are two
ways you can do it:

==== 1. Use sc-server in production.

The SproutCore server can be run in a production mode that will simply generate
and cache web-optimized versions of all of your resources upon request.  For a
low-traffic or newer site, this approach is an easy way to get your code into
production.  You just replace your directory with your latest files and the
sc-server will start serving the new resources.

==== 2. Do a static build

In general, however, loading all of your resources through a Ruby-app is not the
best, especially when you could use a high-speed server such as lighttpd that
is optimized for serving static content.

If you want real speed, do a static build of your content and serve it through
lighttpd or apache.  Do the static build, just run:

sc-build

This will place a directory in tmp/build that contains all of your resources
pre-compiled and ready for static serving.