backlog 0.0.0

data/History.txt

@@ -0,0 +1,4 @@
+== 0.0.0 14/6/2007
+
+* First release on RubyForge
+* Now running at backlog.kubosch.no and datek.no (internal)

data/LICENSE_LOCALIZATION

@@ -0,0 +1,20 @@
+Copyright (c) 2004 Andreas Schwarz
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be included
+in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
+CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/README

@@ -0,0 +1,180 @@
+== Welcome to Rails
+
+Rails is a web-application and persistence framework that includes everything
+needed to create database-backed web-applications according to the
+Model-View-Control pattern of separation. This pattern splits the view (also
+called the presentation) into "dumb" templates that are primarily responsible
+for inserting pre-built data in between HTML tags. The model contains the
+"smart" domain objects (such as Account, Product, Person, Post) that holds all
+the business logic and knows how to persist themselves to a database. The
+controller handles the incoming requests (such as Save New Account, Update
+Product, Show Post) by manipulating the model and directing data to the view.
+
+In Rails, the model is handled by what's called an object-relational mapping
+layer entitled Active Record. This layer allows you to present the data from
+database rows as objects and embellish these data objects with business logic
+methods. You can read more about Active Record in 
+link:files/vendor/rails/activerecord/README.html.
+
+The controller and view are handled by the Action Pack, which handles both
+layers by its two parts: Action View and Action Controller. These two layers
+are bundled in a single package due to their heavy interdependence. This is
+unlike the relationship between the Active Record and Action Pack that is much
+more separate. Each of these packages can be used independently outside of
+Rails.  You can read more about Action Pack in 
+link:files/vendor/rails/actionpack/README.html.
+
+
+== Getting started
+
+1. Start the web server: <tt>ruby script/server</tt> (run with --help for options)
+2. Go to http://localhost:3000/ and get "Welcome aboard: You’re riding the Rails!"
+3. Follow the guidelines to start developing your application
+
+
+== Web servers
+
+Rails uses the built-in web server in Ruby called WEBrick by default, so you don't
+have to install or configure anything to play around. 
+
+If you have lighttpd installed, though, it'll be used instead when running script/server.
+It's considerably faster than WEBrick and suited for production use, but requires additional
+installation and currently only works well on OS X/Unix (Windows users are encouraged
+to start with WEBrick). We recommend version 1.4.11 and higher. You can download it from
+http://www.lighttpd.net.
+
+If you want something that's halfway between WEBrick and lighttpd, we heartily recommend
+Mongrel. It's a Ruby-based web server with a C-component (so it requires compilation) that
+also works very well with Windows. See more at http://mongrel.rubyforge.org/.
+
+But of course its also possible to run Rails with the premiere open source web server Apache.
+To get decent performance, though, you'll need to install FastCGI. For Apache 1.3, you want
+to use mod_fastcgi. For Apache 2.0+, you want to use mod_fcgid.
+
+See http://wiki.rubyonrails.com/rails/pages/FastCGI for more information on FastCGI.
+
+== Example for Apache conf
+
+  <VirtualHost *:80>
+    ServerName rails
+    DocumentRoot /path/application/public/
+    ErrorLog /path/application/log/server.log
+  
+    <Directory /path/application/public/>
+      Options ExecCGI FollowSymLinks
+      AllowOverride all
+      Allow from all
+      Order allow,deny
+    </Directory>
+  </VirtualHost>
+
+NOTE: Be sure that CGIs can be executed in that directory as well. So ExecCGI
+should be on and ".cgi" should respond. All requests from 127.0.0.1 go
+through CGI, so no Apache restart is necessary for changes. All other requests
+go through FCGI (or mod_ruby), which requires a restart to show changes.
+
+
+== Debugging Rails
+
+Have "tail -f" commands running on both the server.log, production.log, and
+test.log files. Rails will automatically display debugging and runtime
+information to these files. Debugging info will also be shown in the browser
+on requests from 127.0.0.1.
+
+
+== Breakpoints
+
+Breakpoint support is available through the script/breakpointer client. This
+means that you can break out of execution at any point in the code, investigate
+and change the model, AND then resume execution! Example:
+
+  class WeblogController < ActionController::Base
+    def index
+      @posts = Post.find_all
+      breakpoint "Breaking out from the list"
+    end
+  end
+  
+So the controller will accept the action, run the first line, then present you
+with a IRB prompt in the breakpointer window. Here you can do things like:
+
+Executing breakpoint "Breaking out from the list" at .../webrick_server.rb:16 in 'breakpoint'
+
+  >> @posts.inspect
+  => "[#<Post:0x14a6be8 @attributes={\"title\"=>nil, \"body\"=>nil, \"id\"=>\"1\"}>, 
+       #<Post:0x14a6620 @attributes={\"title\"=>\"Rails you know!\", \"body\"=>\"Only ten..\", \"id\"=>\"2\"}>]"
+  >> @posts.first.title = "hello from a breakpoint"
+  => "hello from a breakpoint"
+
+...and even better is that you can examine how your runtime objects actually work:
+
+  >> f = @posts.first 
+  => #<Post:0x13630c4 @attributes={"title"=>nil, "body"=>nil, "id"=>"1"}>
+  >> f.
+  Display all 152 possibilities? (y or n)
+
+Finally, when you're ready to resume execution, you press CTRL-D
+
+
+== Console
+
+You can interact with the domain model by starting the console through script/console. 
+Here you'll have all parts of the application configured, just like it is when the
+application is running. You can inspect domain models, change values, and save to the
+database. Starting the script without arguments will launch it in the development environment.
+Passing an argument will specify a different environment, like <tt>script/console production</tt>.
+
+
+== Description of contents
+
+app
+  Holds all the code that's specific to this particular application.
+
+app/controllers
+  Holds controllers that should be named like weblog_controller.rb for
+  automated URL mapping. All controllers should descend from
+  ActionController::Base.
+
+app/models
+  Holds models that should be named like post.rb.
+  Most models will descend from ActiveRecord::Base.
+  
+app/views
+  Holds the template files for the view that should be named like
+  weblog/index.rhtml for the WeblogController#index action. All views use eRuby
+  syntax. This directory can also be used to keep stylesheets, images, and so on
+  that can be symlinked to public.
+  
+app/helpers
+  Holds view helpers that should be named like weblog_helper.rb.
+
+app/apis
+  Holds API classes for web services.
+
+config
+  Configuration files for the Rails environment, the routing map, the database, and other dependencies.
+
+components
+  Self-contained mini-applications that can bundle together controllers, models, and views.
+
+db
+  Contains the database schema in schema.rb.  db/migrate contains all
+  the sequence of Migrations for your schema.
+
+lib
+  Application specific libraries. Basically, any kind of custom code that doesn't
+  belong under controllers, models, or helpers. This directory is in the load path.
+    
+public
+  The directory available for the web server. Contains subdirectories for images, stylesheets,
+  and javascripts. Also contains the dispatchers and the default HTML files.
+
+script
+  Helper scripts for automation and generation.
+
+test
+  Unit and functional tests along with fixtures.
+
+vendor
+  External libraries that the application depends on. Also includes the plugins subdirectory.
+  This directory is in the load path.

