scheduled_resource 0.0.1 → 0.0.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
metadata CHANGED
@@ -1,43 +1,43 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: scheduled_resource
3
3
  version: !ruby/object:Gem::Version
4
- version: 0.0.1
4
+ version: 0.0.2
5
5
  platform: ruby
6
6
  authors:
7
7
  - Mike Cannon
8
8
  autorequire:
9
9
  bindir: bin
10
10
  cert_chain: []
11
- date: 2015-02-18 00:00:00.000000000 Z
11
+ date: 2015-03-13 00:00:00.000000000 Z
12
12
  dependencies:
13
13
  - !ruby/object:Gem::Dependency
14
14
  name: rails
15
15
  requirement: !ruby/object:Gem::Requirement
16
16
  requirements:
17
- - - ">="
17
+ - - "~>"
18
18
  - !ruby/object:Gem::Version
19
- version: '0'
19
+ version: '4.2'
20
20
  type: :runtime
21
21
  prerelease: false
22
22
  version_requirements: !ruby/object:Gem::Requirement
23
23
  requirements:
24
- - - ">="
24
+ - - "~>"
25
25
  - !ruby/object:Gem::Version
26
- version: '0'
26
+ version: '4.2'
27
27
  - !ruby/object:Gem::Dependency
28
28
  name: coffee-rails
29
29
  requirement: !ruby/object:Gem::Requirement
30
30
  requirements:
31
- - - ">="
31
+ - - "~>"
32
32
  - !ruby/object:Gem::Version
33
- version: '0'
33
+ version: '4.1'
34
34
  type: :runtime
35
35
  prerelease: false
36
36
  version_requirements: !ruby/object:Gem::Requirement
37
37
  requirements:
38
- - - ">="
38
+ - - "~>"
39
39
  - !ruby/object:Gem::Version
40
- version: '0'
40
+ version: '4.1'
41
41
  - !ruby/object:Gem::Dependency
42
42
  name: bundler
43
43
  requirement: !ruby/object:Gem::Requirement
@@ -67,57 +67,80 @@ dependencies:
67
67
  - !ruby/object:Gem::Version
68
68
  version: '10.0'
69
69
  description: "== README.md:\n#ScheduledResource\n\nThis gem is for displaying how
70
- things are used\nover time -- a schedule for a set of resources. It\nprovides a
71
- way to describe what is being displayed,\nalong with utilities and protocols to
72
- connect them:\n\n - Configuration (specification and management),\n - Query interfaces
73
- (a REST-like API and internal protocols to query the models), and\n - A basic Rails
74
- controller implementation.\n\nSo we have a way to configure the schedule, internal\nmethods
75
- to generate the data, and a way to retrieve\ndata from the client. But the gem
70
+ things are used\nover time -- a schedule for a set of \"resources\". You\ncan configure
71
+ the elements of the schedule and there\nare utilities and protocols to connect them:\n\n
72
+ - Configuration (specification and management),\n - Query interfaces (a REST-like
73
+ API and internal protocols to query the models), and\n - A basic Rails controller
74
+ implementation.\n\nWe have a way to configure the schedule, internal\nmethods to
75
+ generate the data, and a way to retrieve\ndata from the client. However this gem
76
76
  is largely\nview-framework agnostic. We could use a variety of\nclient-side packages
77
77
  or even more traditional Rails\nview templates to generate HTML.\n\nIn any case,
78
- to get a the most from a display like this\nwe need some client-side code. The
79
- gem includes\nclient-side modules to:\n\n - Manage <b>time and display geometries</b>
78
+ to get a good feel in a display like\nthis we need some client-side code. The gem
79
+ includes\nclient-side modules to:\n\n - Manage <b>time and display geometries</b>
80
80
  with \"infinite\" scroll along the time axis.\n - <b>Format display cells</b> in
81
81
  ways specific to the resource models.\n - <b>Update text justification</b> as the
