| 1 |
= For Edmaru Developers |
| 2 |
|
| 3 |
This document mainly describes the strcture of Edmaru source tree. |
| 4 |
|
| 5 |
== Character encodings |
| 6 |
|
| 7 |
All source files in Edmaru source tree must be encoded by UTF-8. |
| 8 |
|
| 9 |
== Class specification |
| 10 |
|
| 11 |
If you want to improve Edmaru, it is a nice idea to see class |
| 12 |
specifications. Edmaru source codes are designed to generate RDoc |
| 13 |
(http://rdoc.sourceforge.net/) type documentations, therefore, first |
| 14 |
you should run the following command at the root directory of Edmaru |
| 15 |
source tree: |
| 16 |
|
| 17 |
$ ruby gendoc.rb |
| 18 |
|
| 19 |
Then, you can find class specification documents in "doc/rdoc" |
| 20 |
directory and open "doc/rdoc/index.html" by your favorite Web browser |
| 21 |
to see them. |
| 22 |
|
| 23 |
RDoc also supports the output of diagrams that shows the inheritance |
| 24 |
relations among all classes and modules defined in Edmaru source |
| 25 |
tree. If you want to see them, first install "dot" command included |
| 26 |
in graphviz (http://www.graphviz.org/), and then run "gendoc.rb" with "-d" option like: |
| 27 |
|
| 28 |
$ ruby gendoc.rb -d |
| 29 |
|
| 30 |
== Unit tests |
| 31 |
|
| 32 |
Edmaru employs Test::Unit. To carry out all unit test suites, just run |
| 33 |
the following command at the root directory of Edmaru source tree: |
| 34 |
|
| 35 |
$ ruby test.rb |
| 36 |
|
| 37 |
You may add new test suites for Edmaru. Go through the following steps |
| 38 |
to add them: |
| 39 |
|
| 40 |
1. Create a new test suite codes by Test::Unit. |
| 41 |
2. Save the source codes as "test/test_*.rb" |
| 42 |
3. Append a new line to "test.rb" like |
| 43 |
|
| 44 |
require "test/test_*.rb" |
| 45 |
|
| 46 |
== Add new configuration elements |
| 47 |
|
| 48 |
To add new configuration elements, go through the following steps: |
| 49 |
|
| 50 |
1. Create a new source file, for example, "config/my_config.rb". |
| 51 |
2. Add the new created file name to the Array DEFAULT_CONFIG_FILES in config/config_manager.rb |
| 52 |
3. Insert new source codes to "config/my_config.rb" like following: |
| 53 |
|
| 54 |
module Edmaru::Config |
| 55 |
class ConfigManager |
| 56 |
@@default_elements.push ConfigElement.new("/My/Config/Key", |
| 57 |
"Default Value", |
| 58 |
"Description", |
| 59 |
STRING_VALIDATOR) |
| 60 |
end |
| 61 |
end |
| 62 |
|
| 63 |
The important points are the arguments of ConfigElement's initializer, and appending initialized ConfigElement's instance to Edmaru::Config::ConfigManager::default_elemnts. See the comment of Edmaru::Config::ConfigElement#new for more information about initializer. |
| 64 |
|
| 65 |
== Validators |
| 66 |
|
| 67 |
Validator must be an instance of Proc that raises some sort of RuntimeException if passed value, the first argument, is invalid. For example, to cause an element just accept Integer value, write an validator like following: |
| 68 |
|
| 69 |
Proc.new{ |value| |
| 70 |
raise "It's not an integer!" if value.class != Integer |
| 71 |
} |
| 72 |
|
| 73 |
== Predefined Validators |
| 74 |
|
| 75 |
Predefined validators are defined under Edmaru::Config::Validators module. Some of them are defined as constant value like: |
| 76 |
|
| 77 |
STRING_VALIDATOR = Proc.new{ |value| |
| 78 |
raise "Not an instance of String was passed." if value.class != String |
| 79 |
} |
| 80 |
|
| 81 |
And others are defined as method like: |
| 82 |
|
| 83 |
def Validators.LIST_VALIDATOR(array) |
| 84 |
Proc.new{ |value| |
| 85 |
if !array.include?(value) |
| 86 |
raise "#{value} is invalid." |
| 87 |
end |
| 88 |
} |
| 89 |
end |
| 90 |
|
| 91 |
Description and usage of validators defined as method can be seen in Edmaru::Config::Validators module page of class specification. However, you should see standard_validators.rb to know about the validators defined as constant value. |