data/README_LOCALIZATION

@@ -0,0 +1,61 @@
+== Installation
+
+After generating the login system, edit your app/controllers/application.rb
+and app/helpers/application_helper.rb files. The beginning of your
+ApplicationController should look something like this:
+
+  require 'localization'
+
+  class ApplicationController < ActionController::Base
+    include Localization
+
+And your ApplicationHelper module should look like this:
+
+  module ApplicationHelper
+    include Localization
+
+Additionally, you'll need to includes this module as appropriate to use it
+elsewhere, such as in your views. You also need to add the following at the end
+of your config/environment.rb file:
+
+require 'environments/localization_environment'
+require 'localization'
+Localization::load_localized_strings
+
+Under the 'enviroments' subdirectory, you'll find localization_environment.rb.
+Edit this file as necessary...
+
+== Requirements
+
+This module requires iconv support. This is installed by default on most
+*nix distributions, but not on Windows.
+
+You need to put your translations in the files lang/[language].yaml. Then, the
+:default_language => [language] configuration variable will ensure that the
+appropriate file is loaded.
+
+== How to use it 
+
+When you want a localized string such as "localized_hello", simply create a new
+entry in all supported lannguage YAML files of the form:
+
+In en.yaml:
+
+localized_hello: hello
+
+In sp.yaml:
+
+localized_hello: hola
+
+Then in your code, you assign the string as follows:
+
+str_var = l(:localized_hello)
+
+In the environments/localization_environment file, set the
+configuration variable :default_language to either 'en' or 'sp.' That's it!
+
+== Changelog
+
+1.0.7 Fixed README to indicate dependency on iconv
+1.0.1 Fixed a few problems, including with test suite
+1.0.0 First gem release

