backlog 0.0.2 → 0.0.3

data/History.txt

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

data/LICENSE_LOCALIZATION

@@ -1,20 +0,0 @@
-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

@@ -1,180 +0,0 @@
-== 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

@@ -1,61 +0,0 @@
-== 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

@@ -1,194 +0,0 @@
-== 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