82
- display is scrolled horizontally.\n\n\n## Configuration Management\n\nA **scheduled
83
- resource** is something that can be\nused for one thing at a time. Say \"Rocky
84
- & Bullwinkle\"\nis on channel 3 from 10am to 11am on Saturday. Then\n'channel 3'
85
- is the <u>resource</u> and that showing of\nthe is a <u>resource-use block</u>.
86
- \ Resources and \nuse-blocks are typically Rails models. Each resource\nand its
87
- use-blocks get one row in the display. That\nrow has a label to the left with some
88
- timespan visible\non the rest of the row.\n\nThe <b>ScheduledResource</b> class
89
- manages resource and\nuse-block class names, id's and labels for a schedule.\nA
90
- ScheduledResource instance ties together:\n\n 1. A resource class (eg TvStation),\n
91
- 2. An id (a channel number in this example), and\n 3. Strings and other assets that
92
- will go into the DOM.\n\nThe id is used to\n - select a resource <em>instance</em>
93
- and\n - select instances of the <em>resource use block</em> class (eg Program instances).\n\nThe
94
- id <em>could</em> be a database id but more\noften is something a little more suited
95
- to human use\nin the configuration. In any case it is used by model\nclass method\n<tt>(resource_use_block_class).get_all_blocks()</tt>\nto
82
+ display is scrolled horizontally.\n\n\n## Configuration\n\nA **scheduled resource**
83
+ is something that can be\nused for one thing at a time. So if \"Rocky & Bullwinkle\"\nis
84
+ on channel 3 from 10am to 11am on Saturday, then\n'channel 3' is the <u>resource</u>
85
+ and that showing of\nthe episode is a <u>resource-use</u> block. Resources \nand
86
+ use-blocks are typically Rails models. Each resource\nand its use-blocks get one
87
+ row in the display. That\nrow has a label to the left with some timespan visible\non
88
+ the rest of the row.\n\nSomething else you would expect see in a schedule\nwould
89
+ be headers and labels -- perhaps one row with\nthe date and another row with the
90
+ hour. Headers and\nlabels also fit the model of resources and use-blocks.\nBasic
91
+ timezone-aware classes (ZTime*) for those are\nincluded in this gem.\n\n\n### Config
92
+ File\n\nThe schedule configuration comes from\n<tt>config/resource_schedule.yml</tt>
93
+ which has\nthree top-level sections:\n\n- ResourceKinds: A hash where the key is
94
+ a Resource and the value is a UseBlock. (Both are class names),\n- Resources: A
95
+ list where each item is a Resource Class followed by one or more resource ids, and\n-
96
+ visibleTime: The visible timespan of the schedule in seconds.\n\nThe example file
97
+ <tt>config/resource_schedule.yml</tt>\n(installed when you run <tt>schedulize</tt>)
98
+ should be\nenough to display a two-row schedule with just the date\nabove and the
99
+ hour below. Of course you can monkey-patch\nor subclass these classes for your
100
+ own needs.\n\n\n### The schedule API\n\nThe 'schedule' endpoint uses parameters
101
+ <tt>t1</tt> and\n<tt>t2</tt> to specify a time interval for the request.\nA third
102
+ parameter <tt>inc</tt> allows an initial time\nwindow to be expanded without repeating
103
+ blocks that\nspan those boundaries. The time parameters\n_plus the configured resources_
104
+ define the data to be returned.\n\n\n### More About Configuration Management\n\nThe
105
+ <b>ScheduledResource</b> class manages resource and\nuse-block class names, id's
106
+ and labels for a schedule\naccording to the configuration file.\nA ScheduledResource
107
+ instance ties together:\n\n 1. A resource class (eg TvStation),\n 2. An id (a channel
108
+ number in this example), and\n 3. Strings and other assets that will go into the
109
+ DOM.\n\nThe id is used to\n - select a resource _instance_ and\n - select instances
110
+ of the _resource use block_ class (eg Program instances).\n\nThe id _could_ be a
111
+ database id but more\noften is something a little more suited to human use\nin the
112
+ configuration. In any case it is used by model\nclass method\n<tt>(resource_use_block_class).get_all_blocks()</tt>\nto
96
113
  select the right use-blocks for the resource.\nA resource class name and id are
