-
Notifications
You must be signed in to change notification settings - Fork 1
Module Development
To create a new module, you need to be familliar with Rails its “Engines” functionality. Just put your module in modules directory and start developing.
Declare list of gems your module uses in this file. Lines in this file will be evaluated in config/environment.rb when OpenKH loads.
Ex:
config.gem ‘ruby-openid’, ‘>= 2’
There are some things in OpenKH that your module can use:
- Plugins: See vendor/plugins to see a list of plugins your module can uses. Google for more information about them.
Write in SASS instead of normal CSS and put .sass files in app/stylesheets directory. It will be compiled and included to application.css.
Put .js.erb files at app/views/javascripts/name.js.erb directory. They will be accessed through http://server/javascripts/name.js.
IMPORTANT: jRails is used instead of Prototype/Scriptaculous. As a result you use jQuery instead of Prototype/Scriptaculous.
They are utility methods which will be included in both ActionView::Base and ActionController::Base. Hooks are methods that hook into helpers to add features in the IoC/AOP style.
If helpers are put in “helpers” directory, they will be reloaded automatically, as a result hooks will be useless.
Please put helpers in “helpers_hooks”. Helpers will be loaded before hooks. Both will not be reloaded even in development mode. Be sure to restart the web server after making any modification in “helpers_hooks”.
They are:
- CONF, from each module’s init.rb
- Conf, from DB
- params
- mod
mod is a hash which is created at the beginning of a HTTP request and destroyed at the end. See the document for its keys and their meanings.
You can use mod to store temporary data.
Views for things other than actions must be partials, e.g. prefixed with underscore.
Use HAML and SASS.
Ids and classes of HTML elements of module mod_xxx must be prefixed with xxx_
If helpers and controller actions share the same view, the view should be partial.
For consistent style, always use Rails helpers: text_field, text_field_tag, password_field, password_field_tag, text_area, text_area_tag.
This plugin has bug that always add created_at and updated_at to the versioned table if you have them in the main table, even if in your model:
class Model < ActiveRecord::Base
acts_as_versioned
self.non_versioned_columns << 'created_at' << 'updated_at'
end
Thus in the migration you must manually remove these columns:
create_table :models do |t|
…
end
Model.create_versioned_table
remove_column :model_versions, :created_at, :updated_at
Migration file must be named in the following form to avoid conflict among modules:
[prefix number][number]_[name].rb
Prefix number is calculated by the command:
rake openkh:db:migrate:prefix MODULE=[module name]
See db/migrate directories of existing modules for examples.
- To migrate:
rake openkh:db:migrate MODULE=[module name] - To reset:
rake openkh:db:migrate MODULE=[module name] VERSION=0
See lib/tasks/openkh_db.rake for more information.
Install and uninstall scripts should be put in migration’s up and down. That means that up and down may contain things not related to DB.
The heart of every CMS is content. In OpenKH, a content has the following properties:
- It can be listed, sorted, commented
- It can be indexed and searched by the built-in search engine
Common utilities for creating content modules are provided by the module “content_common”. Please take existing content modules as examples.