Temporarily hack guide into the raw JS so it works with ApplicationCa…

…che.
wycats · Apr 18, 2010 · 60019be · 60019be
1 parent ac177ac
commit 60019be
Show file tree

Hide file tree

Showing 15 changed files with 128 additions and 8 deletions.
diff --git a/Buildfile b/Buildfile
@@ -5,5 +5,6 @@
 
 # Add initial buildfile information here
 config :all, :required => [:sproutcore, "sproutcore/animation", "sproutcore/forms"], :theme=>:pig, :url_prefix => "/static/hedwig/",
-  :html5_manifest=> true
+  :html5_manifest=> true,
+  :layout => 'lib/index.rhtml'
 
diff --git a/apps/hedwig/controllers/guides.js b/apps/hedwig/controllers/guides.js
@@ -16,7 +16,9 @@ Hedwig.guidesController = SC.ObjectController.create(
 
   currentGuide: null,
   loadGuide: function(path) {
-    SC.Request.getUrl(path).json().notify(this, "didLoadGuide").send();
+    // we are short-circuiting for now
+    this.set("currentGuide", Hedwig.GUIDE_CONTENT);
+    //SC.Request.getUrl(path).json().notify(this, "didLoadGuide").send();
   },
 
   didLoadGuide: function(response) {

diff --git a/apps/hedwig/lib/index.rhtml b/apps/hedwig/lib/index.rhtml
@@ -0,0 +1,117 @@
+<% # SPROUTCORE DEFAULT INDEX TEMPLATE 
+   # This template provide provides a basic wrapper for a SproutCore client.
+   # Most of the time, it will be sufficient for your own needs.  However, if
+   # you need to create your own template, you can do so by copying this file
+   # into your client, naming it 'index.rhtml' and then adding the options
+   # :layout => 'lib/index' to your Buildfile.
+   #
+   # See the comments in this file for more information on what you can
+   # change.
+-%>
+<!DOCTYPE html>
+<html<% unless @content_for_html5_manifest.blank? %> manifest="app.manifest"<% end %>>
+  <head>
+    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
+    <meta http-equiv="X-UA-Compatible" content="IE=8" />
+    <meta http-equiv="Content-Script-Type" content="text/javascript" />
+    <meta name="apple-mobile-web-app-capable" content="yes" />
+    <meta name="apple-mobile-web-app-status-bar-style" content="black" />
+    <meta name = "viewport" content = "initial-scale = 1.0, minimum-scale=1.0, maximum-scale = 1.0, user-scalable = no" />
+	<link rel="apple-touch-icon-precomposed" href="<%= sc_static('icon-precomposed.png') %>"/>
+	<link rel="apple-touch-startup-image" href="<%= sc_static('startup.png') %>">
+
+<% # Set the 'title' in your config to alter this setting %>
+    <title><%= title %></title>
+<% #
+   # You may choose to load one or more bootstrap resources.  These are 
+   # JS targets that you would like to load at the top of the page.  Specify
+   # these in your Buildfile with the 'bootstrap' config. 
+-%>    
+  <%= bootstrap %>
+
+<% # 
+   # This line should appear in your head area to include the stylesheets
+   # generated by your client.  If you need to include your own
+   # stylesheets, you don't need to change it here.  Instead use the 
+   # required option in your config.
+-%>
+   <%= stylesheets_for_client %>
+   <%= @content_for_page_styles %>
+
+  </head>
+
+<% # The theme CSS class is added automatically based on your chosen theme.
+   # If you need to specify a custom theme name, use CONFIG.theme_name 
+-%>
+  <body class="<%= [theme_name(:default => 'sc-theme'), 'focus'].compact.join(' ') %>">  
+<% # This section is used to setup additional optional class names on the 
+   # body content based on JS-selected conditions.  Use this to make sure you
+   # show the proper CSS as soon as the page appears. 
+-%>
+<%= inline_javascript('sproutcore/bootstrap:setup_body_class_names') %>
+
+<% #
+   # This is where you root body element will appear.  To cause your 
+   # content to appear here, just declare content_for('body') in one of
+   # your partials.
+-%>
+<%= @content_for_body %>
+<% #
+   # This is where your loading screen will appear.  To add a loading screen
+   # just declare content_for('loading') in one of your partials. If you use 
+   # sc-gen to generate your app, it will create a file called loading.rhtml
+   # under english.lproj. You can insert the desired content there.
+-%>
+<% unless @content_for_loading.blank? %>
+<div id="loading">
+<%= @content_for_loading %>
+</div>
+<% end -%>
+<% # 
+   # This is where the resources you declare will appear.  By default anything
+   # you add to partials will be added to this section unless you specify
+   # otherwise.  Note that resources are initially hidden so you can pull them
+   # apart as needed on page load.
+-%>
+<% unless @content_for_resources.blank? %>
+    <!-- Resources to be removed from DOM on page load -->
+    <div id="resources" style="display:none; visibility: hidden;">
+      <%= @content_for_resources -%>
+    </div>
+<% end -%>
+<% #
+   # This line should appear at the bottom of your page to include your
+   # generated JavaScript and any libraries you reference.  If you need
+   # to include other javascripts, add them to the :requires option of
+   # your client in routes.rb instead of changing it here.
+-%>
+<%= javascripts_for_client %>
+<% unless @content_for_page_javascript.blank? %>
+<%= @content_for_page_javascript %>
+<% end -%>
+<% #
+   # If you use old-style view helpers in your page, this method must be 
+   # called to actually add the page views to your HTML.  Normally this will
+   # not generate any content.
+-%>
+<% #render_page_views -%>
+<% # Older SproutCore applications need SC.didLoad to be called after onload.
+   # This is no longer required by SproutCore so it is off by default.  To
+   # reenable set use_window_onload = true in yur config. 
+-%>
+<% if config.use_window_onload %>
+<!-- Start SproutCore on Page Load -->
+    <script type="text/javascript">window.onload = SC.didLoad;</script>
+<% end -%>
+<% # 
+   # The final content section can be used to add any last minute setup you
+   # need to do before the page ends.  This is required for loading unit 
+   # tests among other things.  
+-%>
+<%= @content_for_final -%>
+<%
+  #disable main if the application is loaded in design mode
+%>
+<%= @content_for_designer -%>
+	</body>
+</html>
diff --git a/apps/hedwig/resources/guide/touch.js b/apps/hedwig/resources/guide/touch.js
diff --git a/apps/hedwig/resources/guide/touch.json b/apps/hedwig/resources/guide/touch.json
diff --git a/apps/hedwig/resources/icon-precomposed.png b/apps/hedwig/resources/icon-precomposed.png
diff --git a/apps/hedwig/resources/icon-precomposed.psd b/apps/hedwig/resources/icon-precomposed.psd
diff --git a/apps/hedwig/resources/startup.jpg b/apps/hedwig/resources/startup.jpg
diff --git a/apps/hedwig/resources/startup.png b/apps/hedwig/resources/startup.png
diff --git a/apps/hedwig/resources/startup.psd b/apps/hedwig/resources/startup.psd
diff --git a/docs/build/articles/touch/a-brief-touch.html b/docs/build/articles/touch/a-brief-touch.html
@@ -110,6 +110,6 @@
 <li><strong>Coolness.</strong> Touch-based interfaces are cool. That is all.</li>
 </ul>
 
-<p>In this guide, we go over each of these&emdash;except for the last, which is rather vague; you'll have to figure out
+<p>In this guide, we go over each of these, except for the last, which is rather vague; you'll have to figure out
 your own meaning of "coolness".</p>
 </div><div class="footer"></div></body></html>
diff --git a/docs/build/articles/touch/a-brief-touch.json b/docs/build/articles/touch/a-brief-touch.json
@@ -1 +1 @@
-{"content":"<h1>A Brief Touch</h1>\n\n<p>It is very possible to build <em>awesome</em> touch-enabled applications in SproutCore.</p>\n\n<p>But, what makes an awesome touch-enabled application? Sure, it must accept touches,\nbut with SproutCore's (constantly growing) touch support, this is now pretty easy:\nmany existing interfaces, if built with newer SproutCore varieties, will function fine (or mostly fine),\non both larger-screened touch devices (such as iPad) and the traditional desktop environment.</p>\n\n<p>But there are many differences between desktop and touch platforms:</p>\n\n<ul>\n<li><strong>Precision.</strong> Touches are less precise than clicks. To compensate, controls should be larger.</li>\n<li><strong>Performance.</strong> Touch-based devices tend to be slow (for now). To get around this just takes \nsome elbow grease: there are many techniques to speed things up... many of which SproutCore will\nhandle for you.</li>\n<li><strong>Animation.</strong> Lack of animation looks okay on desktop (even if animation is cool)... but on\ntouch devices, non-animated interfaces look strange: touch is so much more realistic than mouse,\nbut sudden changes without transitions are not realistic at all.</li>\n<li><strong>Coolness.</strong> Touch-based interfaces are cool. That is all.</li>\n</ul>\n\n<p>In this guide, we go over each of these&emdash;except for the last, which is rather vague; you'll have to figure out\nyour own meaning of \"coolness\".</p>","errors":[],"demos":{},"articleDirectory":"articles/touch/","outputDirectory":"build/","title":"A Brief Touch","any":"metadata","goes":"Here","damn":"gruber","this":"is still eye-readable","and":"He is wrong about touch apps."}
+{"content":"<h1>A Brief Touch</h1>\n\n<p>It is very possible to build <em>awesome</em> touch-enabled applications in SproutCore.</p>\n\n<p>But, what makes an awesome touch-enabled application? Sure, it must accept touches,\nbut with SproutCore's (constantly growing) touch support, this is now pretty easy:\nmany existing interfaces, if built with newer SproutCore varieties, will function fine (or mostly fine),\non both larger-screened touch devices (such as iPad) and the traditional desktop environment.</p>\n\n<p>But there are many differences between desktop and touch platforms:</p>\n\n<ul>\n<li><strong>Precision.</strong> Touches are less precise than clicks. To compensate, controls should be larger.</li>\n<li><strong>Performance.</strong> Touch-based devices tend to be slow (for now). To get around this just takes \nsome elbow grease: there are many techniques to speed things up... many of which SproutCore will\nhandle for you.</li>\n<li><strong>Animation.</strong> Lack of animation looks okay on desktop (even if animation is cool)... but on\ntouch devices, non-animated interfaces look strange: touch is so much more realistic than mouse,\nbut sudden changes without transitions are not realistic at all.</li>\n<li><strong>Coolness.</strong> Touch-based interfaces are cool. That is all.</li>\n</ul>\n\n<p>In this guide, we go over each of these, except for the last, which is rather vague; you'll have to figure out\nyour own meaning of \"coolness\".</p>","errors":[],"demos":{},"articleDirectory":"articles/touch/","outputDirectory":"build/","title":"A Brief Touch","any":"metadata","goes":"Here","damn":"gruber","this":"is still eye-readable","and":"He is wrong about touch apps."}
diff --git a/docs/build/articles/touch/a-brief-touch.md b/docs/build/articles/touch/a-brief-touch.md
@@ -27,5 +27,5 @@ But there are many differences between desktop and touch platforms:
   but sudden changes without transitions are not realistic at all.
 - **Coolness.** Touch-based interfaces are cool. That is all.
 
-In this guide, we go over each of these—except for the last, which is rather vague; you'll have to figure out
+In this guide, we go over each of these, except for the last, which is rather vague; you'll have to figure out
 your own meaning of "coolness".
diff --git a/docs/build/guides/touch.json b/docs/build/guides/touch.json
diff --git a/docs/src/articles/touch/a-brief-touch.md b/docs/src/articles/touch/a-brief-touch.md
@@ -27,5 +27,5 @@ But there are many differences between desktop and touch platforms:
   but sudden changes without transitions are not realistic at all.
 - **Coolness.** Touch-based interfaces are cool. That is all.
 
-In this guide, we go over each of these—except for the last, which is rather vague; you'll have to figure out
+In this guide, we go over each of these, except for the last, which is rather vague; you'll have to figure out
 your own meaning of "coolness".