broadway 0.0.1

data/README.textile

@@ -0,0 +1,300 @@
+h1. Broadway
+
+TODO: Tests.  I've just extracted this out of a project and now I'll write tests.
+
+"html2haml":http://html2haml.heroku.com/
+
+"JAVASCRIPT <script src=":http://github.com/HenrikJoreteg/jquery-magic-labels/raw/master/jquery.magiclabels.min.js
+
+This is the source for my blog.  I develop the themes in Sinatra, and convert them into Jekyll for posts.  I'm only doing this until _someone_ gives Jekyll some HAML support so I can use it with Github...  Or I find that it's really not that good of an investment to use Github Pages.
+
+h2. The Goal
+
+The goal of this project is to make it easy to manage 20 public software projects at once.  This way, anyone developing their thing on github can easily post new examples and documentation as they develop their project, without anything out of their ordinary workflow.
+
+h2. Sinatra, HAML, JQuery, Textile
+
+"About this Blog":http://blog.peepcode.com/tutorials/2010/about-this-blog
+
+h2. Jekyll and Sinatra
+
+I use Jekyll for the static page generation (spits out all the pages, essentially pre-compiling everything into raw HTML).  I don't use Jekyll because it uses Liquid.  Liquid might be nice for someone who doesn't want to learn programming but would like to have fun with a few variables, and reuse some code.  But for a programmer who takes pride in efficiency, clean code, and being DRY, HAML and full Ruby access is much better; it gives me freedom to _do_.  I can:
+
+# Format the HTML perfectly (using HAML with Textmate)
+# Have Ruby hooks to conditionally link in elements throughout (getting rid of YAML headers)
+# Use Ruby to dynamically process other URLs
+# Extend the application to do other things like file uploading, all the while
+# Keeping everything DRY and clean.
+
+You can use @_posts@ without any layout!  And they can be raw HTML files!
+
+h3. Notes
+
+* Any folder starting with an underscore is private in terms of browser access
+
+h2. Directory Structure
+
+<pre>
+.
+|-- _config.yml
+|-- _layouts
+|-- _posts (generated output)
+|-- _site (github's place)
+|-- _source (sinatra application for development)
+|   |-- files (blog files to-be published)
+|   |-- posts (blog files)
+|   |-- lib (sinatra helpers)
+|   `-- public (sinatra public directory)
+|-- shared (javascripts, css, media, etc.)
+|-- index.html
+|-- robots.txt (what google should ignore)
+`-- sitemap.xml (google's sitemap from jekyll)
+</pre>
+
+h2. Configuration
+
+h3. Default Configuration
+
+<pre>
+permalink: 
+	if post's name is "entry": /path/to (index.haml)
+	if post's name is "something-else": /path/to/something-else
+	those are "directory" styled permalinks
+title: Path - To - Index
+keywords: nil
+description: nil
+</pre>
+
+h4. Permalink Styles
+
+directory: /path/to/index or /path/to/title
+date: /year/month/day/title
+category: /root/child/childer/title
+
+If directories have underscores, they are subtracted from the path:
+
+/path/to/_some_way_of_organizing_my_posts/my-post.textile
+	=> /path/to/my-post
+	
+Preference:
+
+# If directory contains all of [index.haml, entry.textile], it will render index.haml
+# If directory contains all of [entry.textile], it will render entry.textile
+
+h2. The Rendering Process
+
+# Startup Sinatra
+# Generate URLs from Post metadata, or, by default, directory to index.html or index.haml.  Also collect all tags and categories in the application
+# Now we have all: urls, tags, categories.  But we haven't read all of the files into memory which can be a problem
+# Go to a URL via Sinatra, render HAML
+# Read post for that URL into memory
+# Save HAML to HTML file
+
+h2. Themes
+
+When you make a request to a url, it renders out the template from the public/themes directory, but your content goes in public/posts.  In public/posts, you can add HAML/HTML files to customize the base of the them (via 'yield'), but you don't need to.  Instead, you just create your posts and they will be given a url.  The default layout for anything in your public/posts directory is the root directory it's in.  That's because you're likely to initially structure your posts according to the theme's RESTful page structure.  But if you specify a <code>layout</code> in the header of your file, it will use that from the theme.
+
+ln -s ~/viatropos/shared/themes ~/viatropos/_source/public/shared
+
+h2. Posts
+
+There are 3 types of posts:
+
+# Blog Posts
+# Index Posts
+# Regular Posts
+
+Blog posts are dated, so they must be prefixed with a date (2010-03-11-my-blog-post.textile).  Index posts describe the default page and metadata, and they must be named "index" (index.textile).  Regular posts are posts that don't care about date (such as wiki posts or just simple pages for a portfolio site), and they are named however (my-service-page.textile).  Each post has metadata defined in a YAML header.  The metadata can be wired explicitly to a themes implementation because, eventually, we'll all come to some sort of consensus on what should and shouldn't be included in the page metadata definition.
+
+h2. View Variables
+
+Inside your view you have access to quite a lot of variables:
+
+# @metadata@: Hash of all the config variables defined for your header metadata.
+# @config@: Hash of global config values
+# @params@: Hash of values passed in through the URL
+# @site@: site object, which has these properties
+## @posts@: array of posts
+## @categories@: array of categories @{:name => post}@
+## @pages@: array of pages (TBD)
+# @post@: Post object, if applicable
+## @data@: Hash of metadata specific to this post (symbolized keys)
+## @title@: Post title
+## @url@: Relative URL to Post
+## @date@: Date post was created
+## @published@: Whether or not it's been officially published
+## @tags@
+## @categories@
+
+ALL HASH KEYS ARE SYMBOLS, NOT STRINGS!
+
+h2. Layouts
+
+There are quite a few layouts available in each project:
+
+# Overview
+# Blog
+# Post w/ column
+# Post w/o column
+# Portfolio: two column grid
+# Portfolio: three column grid
+# Testimonials
+# two column list
+# Contact
+
+h2. TODO
+
+# CycleHelper for easier haml repeaters
+
+h2. Theme Development
+
+"html2haml":http://html2haml.heroku.com/
+
+Create a folder called shared/themes/my-theme-name.  In there, create folders for html, touch, and flash.  In the html folder, you need the following
+
+<pre>
+.
+|-- index.haml # home page (layout.haml is somewhere else entirely)
+|-- about
+|-- blog
+|-- features
+|-- demos
+|-- download
+|-- support
+|-- community
+|-- shared
+|   |-- stylesheets
+|   |-- javascripts
+|   |-- images
+|   `-- partials
+|   	|-- _head.haml
+|   	`-- _header.haml
+</pre>
+
+There are two ways the posts/pages can be constructed:
+
+# They have a date prefixing their name
+# They are in an XML file
+
+Dates specify an order, so do XML files.  In the end, we have an xml file for each root directory that lists all of the posts in a tree.  Whether they were from being in the "_posts" directory or because they were in an XML file, it doesn't matter.
+
+If the content of the post doesn't need more than a few lines, you can specify it in XML (each item in XML is converted to a Post).  Saves on space.
+
+The end result is that we have 1 xml file for each category of posts, which can be imported into Flex.
+
+h2. Posts vs. Pages
+
+Posts are pages that can be mass produced, such as wiki pages, blog entries, and forum posts.  They may have these extra defined properties:
+
+# date
+# categories
+# tags
+
+However, Pages can also have categories and tags and dates, but they are not used the same way as posts.
+
+A major difference between pages and posts however is that Posts cannot be nested; Pages can be nested.
+
+h3. So how do we define the difference between Pages and Posts in Broadway?
+
+# Posts and Pages can be written with a date in their name: 2010-03-30-my-post.textile.
+# Directories determine _some_ of the categories of Posts and Pages (you can define additional ones)
+# Posts are basically subclasses of Page, which we can define in two ways:
+## Placing Posts into the __posts_ directory
+## Adding a @category@ to a Page called "post"
+# Related Posts have the same layout, while related pages may have completely different layouts
+
+So what we do is say, _all Posts are leaf items_.  If a file is called @index.textile@, however, it is considered a Page for the corresponding directory.  Thus, the following directory structure:
+
+|-- overview
+|	|-- index.textile
+|	|-- screenshots.textile
+|	|-- performance.textile
+
+...corresponds to this XML structure:
+
+<pre><code>
+<page url="/overview">
+	<post url="/overview/screenshots"/>
+	<post url="/overview/performance"/>
+</page>
+</code></pre>
+
+...which corresponds to these ruby objects
+
+<pre><code>
+page = Page.new(:url => "/overview")
+page.posts << Post.new(:url => "/overview/screenshots")
+page.posts << Post.new(:url => "/overview/performance")
+</pre></code>
+
+Posts can have dates, categories, and tags, while pages can only have categories and tags.
+
+h2. Post Properties
+
+# title
+# url
+# has_one: image
+# tooltip
+# content
+# description
+# categories (directory)
+# tags
+# slug (identifier)
+# published
+# author
+# comments
+# attachments
+
+h2. Attachment Properties
+
+id - Integer
+url - String
+slug - String
+title - String
+description - String
+caption - String
+parent - Integer
+mime_type - String
+images - Object
+
+- Go through public directory
+- look for .xml and .textile/.markdown/.html
+- Can go arbitrary levels deep
+- Pages are for each directory
+	- if no page, then it will render an error page
+	- if index.haml, it will render that
+- Posts are organized by category, which map directly to their directory
+- Posts also have tags
+- Themes can sort posts based on categories
+- There is a global list of tags and categories
+- Posts unique id is the slug
+- posts can't be nested
+- pages can't be nested, but the urls can be
+- there are config files for random variables
+- posts are stored into xml files by page (root level)
+- posts can have 1 image, plus any random content in the post
+- snippets are config items, which can be textile/markdown/html
+
+If there is an index.xml in a folder, it is appended to the child matching that url node in the root index.xml file
+- Content is either in XML, or in the index.textile file of a folder, or the name of the url dot textile.
+	- overview/index.textile
+	- overview.textile
+- The Post (textile file) or XML node can specify the layout:
+	- <item layout="guides".../>
+	- layout: guides
+	If no layout is specified, it will check for these files:
+		- path/to/post/index.haml
+		- theme/path/index.haml
+		- error
+
+h2. Defining Posts and Pages
+
+Posts can be created in two ways: XML or text
+
+h3. Posts from Text (HTML, Textile, Markdown)
+
+Post objects are built out of the path to the file
+
+h3. Posts from XML
+
+Post objects are built out of everything in the XML.  If the XML node is referencing a file outside of itself, then it falls into the first category.

data/Rakefile

@@ -0,0 +1,80 @@
+require 'rake'
+require "rake/rdoctask"
+require 'rake/gempackagetask'
+require File.join(File.expand_path(File.dirname(__FILE__)), 'lib', 'broadway', 'base')
+
+def files(path, from = __FILE__, &block)
+  Dir.glob(File.join(File.dirname(from), path)) {|file| yield file}
+end
+
+APP_ROOT = defined?(RAILS_ROOT) ? RAILS_ROOT : File.dirname(__FILE__)
+RAILS_ROOT = File.dirname(__FILE__)
+
+# http://docs.rubygems.org/read/chapter/20
+spec = Gem::Specification.new do |s|
+  s.name              = "broadway"
+  s.author            = "Lance Pollard"
+  s.version           = Broadway::VERSION
+  s.date              = "Mon Mar 22 20:12:47 -0700 2010"
+  s.summary           = "More than Syncing Rails Apps with the Google Data API"
+  s.homepage          = "http://github.com/viatropos/broadway"
+  s.email             = "lancejpollard@gmail.com"
+  s.description       = "Broadway: A New Way of Googling"
+  s.has_rdoc          = true
+  s.rubyforge_project = "broadway"
+  s.platform          = Gem::Platform::RUBY
+  s.files             = %w(README.textile Rakefile) + 
+                          Dir["{broadway,lib,spec}/**/*"] - 
+                          Dir["spec/tmp"]
+  s.extra_rdoc_files  = %w(README.textile)
+  s.require_path      = "lib"
+  s.add_dependency("nokogiri")
+  s.add_dependency("activesupport", ">= 2.3.5")
+  s.add_dependency("activerecord", ">= 2.3.5")
+end
+
+desc "Create .gemspec file (useful for github)"
+task :gemspec do
+  File.open("#{spec.name}.gemspec", "w") do |f|
+    f.puts spec.to_ruby
+  end
+end
+
+desc "Build the gem into the current directory"
+task :gem => :gemspec do
+  `gem build #{spec.name}.gemspec`
+end
+
+desc "Print a list of the files to be put into the gem"
+task :manifest => :clean do
+  File.open("Manifest", "w") do |f|
+    spec.files.each do |file|
+      f.puts file
+    end
+  end
+end
+
+Rake::GemPackageTask.new(spec) do |pkg|
+  pkg.gem_spec = spec
+end
+
+desc "Install the gem locally"
+task :install => [:package] do
+  sh %{sudo gem install pkg/broadway-#{Broadway::VERSION} --no-ri --no-rdoc}
+end
+
+desc "Generate the rdoc"
+Rake::RDocTask.new do |rdoc|
+  files = ["README.textile", "lib/**/*.rb"]
+  rdoc.rdoc_files.add(files)
+  rdoc.main = "README.textile"
+  rdoc.title = "Broadway: A New Way of Googling"
+end
+
+desc "Run the rspec"
+task :default => :spec
+
+desc "Run Broadway Benchmarks"
+task :benchmark do
+  files("spec/benchmarks/*") {|file| system("ruby #{file}") }
+end

data/lib/broadway.rb

@@ -0,0 +1,7 @@
+libdir = File.dirname(__FILE__)
+$LOAD_PATH.unshift(libdir) unless $LOAD_PATH.include?(libdir)
+
+require 'broadway/base'
+require 'broadway/main'
+
+# http://en.wikipedia.org/wiki/Lists_of_musicals

data/lib/broadway/api.rb

@@ -0,0 +1,51 @@
+module Broadway
+  module API
+    
+    def Post.to_xml(site)
+      xml = Nokogiri::XML::Builder.new { |xml| 
+        xml.send("posts", :type => "array") {
+          site.posts.each do |post|
+            xml.post {
+              xml.title post.data["title"]
+              xml.url post.url
+              xml.categories post.categories.join(",")
+              xml.date(:type => "date") {
+                xml.text post.date.to_s
+              }
+              xml.slug post.slug
+              xml.published(:type => "boolean") {
+                xml.text post.published.to_s
+              }
+              xml.tags post.tags.join(",")
+            }
+          end
+        }
+      }
+      xml.to_xml
+    end
+    
+    def Page.to_xml(site)
+      xml = Nokogiri::XML::Builder.new { |xml| 
+        xml.send("pages", :type => "array") {
+          site.pages.each do |post|
+            xml.page {
+              xml.title post.data["title"]
+              xml.url post.url
+              xml.categories post.categories.join(",")
+              xml.date(:type => "date") {
+                xml.text post.date.to_s
+              }
+              xml.slug post.slug
+              xml.published(:type => "boolean") {
+                xml.text post.published.to_s
+              }
+              xml.tags post.tags.join(",")
+            }
+          end
+        }
+      }
+      xml.to_xml
+    end
+    
+  end
+end

data/lib/broadway/asset.rb

@@ -0,0 +1,17 @@
+module Broadway
+
+  class Asset
+    attr_accessor :url, :title, :tooltip, :thumb
+    
+    def initialize(options = {})
+      options.each do |k,v|
+        self.send "#{k}=", v
+      end
+    end
+    
+    def inspect
+      "#<Broadway:Asset @url=#{self.url.inspect} @title=#{self.title.inspect}>"
+    end
+  end
+  
+end