data/README_LOGIN_SUGAR

@@ -0,0 +1,194 @@
+== About
+
+login_sugar is a modification of salted_login generator 1.1.1 that works
+out of the box on Rails 1.1.6
+
+Changes:
+  - tests all pass out of the box on Rails >= 1.1.4
+  - using ActiveRecord::Migrations for db setup
+  - put underscores in first_name and last_name user attributes
+  - replaced Mock Time extension with a Mock Clock.
+  - README_USER_LOGIN is a one stop readme
+  - contains a default configuration zip
+  - session references se symbols
+  - localization removed
+
+More about salted_login_generator at http://rubyforge.org/projects/salted-login
+
+== Prerequisite
+
+If you are on Windoze, see http://wiki.rubyonrails.com/rails/pages/iconv/
+
+== Installation
+
+If you are working with a fresh rails 1.1.6 project, you can unzip the included
+default_login_sugar_setup.zip file in your RAILS_ROOT directory. It contains
+preconfigured application controller, environment.rb, application_helper.rb and
+test_helper.rb that should work if you used User as your controller names when
+running the generator. If you do this, you can skip down to the PHASE II
+section below. BUT DON'T DO THIS IF YOU HAVE ALREADY MODIFIED YOUR RAILS APP
+as it will overwrite your existing files. Of course, you should have those
+under source control anyhow...
+
+-  PHASE I -
+
+After generating the login system, edit your app/controllers/application.rb
+file. The beginning of your ApplicationController should look something like
+this:
+
+  require 'user_system'
+
+  class ApplicationController < ActionController::Base
+    include UserSystem
+    helper :user
+    model :user
+    before_filter :authenticate_user
+
+Add the following at the end of your config/environment.rb file:
+
+  require 'environments/user_environment'
+
+Add the following line to the top of your test/test_helper.rb:
+
+  require 'user_notify'
+
+- PHASE II -
+
+Under the 'environments' subdirectory, you'll find user_environment.rb.
+Edit this file as necessary.
+
+Import the user model into the database.
+
+You'll have to create your development and test databases first and configure your
+config/database.yml appropriately. Note, if you are using mysql you will need to edit
+test/fixtures/users.yml and make the indicated change on the last fixture.
+
+You can use the provided migration script in
+db/migrate/migration_login_sugar__rename_this_to_fit_your_project.rb.
+
+This model is meant as an example and you
+can extend it, however I suggest first completing the stock installation and running
+the tests to confirm installation, then create a new migration to add your new columns.
+
+Rename db/migrate/migration_login_sugar__rename_this_to_fit_your_project.rb to
+db/migrate/###_login_sugar.rb where ### is the proper new migration level. For example,
+if this is your first migration for this rails project, use 001. If you name it something
+other than ###_login_sugar.rb then you'll need to edit the file and change the class name
+of the migration in the class definition as well.
+
+Then run:
+
+  rake migrate && rake db:test:clone
+
+Go ahead and run the unit and functional tests now:
+
+  rake
+
+These should all pass.
+
+Finally, you must properly configure ActionMailer for your mail settings. For
+example, I have the following in config/environments/development.rb (for a
+.Mac account, and without my username and password, obviously):
+
+ActionMailer::Base.server_settings = {
+  :address => "smtp.mac.com",
+  :port => 25,
+  :domain => "smtp.mac.com",
+  :user_name => "<your user name here>",
+  :password => "<your password here>",
+  :authentication => :login
+}
+
+You'll need to configure it properly so that email can be sent. One of the
+easiest ways to test your configuration is to temporarily reraise exceptions
+from the signup method (so that you get the actual mailer exception string).
+In the rescue statement, put a single "raise" statement in. Once you've
+debugged any setting problems, remove that statement to get the proper flash
+error handling back.
+
+== How to use it
+
+Now you can go around and happily add "before_filter :authenticate_user" to the
+controllers which you would like to protect. 
+
+After integrating the login system with your rails application navigate to your
+new controller's signup method. There you can create a new account. After you
+are done you should have a look at your DB. Your freshly created user
+will be there but the password will be a sha1 hashed 40 digit mess. I find
+this should be the minimum of security which every page offering login &
+password should give its customers. Now you can move to one of those 
+controllers which you protected with the before_filter :authenticate_user snippet.
+You will automatically be re-directed to your freshly created login controller
+and you are asked for a password. After entering valid account data you will be
+taken back to the controller which you requested earlier. Simple huh?
+
+== Tips & Tricks
+
+How do I...
+
+  ... access the user who is currently logged in
+
+  A: You can get the user object from the session using @session[:user]
+     Example: 
+       Welcome <%= @session[:user].name %>
+
+  ... restrict access to only a few methods? 
+  
+  A: Use before_filters build in scoping. 
+     Example: 
+       before_filter :authenticate_user, :only => [:myaccount, :changepassword]
+       before_filter :authenticate_user, :except => [:index]
+     
+  ... check if a user is logged-in in my views?
+  
+  A: @session[:user] will tell you. Here is an example helper which you can use to make this more pretty:
+     Example: 
+       def user?
+         !@session[:user].nil?
+       end
+
+  ... return a user to the page they came from before logging in?
+F
+  A: The user will be send back to the last url which called the method "store_location"
+     Example:
+       User was at /articles/show/1, wants to log in.
+       in articles_controller.rb, add store_location to the show function and
+       send the user to the login form. 
+       After he logs in he will be send back to /articles/show/1
+
+You can find more help at http://wiki.rubyonrails.com/rails/show/SaltedLoginGenerator
+
+== Troubleshooting
+
+One of the more common problems people have seen is that after verifying an
+account by following the emailed URL, they are unable to login via the
+normal login method since the verified field is not properly set in the
+user model's row in the DB.
+
+The most common cause of this problem is that the DB and session get out of
+sync. In particular, it always happens for me after recreating the DB if I
+have run the server previously. To fix the problem, remove the /tmp/ruby*
+session files (from wherever they are for your installation) while the server
+is stopped, and then restart. This usually is the cause of the problem.
+
+A forthcoming release will probably fix this via a well placed reset_session
+call (or requirement to add it after running the generator) so that it is done
+automatically on startup.
+
+== Changelog
+
+login_sugar
+0.9.4 removed scaffold references, removed localization, added generator rake task
+0.9.3 fixed Clock.now, symbolized session references
+0.9.2 fixed localization reference for sign in form (thanks Nym)
+0.9.1 fixed double first_name replacing last_name (thanks BobF)
+0.9.0 first release, modified salted_login 1.1.1
+
+salted_login
+
+1.0.9 Fixed hardcoded generator name (in controller test and schema) and README
+1.0.8 Generator/schema fixes and some README fixes/improvements
+1.0.7 Fixed bad bug with missing attr_accessor :new_password in user class
+1.0.6 Proper delete support and bug fixes
+1.0.5 Lots of fixes and changes (see rubyforge.org/salted-login)
+1.0.0 First gem release