bcms_settings 0.0.2 → 0.0.3
Sign up to get free protection for your applications and to get access to all the features.
- data/README +130 -207
- data/lib/bcms_settings/cms/settings.rb +47 -67
- data/test/unit/lib/cms/settings_test.rb +41 -2
- metadata +3 -3
data/README
CHANGED
@@ -1,243 +1,166 @@
|
|
1
|
-
|
2
|
-
|
3
|
-
Rails is a web-application framework that includes everything needed to create
|
4
|
-
database-backed web applications according to the Model-View-Control pattern.
|
5
|
-
|
6
|
-
This pattern splits the view (also called the presentation) into "dumb" templates
|
7
|
-
that are primarily responsible for inserting pre-built data in between HTML tags.
|
8
|
-
The model contains the "smart" domain objects (such as Account, Product, Person,
|
9
|
-
Post) that holds all the business logic and knows how to persist themselves to
|
10
|
-
a database. The controller handles the incoming requests (such as Save New Account,
|
11
|
-
Update Product, Show Post) by manipulating the model and directing data to the view.
|
12
|
-
|
13
|
-
In Rails, the model is handled by what's called an object-relational mapping
|
14
|
-
layer entitled Active Record. This layer allows you to present the data from
|
15
|
-
database rows as objects and embellish these data objects with business logic
|
16
|
-
methods. You can read more about Active Record in
|
17
|
-
link:files/vendor/rails/activerecord/README.html.
|
18
|
-
|
19
|
-
The controller and view are handled by the Action Pack, which handles both
|
20
|
-
layers by its two parts: Action View and Action Controller. These two layers
|
21
|
-
are bundled in a single package due to their heavy interdependence. This is
|
22
|
-
unlike the relationship between the Active Record and Action Pack that is much
|
23
|
-
more separate. Each of these packages can be used independently outside of
|
24
|
-
Rails. You can read more about Action Pack in
|
25
|
-
link:files/vendor/rails/actionpack/README.html.
|
26
|
-
|
27
|
-
|
28
|
-
== Getting Started
|
29
|
-
|
30
|
-
1. At the command prompt, start a new Rails application using the <tt>rails</tt> command
|
31
|
-
and your application name. Ex: rails myapp
|
32
|
-
2. Change directory into myapp and start the web server: <tt>script/server</tt> (run with --help for options)
|
33
|
-
3. Go to http://localhost:3000/ and get "Welcome aboard: You're riding the Rails!"
|
34
|
-
4. Follow the guidelines to start developing your application
|
35
|
-
|
36
|
-
|
37
|
-
== Web Servers
|
38
|
-
|
39
|
-
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
|
40
|
-
with a variety of other web servers.
|
41
|
-
|
42
|
-
Mongrel is a Ruby-based webserver with a C component (which requires compilation) that is
|
43
|
-
suitable for development and deployment of Rails applications. If you have Ruby Gems installed,
|
44
|
-
getting up and running with mongrel is as easy as: <tt>gem install mongrel</tt>.
|
45
|
-
More info at: http://mongrel.rubyforge.org
|
46
|
-
|
47
|
-
Say other Ruby web servers like Thin and Ebb or regular web servers like Apache or LiteSpeed or
|
48
|
-
Lighttpd or IIS. The Ruby web servers are run through Rack and the latter can either be setup to use
|
49
|
-
FCGI or proxy to a pack of Mongrels/Thin/Ebb servers.
|
50
|
-
|
51
|
-
== Apache .htaccess example for FCGI/CGI
|
52
|
-
|
53
|
-
# General Apache options
|
54
|
-
AddHandler fastcgi-script .fcgi
|
55
|
-
AddHandler cgi-script .cgi
|
56
|
-
Options +FollowSymLinks +ExecCGI
|
57
|
-
|
58
|
-
# If you don't want Rails to look in certain directories,
|
59
|
-
# use the following rewrite rules so that Apache won't rewrite certain requests
|
60
|
-
#
|
61
|
-
# Example:
|
62
|
-
# RewriteCond %{REQUEST_URI} ^/notrails.*
|
63
|
-
# RewriteRule .* - [L]
|
64
|
-
|
65
|
-
# Redirect all requests not available on the filesystem to Rails
|
66
|
-
# By default the cgi dispatcher is used which is very slow
|
67
|
-
#
|
68
|
-
# For better performance replace the dispatcher with the fastcgi one
|
69
|
-
#
|
70
|
-
# Example:
|
71
|
-
# RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
|
72
|
-
RewriteEngine On
|
73
|
-
|
74
|
-
# If your Rails application is accessed via an Alias directive,
|
75
|
-
# then you MUST also set the RewriteBase in this htaccess file.
|
76
|
-
#
|
77
|
-
# Example:
|
78
|
-
# Alias /myrailsapp /path/to/myrailsapp/public
|
79
|
-
# RewriteBase /myrailsapp
|
80
|
-
|
81
|
-
RewriteRule ^$ index.html [QSA]
|
82
|
-
RewriteRule ^([^.]+)$ $1.html [QSA]
|
83
|
-
RewriteCond %{REQUEST_FILENAME} !-f
|
84
|
-
RewriteRule ^(.*)$ dispatch.cgi [QSA,L]
|
85
|
-
|
86
|
-
# In case Rails experiences terminal errors
|
87
|
-
# Instead of displaying this message you can supply a file here which will be rendered instead
|
88
|
-
#
|
89
|
-
# Example:
|
90
|
-
# ErrorDocument 500 /500.html
|
91
|
-
|
92
|
-
ErrorDocument 500 "<h2>Application error</h2>Rails application failed to start properly"
|
93
|
-
|
94
|
-
|
95
|
-
== Debugging Rails
|
96
|
-
|
97
|
-
Sometimes your application goes wrong. Fortunately there are a lot of tools that
|
98
|
-
will help you debug it and get it back on the rails.
|
99
|
-
|
100
|
-
First area to check is the application log files. Have "tail -f" commands running
|
101
|
-
on the server.log and development.log. Rails will automatically display debugging
|
102
|
-
and runtime information to these files. Debugging info will also be shown in the
|
103
|
-
browser on requests from 127.0.0.1.
|
104
|
-
|
105
|
-
You can also log your own messages directly into the log file from your code using
|
106
|
-
the Ruby logger class from inside your controllers. Example:
|
107
|
-
|
108
|
-
class WeblogController < ActionController::Base
|
109
|
-
def destroy
|
110
|
-
@weblog = Weblog.find(params[:id])
|
111
|
-
@weblog.destroy
|
112
|
-
logger.info("#{Time.now} Destroyed Weblog ID ##{@weblog.id}!")
|
113
|
-
end
|
114
|
-
end
|
1
|
+
# Cms::Settings for BrowserCMS projects
|
115
2
|
|
116
|
-
|
3
|
+
Cms::Settings provides an interface for storing and retrieving
|
4
|
+
arbitrary key value pairs and can be used as a persistent
|
5
|
+
global configuration store.
|
117
6
|
|
118
|
-
|
7
|
+
Cms::Settings stores key value pairs in attributes of ActiveRecord
|
8
|
+
objects. These objects, however, are not designed to be used
|
9
|
+
directly. Rather, this module provides an interface for easy
|
10
|
+
access to the storage objects.
|
119
11
|
|
120
|
-
|
12
|
+
For all installed bcms modules loaded as gems as defined by the BrowserCMS'
|
13
|
+
module instalation process, this module can create a namespaced key value
|
14
|
+
store automatically.
|
121
15
|
|
122
|
-
|
16
|
+
## Installation
|
123
17
|
|
124
|
-
|
125
|
-
|
18
|
+
The Settings module installs like most other BrowserCMS modules
|
19
|
+
(http://guides.browsercms.org/installing_modules.html)
|
20
|
+
except that it does not define any new routes and requires one
|
21
|
+
additional step.
|
126
22
|
|
127
|
-
|
128
|
-
and also on programming in general.
|
23
|
+
gem install bcms_settings
|
129
24
|
|
25
|
+
## Set up your application to use the module
|
130
26
|
|
131
|
-
|
27
|
+
### 1. Edit config/environment.rb
|
132
28
|
|
133
|
-
|
134
|
-
|
135
|
-
in the code, investigate and change the model, AND then resume execution!
|
136
|
-
You need to install ruby-debug to run the server in debugging mode. With gems, use 'gem install ruby-debug'
|
137
|
-
Example:
|
29
|
+
config.gem "browsercms"
|
30
|
+
config.gem "bcms_settings"
|
138
31
|
|
139
|
-
|
140
|
-
|
141
|
-
|
142
|
-
|
143
|
-
|
144
|
-
|
32
|
+
### 2. Run the following commands
|
33
|
+
|
34
|
+
script/generate browser_cms
|
35
|
+
rake db:migrate
|
36
|
+
|
37
|
+
### 3. Add the following line to the browsercms.rb initializer
|
38
|
+
|
39
|
+
Cms::Settings.synchronize
|
40
|
+
|
41
|
+
## Usage
|
42
|
+
|
43
|
+
### Cms::Settings.syncronize
|
44
|
+
|
45
|
+
Calling this method in an initializer will keep your installed modules
|
46
|
+
(as declared on environment.rb) in sync with the Settings module.
|
47
|
+
|
48
|
+
If a BrowserCMS project declares the following gem dependencies
|
49
|
+
in environment.rb:
|
50
|
+
|
51
|
+
gem.bcms_s3
|
52
|
+
gem.bcms_seo_sitemap
|
53
|
+
|
54
|
+
client code can access the following objects automatically:
|
55
|
+
|
56
|
+
Cms::Settings.bcms_s3
|
57
|
+
=> #<Cms::Settings: bcms_s3 => {}>
|
58
|
+
|
59
|
+
Cms::Settings.bcms_seo_sitemap
|
60
|
+
=> #<Cms::Settings: bcms_seo_sitemap => {}>
|
61
|
+
|
62
|
+
if you uninstall bcms_xyz (by removing it from environment.rb)
|
63
|
+
the corresponding settings oject will be destroyed for you.
|
64
|
+
|
65
|
+
To know which bcms_modules the Settings module knows about:
|
145
66
|
|
146
|
-
|
147
|
-
with a IRB prompt in the server window. Here you can do things like:
|
67
|
+
Cms::Settings.modules => ['bcms_s3', 'bcms_seo_sitemap']
|
148
68
|
|
149
|
-
|
150
|
-
=> "[#<Post:0x14a6be8 @attributes={\"title\"=>nil, \"body\"=>nil, \"id\"=>\"1\"}>,
|
151
|
-
#<Post:0x14a6620 @attributes={\"title\"=>\"Rails you know!\", \"body\"=>\"Only ten..\", \"id\"=>\"2\"}>]"
|
152
|
-
>> @posts.first.title = "hello from a debugger"
|
153
|
-
=> "hello from a debugger"
|
69
|
+
### Storing, retrieving and deleting values
|
154
70
|
|
155
|
-
|
71
|
+
To store values in these objects just call arbitrary methods (which will become
|
72
|
+
keys) and assign values. It is possile to store scalar values, arrays and
|
73
|
+
hashes. Values ar persisted automatically.
|
156
74
|
|
157
|
-
|
158
|
-
|
159
|
-
>> f.
|
160
|
-
Display all 152 possibilities? (y or n)
|
75
|
+
Cms::Settings.bcms_s3.account_id = "ACCOUNT_ID"
|
76
|
+
Cms::Settings.bcms_s3.buckets = %w[bucket1 bucket2]
|
161
77
|
|
162
|
-
|
78
|
+
After adding these two values, the object looks like this:
|
163
79
|
|
80
|
+
Cms::Settings.bcms_s3
|
81
|
+
=> #<Cms::Settings: bcms_s3 => {"account_id"=>"ACCOUNT_ID", "buckets"=>["bucket1", "bucket2"]}>
|
164
82
|
|
165
|
-
|
83
|
+
To retrieve values:
|
166
84
|
|
167
|
-
|
168
|
-
|
169
|
-
application is running. You can inspect domain models, change values, and save to the
|
170
|
-
database. Starting the script without arguments will launch it in the development environment.
|
171
|
-
Passing an argument will specify a different environment, like <tt>script/console production</tt>.
|
85
|
+
Cms::Settings.bcms_s3.account_id
|
86
|
+
=> "ACCOUNT_ID"
|
172
87
|
|
173
|
-
|
88
|
+
Cms::Settings.bcms_s3.buckets.first
|
89
|
+
=> "bucket1"
|
174
90
|
|
175
|
-
|
91
|
+
To update keys, just assign new values:
|
176
92
|
|
177
|
-
|
178
|
-
|
179
|
-
|
180
|
-
argument will connect you to a different database, like <tt>script/dbconsole production</tt>.
|
181
|
-
Currently works for mysql, postgresql and sqlite.
|
93
|
+
Cms::Settings.bcms_s3.account_id = "NEW_ID"
|
94
|
+
Cms::Settings.bcms_s3.account_id
|
95
|
+
=> "NEW_ID"
|
182
96
|
|
183
|
-
|
97
|
+
To delete values, call the delete method on the settings object:
|
184
98
|
|
185
|
-
|
186
|
-
|
99
|
+
Cms::Settings.bcms_s3.delete("buckets")
|
100
|
+
Cms::Settings.bcms_s3
|
101
|
+
=> #<Cms::Settings: bcms_s3 => {"account_id"=>"NEW_ID"}
|
187
102
|
|
188
|
-
|
189
|
-
|
190
|
-
automated URL mapping. All controllers should descend from ApplicationController
|
191
|
-
which itself descends from ActionController::Base.
|
103
|
+
Keys can have almost any name, except for these:
|
104
|
+
["inspect", "__send__", "delete", "instance_eval", "__metaclass__", "method_missing"]
|
192
105
|
|
193
|
-
app/models
|
194
|
-
Holds models that should be named like post.rb.
|
195
|
-
Most models will descend from ActiveRecord::Base.
|
196
106
|
|
197
|
-
|
198
|
-
Holds the template files for the view that should be named like
|
199
|
-
weblogs/index.html.erb for the WeblogsController#index action. All views use eRuby
|
200
|
-
syntax.
|
107
|
+
### Registering and deleting modules
|
201
108
|
|
202
|
-
|
203
|
-
|
204
|
-
header/footer method of wrapping views. In your views, define a layout using the
|
205
|
-
<tt>layout :default</tt> and create a file named default.html.erb. Inside default.html.erb,
|
206
|
-
call <% yield %> to render the view using this layout.
|
109
|
+
It is also possible to register and delete modules manually in addition to or
|
110
|
+
as an alternative to caling Settings.synchronize.
|
207
111
|
|
208
|
-
|
209
|
-
Holds view helpers that should be named like weblogs_helper.rb. These are generated
|
210
|
-
for you automatically when using script/generate for controllers. Helpers can be used to
|
211
|
-
wrap functionality for your views into methods.
|
112
|
+
To register modules:
|
212
113
|
|
213
|
-
|
214
|
-
Configuration files for the Rails environment, the routing map, the database, and other dependencies.
|
114
|
+
Cms::Settings.register("bcms_my_module")
|
215
115
|
|
216
|
-
|
217
|
-
Contains the database schema in schema.rb. db/migrate contains all
|
218
|
-
the sequence of Migrations for your schema.
|
116
|
+
then you can store, retrieve and delete arbitrary values:
|
219
117
|
|
220
|
-
|
221
|
-
|
222
|
-
|
118
|
+
config = Cms::Settings.bcms_my_module
|
119
|
+
config.client = "Widgets INC"
|
120
|
+
config.url = "http://example.com"
|
121
|
+
config.sections = %w[A B C]
|
223
122
|
|
224
|
-
|
225
|
-
|
226
|
-
belong under controllers, models, or helpers. This directory is in the load path.
|
123
|
+
config.url
|
124
|
+
=> "http://example.com
|
227
125
|
|
228
|
-
|
229
|
-
The directory available for the web server. Contains subdirectories for images, stylesheets,
|
230
|
-
and javascripts. Also contains the dispatchers and the default HTML files. This should be
|
231
|
-
set as the DOCUMENT_ROOT of your web server.
|
126
|
+
config.delete("url")
|
232
127
|
|
233
|
-
|
234
|
-
|
128
|
+
config.url
|
129
|
+
=> nil
|
130
|
+
|
131
|
+
In reality, 'registering a module' only creates an object where
|
132
|
+
to store values, so you can request sorage to the Settings module for
|
133
|
+
whatever porpose you like, povinding that:
|
134
|
+
|
135
|
+
1. The name you are trying to register is a valid BrowserCMS module
|
136
|
+
name and a valid Ruby method identifier, so this is valid:
|
137
|
+
|
138
|
+
Cms::Settings.register("bcms_my_config")
|
139
|
+
|
140
|
+
but this is not:
|
141
|
+
|
142
|
+
Cms::Settings.register("My Config")
|
143
|
+
|
144
|
+
2. The name you are trying to register has not been registered
|
145
|
+
previously. Names passed to the register method must be unique.
|
146
|
+
|
147
|
+
|
148
|
+
To delete modules:
|
149
|
+
|
150
|
+
Cms::Settings.delete("bcms_my_config") #all values will be lost
|
151
|
+
|
152
|
+
Cms::Settings.bcms_by_config #Raises an exception
|
153
|
+
=> ModuleNotRegistered
|
154
|
+
|
155
|
+
|
156
|
+
## Module development
|
157
|
+
|
158
|
+
If you are developing a BrowserCMS module and want to use the Settings
|
159
|
+
API you'll need to include something like this in an initializer while
|
160
|
+
on development:
|
161
|
+
|
162
|
+
unless Cms::Settings.modules.include?('bcms_my_module')
|
163
|
+
Cms::Settings.register('bcms_my_module')
|
164
|
+
end
|
235
165
|
|
236
|
-
test
|
237
|
-
Unit and functional tests along with fixtures. When using the script/generate scripts, template
|
238
|
-
test files will be generated for you and placed in this directory.
|
239
166
|
|
240
|
-
vendor
|
241
|
-
External libraries that the application depends on. Also includes the plugins subdirectory.
|
242
|
-
If the app has frozen rails, those gems also go here, under vendor/rails/.
|
243
|
-
This directory is in the load path.
|
@@ -1,58 +1,4 @@
|
|
1
1
|
module Cms
|
2
|
-
# Cms::Settings provides an interface for storing and retrieving
|
3
|
-
# arbitrary key value pairs and can be used as a persistent
|
4
|
-
# global configuration store.
|
5
|
-
#
|
6
|
-
# Cms::Settings stores key value pairs in attributes of ActiveRecord
|
7
|
-
# objects. These objects, however, are not designed to be used
|
8
|
-
# directly. Rather, this module provides an interface for easy
|
9
|
-
# access to the storage objects.
|
10
|
-
#
|
11
|
-
# For all installed bcms modules loaded as gems as defined by the BrowserCMS'
|
12
|
-
# module instalation process, this module creates a namespaced key value
|
13
|
-
# store automatically.
|
14
|
-
#
|
15
|
-
# To know which bcms_modules the Settings module knows about:
|
16
|
-
# Cms::Settings.modules => [] #an empty array for new projects.
|
17
|
-
#
|
18
|
-
# If a BrowserCMS project declares the following gem dependencies
|
19
|
-
# in environment.rb:
|
20
|
-
#
|
21
|
-
# gem.bcms_s3
|
22
|
-
# gem.bcms_seo_sitemap
|
23
|
-
#
|
24
|
-
# Client code can access the following objects automatically:
|
25
|
-
#
|
26
|
-
# Cms::Settings.bcms_s3 => #<Cms::Settings: bcms_s3 => {}>
|
27
|
-
# Cms::Settings.bcms_seo_sitemap => #<Cms::Settings: bcms_seo_sitemap => {}>
|
28
|
-
#
|
29
|
-
# To store key, value pairs just call an "=" method with an arbitrary name
|
30
|
-
# and value:
|
31
|
-
#
|
32
|
-
# Cms::Settings.bcms_s3.account_id = "ACCOUNT_ID"
|
33
|
-
# Cms::Settings.bcms_s3.buckets = %w[bucket1 bucket2]
|
34
|
-
#
|
35
|
-
# After adding these two values, the object looks like this:
|
36
|
-
#
|
37
|
-
# Cms::Settings.bcms_s3 => <Cms::Settings: bcms_s3 => {"account_id"=>"ACCOUNT_ID", "buckets"=>["bucket1", "bucket2"]}>
|
38
|
-
#
|
39
|
-
# To retrieve values:
|
40
|
-
#
|
41
|
-
# Cms::Settings.bcms_s3.account_id => "ACCOUNT_ID"
|
42
|
-
# Cms::Settings.bcms_s3.buckets.first = "bucket1"
|
43
|
-
#
|
44
|
-
# To update keys, just assign new values:
|
45
|
-
#
|
46
|
-
# Cms::Settings.bcms_s3.account_id = "NEW_ID"
|
47
|
-
# Cms::Settings.bcms_s3.account_id => "NEW_ID"
|
48
|
-
#
|
49
|
-
# To delete values, call the delete method on the settings object:
|
50
|
-
#
|
51
|
-
# Cms::Settings.bcms_s3.delete("buckets")
|
52
|
-
# Cms::Settings.bcms_s3 => #<Cms::Settings: bcms_s3 => {"account_id"=>"NEW_ID"}
|
53
|
-
#
|
54
|
-
# Keys can have almost any name, except:
|
55
|
-
# ["inspect", "__send__", "delete", "instance_eval", "__metaclass__", "method_missing", "__id__"]
|
56
2
|
|
57
3
|
module Settings
|
58
4
|
|
@@ -115,16 +61,48 @@ module Cms
|
|
115
61
|
# Manually registered modules are ignored by the synchronize method.
|
116
62
|
#
|
117
63
|
# Cms::Settings.register("bcms_foo")
|
118
|
-
# Cms::Settings.bcms_foo will be prsisted in the
|
64
|
+
# Cms::Settings.bcms_foo will be prsisted in the the database until
|
119
65
|
# manually deleted.
|
120
66
|
#
|
121
67
|
# Manually registered module names must conform to BCMS's module naming
|
122
68
|
# conventions, so this call will raise an InvalidModuleName exception:
|
123
69
|
# Cms::Settings.register("foo") => InvalidModuleName
|
124
70
|
#
|
125
|
-
#
|
71
|
+
# Modules can only be registered once:
|
126
72
|
# Cms::Settings.modules => ["bcms_s3", "bcms_seo_sitemap"]
|
127
73
|
# Cms::Settings.register("bcms_s3") => ModuleConfigurationExists
|
74
|
+
#
|
75
|
+
# ******************
|
76
|
+
# **IMPORTANT NOTE**
|
77
|
+
# ******************
|
78
|
+
# When developing modules that use the Settings API, it is necessary to
|
79
|
+
# register them manually since they can't declare themselves as
|
80
|
+
# dependencies. This can be done in an initializer, however, since
|
81
|
+
# modules can only be registered once, every time the modules' project
|
82
|
+
# boots, an exception will be raised.
|
83
|
+
#
|
84
|
+
# One possible workaround is to check if the module is registered already:
|
85
|
+
#
|
86
|
+
# unless Cms::Settings.modules.include?('bcms_seo_sitemap')
|
87
|
+
# Cms::Settings.register('bcms_seo_sitemap')
|
88
|
+
# end
|
89
|
+
#
|
90
|
+
# A marginally better approach would be something like:
|
91
|
+
#
|
92
|
+
# unless Cms::Settings.registered?('bcms_seo_sitemap')
|
93
|
+
# Cms::Settings.register('bcms_seo_sitemap')
|
94
|
+
# end
|
95
|
+
#
|
96
|
+
# Another possibility is to have the register method fail silently if the
|
97
|
+
# module already exists or just log a warning.
|
98
|
+
#
|
99
|
+
# I do like the exceptions approach because it makes it evident that
|
100
|
+
# somehow, somewhere, for some reason, someone registered that module
|
101
|
+
# previously and may be using the configuration object for something.
|
102
|
+
#
|
103
|
+
# This is particularly important because in reality, 'registered modules'
|
104
|
+
# need not to even be modules at all. Someone may just register
|
105
|
+
# 'bcms_my_configuration' for whatever purpose even from the console.
|
128
106
|
|
129
107
|
def register(module_name)
|
130
108
|
register_modules [module_name], false
|
@@ -186,7 +164,7 @@ module Cms
|
|
186
164
|
|
187
165
|
def installed_modules
|
188
166
|
Rails.configuration.gems.map do |g|
|
189
|
-
g.name if g.name =~ /^bcms_/
|
167
|
+
g.name if g.name =~ /^bcms_/ && g.name != 'bcms_settings'
|
190
168
|
end.compact.uniq
|
191
169
|
end
|
192
170
|
|
@@ -198,16 +176,18 @@ module Cms
|
|
198
176
|
end
|
199
177
|
|
200
178
|
def register_modules(module_names, managed = true)
|
201
|
-
|
202
|
-
|
203
|
-
|
204
|
-
|
205
|
-
|
206
|
-
|
207
|
-
|
208
|
-
|
209
|
-
|
210
|
-
|
179
|
+
if CmsModule.table_exists?
|
180
|
+
module_names.each do |name|
|
181
|
+
verify_module_name(name)
|
182
|
+
begin
|
183
|
+
CmsModule.create!(:name => name.to_s,
|
184
|
+
:settings => {},
|
185
|
+
:cms_managed => managed)
|
186
|
+
|
187
|
+
rescue ActiveRecord::RecordInvalid
|
188
|
+
raise ModuleConfigurationExists,
|
189
|
+
"The module #{name} is already registered."
|
190
|
+
end
|
211
191
|
end
|
212
192
|
end
|
213
193
|
end
|
@@ -88,14 +88,53 @@ class SettingsTest < ActiveSupport::TestCase
|
|
88
88
|
end
|
89
89
|
end
|
90
90
|
|
91
|
-
test "raises NoMethodError for undefined methods that do not conform with BCMS module naming convention
|
91
|
+
test "raises NoMethodError for undefined methods that do not conform with BCMS module naming convention" do
|
92
92
|
assert_raise(NoMethodError) do
|
93
93
|
Cms::Settings.wibble
|
94
94
|
end
|
95
95
|
end
|
96
96
|
|
97
|
-
|
97
|
+
#TODO: The following tests for CmsModuleProxy should probably be split to a different file.
|
98
|
+
|
99
|
+
test "should store values for arbitrary keys" do
|
100
|
+
register_modules 'bcms_s3'
|
101
|
+
Cms::Settings.bcms_s3.account_id = "ACCOUNT_ID"
|
102
|
+
assert_equal "ACCOUNT_ID", Cms::Settings.bcms_s3.account_id
|
103
|
+
end
|
104
|
+
|
105
|
+
test "sohould store arrays" do
|
106
|
+
register_modules 'bcms_blog'
|
107
|
+
config = Cms::Settings.bcms_blog
|
108
|
+
config.options = %w[A B C]
|
109
|
+
assert_equal "C", config.options.last
|
110
|
+
end
|
111
|
+
|
112
|
+
test "should update values" do
|
113
|
+
register_modules 'bcms_blog'
|
114
|
+
config = Cms::Settings.bcms_blog
|
115
|
+
config.authors = ['Sue', 'Mike']
|
116
|
+
assert_equal 'Sue', config.authors[0]
|
117
|
+
config.authors[0] = 'Zoe'
|
118
|
+
assert_equal 'Zoe', config.authors[0]
|
119
|
+
end
|
98
120
|
|
121
|
+
test "should destroy key value pairs" do
|
122
|
+
register_modules 'bcms_wibble'
|
123
|
+
config = Cms::Settings.bcms_wibble
|
124
|
+
config.depth = 3
|
125
|
+
assert_equal 3, config.depth
|
126
|
+
config.delete("depth")
|
127
|
+
assert !config.depth
|
128
|
+
end
|
129
|
+
|
130
|
+
test "should raise NoMethodError for methods with arity > 1" do
|
131
|
+
register_modules 'bcms_wibble'
|
132
|
+
assert_raise(NoMethodError) do
|
133
|
+
Cms::Settings.bcms.wibble.something('a', 'b')
|
134
|
+
end
|
135
|
+
end
|
136
|
+
|
137
|
+
private
|
99
138
|
def register_modules(*names)
|
100
139
|
names.each {|n| CmsModule.create(:name => n, :settings => {})}
|
101
140
|
end
|
metadata
CHANGED
@@ -1,13 +1,13 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: bcms_settings
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
hash:
|
4
|
+
hash: 25
|
5
5
|
prerelease: false
|
6
6
|
segments:
|
7
7
|
- 0
|
8
8
|
- 0
|
9
|
-
-
|
10
|
-
version: 0.0.
|
9
|
+
- 3
|
10
|
+
version: 0.0.3
|
11
11
|
platform: ruby
|
12
12
|
authors:
|
13
13
|
- BrowserMedia
|