97
- are joined with\na '_' to form a tag that also serves as an id for the DOM.\n\nSomething
98
- else you would expect see in a schedule\nwould be headers and labels -- perhaps
99
- one row with\nthe date and another row with the hour. Headers and\nlabels also
100
- fit the model of resources and use_blocks.\nBasic timezone-aware classes (ZTime*)
101
- for those are\nincluded in this gem.\n\n\n### Configuration File\n\nThe schedule
102
- configuration comes from\n<tt>config/resource_schedule.yml</tt> which has\nthree
103
- top-level sections:\n\n- ResourceKinds: A hash where the key is a Resource and
104
- the value is a UseBlock. (Both are class names),\n- Resources: A list where each
105
- item is a Resource Class followed by one or more resource ids, and\n- visibleTime:
106
- \ The visible timespan of the schedule in seconds.\n\nThe example file <tt>config/resource_schedule.yml</tt>\n(installed
107
- when you run <tt>schedulize</tt>) should be\nenough to display a two-row schedule
108
- with just the date\nabove and the hour below. Of course you can monkey-patch\nor
109
- subclass these classes for your own needs.\n\n\n### The schedule API\n\nThe endpoint
110
- uses parameters <tt>t1</tt> and\n<tt>t2</tt> to specify a time interval for the
111
- request.\nA third parameter <tt>inc</tt> allows an initial time\nwindow to be expanded
112
- without repeating blocks that\nspan those boundaries. The time parameters _plus
113
- the\nconfigured resources_ define the data to be returned.\n\n\n### More About Configuration
114
- Management\n\nOnce the configuration yaml is loaded that data is\nmaintained in
115
- the session structure. Of course having\na single configuration file limits the
116
- application's\nusefulness. A more general approach would be to\nhave a user model
117
- with login and configuration would\nbe associated with the user.\n\n\n\n\n\n\n##
118
- Installation\n\nAdd this line to your application's Gemfile:\n\n```ruby\ngem 'scheduled_resource'\n```\n\nAnd
119
- then execute:\n\n $ bundle\n\nOr install it yourself as:\n\n $ gem install
120
- scheduled_resource\n\n## Usage\n\nTo Do: Write usage instructions here\n\n## Contributing\n\n1.
114
+ are joined with\na '_' to form a tag that also serves as an id for the DOM.\n\nOnce
115
+ the configuration yaml is loaded that data is\nmaintained in the session structure.
116
+ \ Of course having\na single configuration file limits the application's\nusefulness.
117
+ \ A more general approach would be to\nhave a user model with login and configuration
118
+ would\nbe associated with the user.\n\n\n## Installation\n\nAdd this line to your
119
+ application's Gemfile:\n\n```ruby\ngem 'scheduled_resource'\n```\n\nAnd then execute:\n\n
120
+ \ $ bundle\n\nOr install it yourself as:\n\n $ gem install scheduled_resource\n\nThen
121
+ from your application's root execute:\n\n $ schedulize .\n\nThis will install
122
+ a few image placeholders, \nclient-side modules and a stylesheet under \n<tt>vendor/assets</tt>,
123
+ an example configuration\nin <tt>config/resource_schedule.yml</tt> and\nan example
124
+ controller in\n<tt>app/controllers/schedule_controller.rb</tt>.\n\nAlso, if you
125
+ use\n\n $ bundle show scheduled_resource\n\nto locate the installed source you
126
+ can browse\nexample classes <tt>lib/z_time_*.rb</tt> and\nthe controller helper
127
+ methods in\n<tt>lib/scheduled_resource/helper.rb</tt>\n\n\n## Testing\n\nThis gem
128
+ also provides for a basic test application\nusing angularjs to display a minimal
129
+ but functional\nschedule showing just the day and hour headers in\ntwo different
130
+ timezones (US Pacific and Eastern).\nProceed as follows, starting with a fresh Rails
131
+ app:\n\n $ rails new test_sr\n\nAs above, add the gem to the Gemfile, then \n\n
132
+ \ $ cd test_sr\n $ bundle\n $ schedulize .\n\nAdd lines such as these to
133
+ <tt>config/routes.rb</tt>\n\n get \"/schedule/index\" => \"schedule#index\"\n
134
+ \ get \"/schedule\" => \"schedule#schedule\"\n\nCopy / merge these files
135
+ from the gem source into\nthe test app:\n\n $SR_SRC/app/views/layouts/application.html.erb\n
136
+ \ $SR_SRC/app/views/schedule/index.html.erb\n $SR_SRC/app/assets/javascripts/{angular.js,script.js,controllers.js}\n\nand
137
+ add <tt>//= require angular</tt> to application.js\njust below the entries for <tt>jquery</tt>.\n\nAfter
138
+ you run the server and browse to\n\n http://0.0.0.0:3000/schedule/index\n\nyou
139
+ should see the four time-header rows specified\nby the sample config file.\n\n\n##
140
+ More Examples\n\nA better place to see the use of this gem is at\n[tv4](https://github.com/emeyekayee/tv4).
141
+ \ Specifically,\nmodels <tt>app/models/event.rb</tt> and\n<tt>app/models/station.rb</tt>
142
+ give better examples of\nimplementing the ScheduledResource protocol and adapting\nto
143
+ a db schema organized along somewhat different lines.\n\n\n\n\n## Contributing\n\n1.
121
144
  Fork it ( https://github.com/emeyekayee/scheduled_resource/fork )\n2. Create your
122
145
  feature branch (`git checkout -b my-new-feature`)\n3. Commit your changes (`git
123
146
  commit -am 'Add some feature'`)\n4. Push to the branch (`git push origin my-new-feature`)\n5.
@@ -134,6 +157,11 @@ files:
134
157
  - LICENSE
135
158
  - README.md
136
159
  - Rakefile
160
+ - app/assets/javascripts/angular.js
161
+ - app/assets/javascripts/controllers.js
162
+ - app/assets/javascripts/script.js
163
+ - app/views/layouts/application.html.erb
164
+ - app/views/schedule/index.html.erb
137
165
  - bin/schedulize
138
166
  - lib/assets/javascripts/blank.jpg
139
167
  - lib/assets/javascripts/justify_tweaks.js
@@ -151,7 +179,7 @@ files:
151
179
  - lib/z_time_label_day.rb
152
180
  - lib/z_time_label_hour.rb
153
181
  - scheduled_resource.gemspec
154
- homepage: ''
182
+ homepage: http://github.com/emeyekayee/scheduled_resource
155
183
  licenses:
156
184
  - MIT
157
185
  metadata: {}
@@ -174,5 +202,5 @@ rubyforge_project:
174
202
  rubygems_version: 2.2.2
175
203
  signing_key:
176
204
  specification_version: 4
177
- summary: Help display how something is used over time.
205
+ summary: Display how something is used over time.
178
206
  test_files: []