ref: refs/heads/master
commit 98d602c0c74678ffb790482ccd8b493c99ab3740
Author: Josef Reidinger
Date: Fri Aug 14 15:00:06 2009 +0200
add base system plugin
---
plugins/basesystem/README | 243 ++++++++++++++++++++
plugins/basesystem/Rakefile | 10 +
.../app/controllers/basesystem_controller.rb | 23 ++
plugins/basesystem/app/models/basesystem.rb | 64 +++++
.../basesystem/app/views/basesystem/show.html.erb | 1 +
.../basesystem/app/views/basesystem/show.json.erb | 1 +
.../basesystem/app/views/basesystem/show.xml.erb | 1 +
plugins/basesystem/config/basesystemsteps.conf | 1 +
plugins/basesystem/config/rails_parent.rb | 15 ++
plugins/basesystem/config/resources/basesystem.yml | 5 +
plugins/basesystem/doc/README_FOR_APP | 2 +
.../basesystem/test/performance/browsing_test.rb | 9 +
plugins/basesystem/test/test_helper.rb | 38 +++
13 files changed, 413 insertions(+), 0 deletions(-)
diff --git a/plugins/basesystem/README b/plugins/basesystem/README
new file mode 100644
index 0000000..37ec8ea
--- /dev/null
+++ b/plugins/basesystem/README
@@ -0,0 +1,243 @@
+== Welcome to Rails
+
+Rails is a web-application framework that includes everything needed to create
+database-backed web applications according to the Model-View-Control pattern.
+
+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. At the command prompt, start a new Rails application using the <tt>rails</tt> command
+ and your application name. Ex: rails myapp
+2. Change directory into myapp and start the web server: <tt>script/server</tt> (run with --help for options)
+3. Go to http://localhost:3000/ and get "Welcome aboard: You're riding the Rails!"
+4. Follow the guidelines to start developing your application
+
+
+== Web Servers
+
+By default, Rails will try to use Mongrel if it's are installed when started with script/server, otherwise Rails will use WEBrick, the webserver that ships with Ruby. But you can also use Rails
+with a variety of other web servers.
+
+Mongrel is a Ruby-based webserver with a C component (which requires compilation) that is
+suitable for development and deployment of Rails applications. If you have Ruby Gems installed,
+getting up and running with mongrel is as easy as: <tt>gem install mongrel</tt>.
+More info at: http://mongrel.rubyforge.org
+
+Say other Ruby web servers like Thin and Ebb or regular web servers like Apache or LiteSpeed or
+Lighttpd or IIS. The Ruby web servers are run through Rack and the latter can either be setup to use
+FCGI or proxy to a pack of Mongrels/Thin/Ebb servers.
+
+== Apache .htaccess example for FCGI/CGI
+
+# General Apache options
+AddHandler fastcgi-script .fcgi
+AddHandler cgi-script .cgi
+Options +FollowSymLinks +ExecCGI
+
+# If you don't want Rails to look in certain directories,
+# use the following rewrite rules so that Apache won't rewrite certain requests
+#
+# Example:
+# RewriteCond %{REQUEST_URI} ^/notrails.*
+# RewriteRule .* - [L]
+
+# Redirect all requests not available on the filesystem to Rails
+# By default the cgi dispatcher is used which is very slow
+#
+# For better performance replace the dispatcher with the fastcgi one
+#
+# Example:
+# RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
+RewriteEngine On
+
+# If your Rails application is accessed via an Alias directive,
+# then you MUST also set the RewriteBase in this htaccess file.
+#
+# Example:
+# Alias /myrailsapp /path/to/myrailsapp/public
+# RewriteBase /myrailsapp
+
+RewriteRule ^$ index.html [QSA]
+RewriteRule ^([^.]+)$ $1.html [QSA]
+RewriteCond %{REQUEST_FILENAME} !-f
+RewriteRule ^(.*)$ dispatch.cgi [QSA,L]
+
+# In case Rails experiences terminal errors
+# Instead of displaying this message you can supply a file here which will be rendered instead
+#
+# Example:
+# ErrorDocument 500 /500.html
+
+ErrorDocument 500 "<h2>Application error</h2>Rails application failed to start properly"
+
+
+== Debugging Rails
+
+Sometimes your application goes wrong. Fortunately there are a lot of tools that
+will help you debug it and get it back on the rails.
+
+First area to check is the application log files. Have "tail -f" commands running
+on the server.log and development.log. 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.
+
+You can also log your own messages directly into the log file from your code using
+the Ruby logger class from inside your controllers. Example:
+
+ class WeblogController < ActionController::Base
+ def destroy
+ @weblog = Weblog.find(params[:id])
+ @weblog.destroy
+ logger.info("#{Time.now} Destroyed Weblog ID ##{@weblog.id}!")
+ end
+ end
+
+The result will be a message in your log file along the lines of:
+
+ Mon Oct 08 14:22:29 +1000 2007 Destroyed Weblog ID #1
+
+More information on how to use the logger is at http://www.ruby-doc.org/core/
+
+Also, Ruby documentation can be found at http://www.ruby-lang.org/ including:
+
+* The Learning Ruby (Pickaxe) Book: http://www.ruby-doc.org/docs/ProgrammingRuby/
+* Learn to Program: http://pine.fm/LearnToProgram/ (a beginners guide)
+
+These two online (and free) books will bring you up to speed on the Ruby language
+and also on programming in general.
+
+
+== Debugger
+
+Debugger support is available through the debugger command when you start your Mongrel or
+Webrick server with --debugger. This means that you can break out of execution at any point
+in the code, investigate and change the model, AND then resume execution!
+You need to install ruby-debug to run the server in debugging mode. With gems, use 'gem install ruby-debug'
+Example:
+
+ class WeblogController < ActionController::Base
+ def index
+ @posts = Post.find(:all)
+ debugger
+ end
+ end
+
+So the controller will accept the action, run the first line, then present you
+with a IRB prompt in the server window. Here you can do things like:
+
+ >> @posts.inspect
+ => "[#nil, \"body\"=>nil, \"id\"=>\"1\"}>,
+ #\"Rails you know!\", \"body\"=>\"Only ten..\", \"id\"=>\"2\"}>]"
+ >> @posts.first.title = "hello from a debugger"
+ => "hello from a debugger"
+
+...and even better is that you can examine how your runtime objects actually work:
+
+ >> f = @posts.first
+ => #nil, "body"=>nil, "id"=>"1"}>
+ >> f.
+ Display all 152 possibilities? (y or n)
+
+Finally, when you're ready to resume execution, you enter "cont"
+
+
+== Console
+
+You can interact with the domain model by starting the console through <tt>script/console</tt>.
+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>.
+
+To reload your controllers and models after launching the console run <tt>reload!</tt>
+
+== dbconsole
+
+You can go to the command line of your database directly through <tt>script/dbconsole</tt>.
+You would be connected to the database with the credentials defined in database.yml.
+Starting the script without arguments will connect you to the development database. Passing an
+argument will connect you to a different database, like <tt>script/dbconsole production</tt>.
+Currently works for mysql, postgresql and sqlite.
+
+== Description of Contents
+
+app
+ Holds all the code that's specific to this particular application.
+
+app/controllers
+ Holds controllers that should be named like weblogs_controller.rb for
+ automated URL mapping. All controllers should descend from ApplicationController
+ which itself descends 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
+ weblogs/index.html.erb for the WeblogsController#index action. All views use eRuby
+ syntax.
+
+app/views/layouts
+ Holds the template files for layouts to be used with views. This models the common
+ header/footer method of wrapping views. In your views, define a layout using the
+ <tt>layout :default</tt> and create a file named default.html.erb. Inside default.html.erb,
+ call <% yield %> to render the view using this layout.
+
+app/helpers
+ Holds view helpers that should be named like weblogs_helper.rb. These are generated
+ for you automatically when using script/generate for controllers. Helpers can be used to
+ wrap functionality for your views into methods.
+
+config
+ Configuration files for the Rails environment, the routing map, the database, and other dependencies.
+
+db
+ Contains the database schema in schema.rb. db/migrate contains all
+ the sequence of Migrations for your schema.
+
+doc
+ This directory is where your application documentation will be stored when generated
+ using <tt>rake doc:app</tt>
+
+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. This should be
+ set as the DOCUMENT_ROOT of your web server.
+
+script
+ Helper scripts for automation and generation.
+
+test
+ Unit and functional tests along with fixtures. When using the script/generate scripts, template
+ test files will be generated for you and placed in this directory.
+
+vendor
+ External libraries that the application depends on. Also includes the plugins subdirectory.
+ If the app has frozen rails, those gems also go here, under vendor/rails/.
+ This directory is in the load path.
diff --git a/plugins/basesystem/Rakefile b/plugins/basesystem/Rakefile
new file mode 100644
index 0000000..8f4c2f2
--- /dev/null
+++ b/plugins/basesystem/Rakefile
@@ -0,0 +1,10 @@
+require 'rake'
+require 'rake/testtask'
+require 'rake/rdoctask'
+require 'rake/packagetask'
+require File.join(File.dirname(__FILE__), 'config', 'rails_parent')
+require File.join(RailsParent.parent, 'config', 'boot')
+require 'tasks/rails'
+
+desc 'Default: run unit tests.'
+task :default => :test
diff --git a/plugins/basesystem/app/controllers/basesystem_controller.rb b/plugins/basesystem/app/controllers/basesystem_controller.rb
new file mode 100644
index 0000000..7e81f88
--- /dev/null
+++ b/plugins/basesystem/app/controllers/basesystem_controller.rb
@@ -0,0 +1,23 @@
+# = Base system controller
+# Provides access to language settings for authentificated users.
+# Main goal is checking permissions.
+class LanguageController < ApplicationController
+
+ before_filter :login_required
+
+ def show
+ @basesystem = Basesystem.find
+ end
+
+ def update
+ @basesystem = Basesystem.find
+ @basesystem.current = params[:basesystem][:current]
+ @basesystem.save
+ render :index
+ end
+
+ def create
+ update
+ end
+
+end
diff --git a/plugins/basesystem/app/models/basesystem.rb b/plugins/basesystem/app/models/basesystem.rb
new file mode 100644
index 0000000..ddcf9fc
--- /dev/null
+++ b/plugins/basesystem/app/models/basesystem.rb
@@ -0,0 +1,64 @@
+# = Base system model
+class Basesystem
+
+ # steps needed by base system
+ attr_accessor :steps
+ # current step to finish
+ attr_accessor :current
+
+ STEPS_FILE = File.join(File.dirname(__FILE__),"..","..","config","basesystemsteps.conf")
+ CURRENT_STEP_FILE = File.join(File.dirname(__FILE__),"..","..","var","currentstep")
+ END_STRING = "FINISH"
+
+ def initialize
+ @steps = Array.new
+ #load steps configuration
+ fh = File.new(STEPS_FILE, "r")
+ while (line = fh.gets)
+ steps.push(line.chomp)
+ end
+ fh.close
+ end
+
+ def Basesystem.find
+ ret = Basesystem.new
+ unless File.exist?(CURRENT_STEP_FILE)
+ ret.current = ret.steps.empty? ? END_STRING : ret.steps[0]
+ else
+ fh = File.new(CURRENT_STEP_FILE,"r")
+ ret.current = fh.gets
+ fh.close
+ if ret.steps.include(ret.current) #invalid step
+ Rails.logger.warn "invalid step in current"
+ ret.current = END_STRING
+ end
+ end
+ Rails.logger.info "Current step is set to #{ret.current}"
+ return ret
+ end
+
+ def save
+ #check if current is valid
+ unless @steps.include?(@current) or @current == END_STRING
+ #invalid current value
+ return false
+ end
+ cur = File.new(CURRENT_STEP_FILE, "w")
+ cur.puts @current
+ cur.close
+ end
+
+ def to_xml( options = {} )
+ xml = options[:builder] ||= Builder::XmlMarkup.new(options)
+ xml.instruct! unless options[:skip_instruct]
+
+ xml.basesystem do
+ xml.tag!(:current, @current)
+ end
+ end
+
+ def to_json( options = {} )
+ hash = Hash.from_xml(to_xml())
+ return hash.to_json
+ end
+end
diff --git a/plugins/basesystem/app/views/basesystem/show.html.erb b/plugins/basesystem/app/views/basesystem/show.html.erb
new file mode 100644
index 0000000..c52b4ed
--- /dev/null
+++ b/plugins/basesystem/app/views/basesystem/show.html.erb
@@ -0,0 +1 @@
+<%= @basesystem.to_xml -%>
\ No newline at end of file
diff --git a/plugins/basesystem/app/views/basesystem/show.json.erb b/plugins/basesystem/app/views/basesystem/show.json.erb
new file mode 100644
index 0000000..9cfa538
--- /dev/null
+++ b/plugins/basesystem/app/views/basesystem/show.json.erb
@@ -0,0 +1 @@
+<%= @basesystem.to_json -%>
\ No newline at end of file
diff --git a/plugins/basesystem/app/views/basesystem/show.xml.erb b/plugins/basesystem/app/views/basesystem/show.xml.erb
new file mode 100644
index 0000000..c52b4ed
--- /dev/null
+++ b/plugins/basesystem/app/views/basesystem/show.xml.erb
@@ -0,0 +1 @@
+<%= @basesystem.to_xml -%>
\ No newline at end of file
diff --git a/plugins/basesystem/config/basesystemsteps.conf b/plugins/basesystem/config/basesystemsteps.conf
new file mode 100644
index 0000000..184f94b
--- /dev/null
+++ b/plugins/basesystem/config/basesystemsteps.conf
@@ -0,0 +1 @@
+systemtime
\ No newline at end of file
diff --git a/plugins/basesystem/config/rails_parent.rb b/plugins/basesystem/config/rails_parent.rb
new file mode 100644
index 0000000..b869908
--- /dev/null
+++ b/plugins/basesystem/config/rails_parent.rb
@@ -0,0 +1,15 @@
+class RailsParent
+
+ def RailsParent.parent
+ parent = ENV["RAILS_PARENT"]
+ unless parent
+ parent = File.expand_path(File.join('..','..','..', 'webservice'), File.dirname(__FILE__))
+ unless File.directory?( parent || "" )
+ $stderr.puts "Nope: #{parent}\nPlease set RAILS_PARENT environment"
+ exit 1
+ end
+ end
+ parent
+ end
+
+end
diff --git a/plugins/basesystem/config/resources/basesystem.yml b/plugins/basesystem/config/resources/basesystem.yml
new file mode 100644
index 0000000..5a1e9ff
--- /dev/null
+++ b/plugins/basesystem/config/resources/basesystem.yml
@@ -0,0 +1,5 @@
+
+interface: org.opensuse.yast.modules.basesystem
+controller: basesystem
+singular: true
+
diff --git a/plugins/basesystem/doc/README_FOR_APP b/plugins/basesystem/doc/README_FOR_APP
new file mode 100644
index 0000000..fe41f5c
--- /dev/null
+++ b/plugins/basesystem/doc/README_FOR_APP
@@ -0,0 +1,2 @@
+Use this README file to introduce your application and point to useful places in the API for learning more.
+Run "rake doc:app" to generate API documentation for your models, controllers, helpers, and libraries.
diff --git a/plugins/basesystem/test/performance/browsing_test.rb b/plugins/basesystem/test/performance/browsing_test.rb
new file mode 100644
index 0000000..4b60558
--- /dev/null
+++ b/plugins/basesystem/test/performance/browsing_test.rb
@@ -0,0 +1,9 @@
+require 'test_helper'
+require 'performance_test_help'
+
+# Profiling results for each test method are written to tmp/performance.
+class BrowsingTest < ActionController::PerformanceTest
+ def test_homepage
+ get '/'
+ end
+end
diff --git a/plugins/basesystem/test/test_helper.rb b/plugins/basesystem/test/test_helper.rb
new file mode 100644
index 0000000..b9fe251
--- /dev/null
+++ b/plugins/basesystem/test/test_helper.rb
@@ -0,0 +1,38 @@
+ENV["RAILS_ENV"] = "test"
+require File.expand_path(File.dirname(__FILE__) + "/../config/environment")
+require 'test_help'
+
+class ActiveSupport::TestCase
+ # Transactional fixtures accelerate your tests by wrapping each test method
+ # in a transaction that's rolled back on completion. This ensures that the
+ # test database remains unchanged so your fixtures don't have to be reloaded
+ # between every test method. Fewer database queries means faster tests.
+ #
+ # Read Mike Clark's excellent walkthrough at
+ # http://clarkware.com/cgi/blosxom/2005/10/24#Rails10FastTesting
+ #
+ # Every Active Record database supports transactions except MyISAM tables
+ # in MySQL. Turn off transactional fixtures in this case; however, if you
+ # don't care one way or the other, switching from MyISAM to InnoDB tables
+ # is recommended.
+ #
+ # The only drawback to using transactional fixtures is when you actually
+ # need to test transactions. Since your test is bracketed by a transaction,
+ # any transactions started in your code will be automatically rolled back.
+ self.use_transactional_fixtures = true
+
+ # Instantiated fixtures are slow, but give you @david where otherwise you
+ # would need people(:david). If you don't want to migrate your existing
+ # test cases which use the @david style and don't mind the speed hit (each
+ # instantiated fixtures translates to a database query per test method),
+ # then set this back to true.
+ self.use_instantiated_fixtures = false
+
+ # Setup all fixtures in test/fixtures/*.(yml|csv) for all tests in alphabetical order.
+ #
+ # Note: You'll currently still have to declare fixtures explicitly in integration tests
+ # -- they do not yet inherit this setting
+ fixtures :all
+
+ # Add more helper methods to be used by all tests here...
+end
--
To unsubscribe, e-mail: yast-commit+unsubscribe@opensuse.org
For additional commands, e-mail: yast-commit+help@opensuse.org