dao 5.4.0 → 5.5.0

Sign up to get free protection for your applications and to get access to all the features.
Files changed (6) hide show
  1. checksums.yaml +8 -8
  2. data/dao.gemspec +3 -4
  3. data/lib/dao.rb +2 -2
  4. data/lib/dao/form.rb +2 -0
  5. metadata +4 -5
  6. data/10.patch +0 -316
checksums.yaml CHANGED
@@ -1,15 +1,15 @@
1
1
  ---
2
2
  !binary "U0hBMQ==":
3
3
  metadata.gz: !binary |-
4
- MGZhZTE2YzNhMmEwMWIxMjBmZmNmMzFkNjliNjFjNzhmZWUwZTZkYg==
4
+ ODJiYmNmMGY2MDdkYjM1MThiOTUyOGFkMzc5ZDkwMTNhYjA1YjNhYw==
5
5
  data.tar.gz: !binary |-
6
- MGVmMzI5ZmMxNWJiZDYyYTFhYmQxMThhMzRiMjEyY2NkZDRkMGNlNA==
6
+ YzRmOWI5Y2ViYjM0NjM5MWFiMDYzZjFhMjEwYjNkMjJkMTJlNmY1Mw==
7
7
  !binary "U0hBNTEy":
8
8
  metadata.gz: !binary |-
9
- ZGY4Mzk2YWYwMWQyYWIyZDVmMzkxZWNjYzIyZmY2Y2FjNDk0YzM3MTQ2NGNj
10
- ZGMwNzQwODUwOWQ5Y2RlMjYwODJjMDE4Njg4NmEyMjkxNDFmZjdlMzE0MWEw
11
- MTUwN2I0ZWRkZmExNTI0YjU2MmQ5ZmNmMzhlMGVmMGIxMmZlM2U=
9
+ YzU1M2Y0NWM5MGU2OWI0NTU5MGFlOGQzZWI0MjRkNzEwZTllZGRmMDJkOGNk
10
+ ZjhlNjAzZjc4OWFmM2M5YjhmMTNlNWVhMWMxNWFhOTgwZTQ4MDdlYTg1MGY0
11
+ YmY5NWI5N2E0NjYzZmM4NjA5ZDYwNWYyYmI5Zjk4NWJiZTNiOTg=
12
12
  data.tar.gz: !binary |-
13
- Y2VmY2VmNGUyNjhjYjYyNGJkYzViNDgwNjdiODk0MzlhNzE2ZGRjZDE5ZjMy
14
- ZWE0ODdiNWVhZDE3NjYzMmQ3NmY3NGY1N2ZkNTViYjVmZGJjYTE2YWUzZmEy
15
- YzVkYWY5NzJkNDg1MDNiNTIxN2RkYThhNTY5Y2EwNjZiZjAyN2I=
13
+ YTc5NDY5OTBlYjA1MWRjZjA3MjI5MzliOTlhNzQ1MTljZjc3NGJiMjFhY2Y0
14
+ ZjJjYmQxN2RmZmViMDEzMjlhOWE5ZDEwODVlOTUwMmUwMGE3ZWZiMzEwZDkw
15
+ ZjdlNGFkMjJmN2JmZWZhZTg0N2U1ZDUyMWEwMGY4ZDJmMDJlYjg=
@@ -3,15 +3,14 @@
3
3
 
4
4
  Gem::Specification::new do |spec|
5
5
  spec.name = "dao"
6
- spec.version = "5.4.0"
6
+ spec.version = "5.5.0"
7
7
  spec.platform = Gem::Platform::RUBY
8
8
  spec.summary = "dao"
9
9
  spec.description = "presenter, conducer, api, and better form objects for you rails' pleasure"
10
10
  spec.license = "same as ruby's"
11
11
 
12
12
  spec.files =
13
- ["10.patch",
14
- "Gemfile",
13
+ ["Gemfile",
15
14
  "Gemfile.lock",
16
15
  "README",
17
16
  "Rakefile",
@@ -107,7 +106,7 @@ Gem::Specification::new do |spec|
107
106
  spec.test_files = nil
108
107
 
109
108
 
110
- spec.add_dependency(*["rails", " >= 3.1"])
109
+ spec.add_dependency(*["rails", " ~> 3.1"])
111
110
 
112
111
  spec.add_dependency(*["map", " >= 6.0.0"])
113
112
 
data/lib/dao.rb CHANGED
@@ -11,7 +11,7 @@
11
11
  # dao libs
12
12
  #
13
13
  module Dao
14
- Version = '5.4.0' unless defined?(Version)
14
+ Version = '5.5.0' unless defined?(Version)
15
15
 
16
16
  def version
17
17
  Dao::Version
@@ -19,7 +19,7 @@
19
19
 
20
20
  def dependencies
21
21
  {
22
- 'rails' => [ 'rails' , ' >= 3.1' ] ,
22
+ 'rails' => [ 'rails' , ' ~> 3.1' ] ,
23
23
  'map' => [ 'map' , ' >= 6.0.0' ] ,
24
24
  'fattr' => [ 'fattr' , ' >= 2.2' ] ,
25
25
  'coerce' => [ 'coerce' , ' >= 0.0.3' ] ,
@@ -470,6 +470,8 @@ module Dao
470
470
 
471
471
  option_(opts){ content }
472
472
  end
473
+ else
474
+ ' '
473
475
  end
474
476
  }
475
477
  end
metadata CHANGED
@@ -1,27 +1,27 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: dao
3
3
  version: !ruby/object:Gem::Version
4
- version: 5.4.0
4
+ version: 5.5.0
5
5
  platform: ruby
6
6
  authors:
7
7
  - Ara T. Howard
8
8
  autorequire:
9
9
  bindir: bin
10
10
  cert_chain: []
11
- date: 2015-03-03 00:00:00.000000000 Z
11
+ date: 2015-04-24 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
19
  version: '3.1'
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
26
  version: '3.1'
27
27
  - !ruby/object:Gem::Dependency
@@ -156,7 +156,6 @@ executables: []
156
156
  extensions: []
157
157
  extra_rdoc_files: []
158
158
  files:
159
- - 10.patch
160
159
  - Gemfile
161
160
  - Gemfile.lock
162
161
  - README
data/10.patch DELETED
@@ -1,316 +0,0 @@
1
- From e8155d4abba61db094defcf1c6dc0c42d7f4f26c Mon Sep 17 00:00:00 2001
2
- From: Kerry Ivan Kurian <kerry@dojo4.com>
3
- Date: Sun, 13 Oct 2013 13:13:16 -0600
4
- Subject: [PATCH 1/4] update teh readme
5
-
6
- ---
7
- README | 84 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------
8
- 1 file changed, 71 insertions(+), 13 deletions(-)
9
-
10
- diff --git a/README b/README
11
- index 6d72aa7..cc0ca30 100644
12
- --- a/README
13
- +++ b/README
14
- @@ -38,25 +38,83 @@ SYNOPSIS
15
- "
16
-
17
- In computer software, a data access object (DAO) is an object that
18
- - provides an abstract interface to some type of database or persistence
19
- - mechanism, providing some specific operations without exposing details
20
- - of the database. It provides a mapping from application calls to the
21
- - persistence layer. This isolation separates the concerns of what data
22
- - accesses the application needs, in terms of domain-specific objects and
23
- - data types (the public interface of the DAO), and how these needs can be
24
- - satisfied with a specific DBMS, database schema, etc. (the
25
- - implementation of the DAO).
26
- -
27
- - "
28
- + provides an abstract interface to some type of database or other
29
- + persistence mechanism. By mapping application calls to the persistence
30
- + layer, DAOs provide some specific data operations without exposing
31
- + details of the database. This isolation supports the single
32
- + responsibility principle. It separates what data accesses the
33
- + application needs, in terms of domain-specific objects and data types
34
- + (the public interface of the DAO), from how these needs can be satisfied
35
- + with a specific DBMS, database schema, etc. (the implementation of the
36
- + DAO).
37
- +
38
- + "
39
- - http://en.wikipedia.org/wiki/Data_access_object
40
-
41
- + and this to say about the single responsibility principle
42
- +
43
- + "
44
- +
45
- + In object-oriented programming, the single responsibility principle
46
- + states that every class should have a single responsibility, and that
47
- + responsibility should be entirely encapsulated by the class. All its
48
- + services should be narrowly aligned with that responsibility.
49
- +
50
- + Responsibility [is defined] as a reason to change, and [single
51
- + responsibility means] that a class or module should have one, and only
52
- + one, reason to change. As an example, consider a module that compiles and
53
- + prints a report. Such a module can be changed for two reasons. First,
54
- + the content of the report can change. Second, the format of the report
55
- + can change. These two things change for very different causes; one
56
- + substantive, and one cosmetic. The single responsibility principle says
57
- + that these two aspects of the problem are really two separate
58
- + responsibilities, and should therefore be in separate classes or
59
- + modules. It would be a bad design to couple two things that change for
60
- + different reasons at different times.
61
- +
62
- + "
63
- +
64
- + - http://en.wikipedia.org/wiki/Single_responsibility_principle
65
- +
66
- + even though rails is the sweet, its ActiveRecord class violates (or, at
67
- + least, encourages a programmer to violate) the single responsibility
68
- + principle. uncle bob sums it up this way
69
- +
70
- + "
71
- +
72
- + The problem I have with ActiveRecord is that it creates confusion about
73
- + these two very different styles of programming. A database table is a
74
- + data structure. It has exposed data and no behavior. But an ActiveRecord
75
- + appears to be an object. It has “hidden” data, and exposed behavior. I
76
- + put the word “hidden” in quotes because the data is, in fact, not
77
- + hidden. Almost all ActiveRecord derivatives export the database columns
78
- + through accessors and mutators. Indeed, the Active Record is meant to be
79
- + used like a data structure.
80
- +
81
- + On the other hand, many people put business rule methods in their
82
- + ActiveRecord classes; which makes them appear to be objects. This leads
83
- + to a dilemma. On which side of the line does the Active Record really
84
- + fall? Is it an object? Or is it a data structure?
85
- +
86
- + "
87
- +
88
- + - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles?answertab=oldest#tab-top
89
- +
90
- and
91
-
92
- "
93
- - Models are not data access objects...
94
- +
95
- + Jim Weirich, at the end of his SOLID Ruby Talk at the 2009 Ruby
96
- + Conference, asks the audience: "ActiveRecord objects implement a domain
97
- + concept and a persistence concept. Does this violate the SRP (Single
98
- + Responsibility Principle)?" The audience agrees that it does violate the
99
- + SRP. Jim asks if this bothers them. Many members of the audience say
100
- + yes. Why? It makes testing harder. It makes the persistence object a lot
101
- + heavier.
102
- +
103
- "
104
-
105
- - - http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
106
- + - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles#comment293734_119352
107
-
108
- DESCRITPION
109
-
110
- @@ -134,7 +192,7 @@ DESCRITPION
111
- - forms and interfaces that involve dozens of models are as easy to deal
112
- with as simple ones.
113
-
114
- - - code can be optimized at the interface
115
- + - code can be optimized at the interface.
116
-
117
- READING
118
- http://blog.plataformatec.com.br/2012/03/barebone-models-to-use-with-actionpack-in-rails-4-0/
119
-
120
- From 07e3bc0733cc9e49c6e2f077a993bb85963da91b Mon Sep 17 00:00:00 2001
121
- From: Kerry Ivan Kurian <kerry@dojo4.com>
122
- Date: Sun, 13 Oct 2013 13:46:47 -0600
123
- Subject: [PATCH 2/4] mo betta problem/solution background/motivation
124
-
125
- ---
126
- README | 69 +++++++++++++++++++++++++++++++++++++++++++++++++-----------------
127
- 1 file changed, 51 insertions(+), 18 deletions(-)
128
-
129
- diff --git a/README b/README
130
- index cc0ca30..0fcddf9 100644
131
- --- a/README
132
- +++ b/README
133
- @@ -36,7 +36,6 @@ SYNOPSIS
134
- wikipedia has this to say about dao in general
135
-
136
- "
137
- -
138
- In computer software, a data access object (DAO) is an object that
139
- provides an abstract interface to some type of database or other
140
- persistence mechanism. By mapping application calls to the persistence
141
- @@ -47,14 +46,12 @@ SYNOPSIS
142
- (the public interface of the DAO), from how these needs can be satisfied
143
- with a specific DBMS, database schema, etc. (the implementation of the
144
- DAO).
145
- -
146
- "
147
- - http://en.wikipedia.org/wiki/Data_access_object
148
-
149
- and this to say about the single responsibility principle
150
-
151
- "
152
- -
153
- In object-oriented programming, the single responsibility principle
154
- states that every class should have a single responsibility, and that
155
- responsibility should be entirely encapsulated by the class. All its
156
- @@ -71,19 +68,31 @@ SYNOPSIS
157
- responsibilities, and should therefore be in separate classes or
158
- modules. It would be a bad design to couple two things that change for
159
- different reasons at different times.
160
- -
161
- "
162
- -
163
- - http://en.wikipedia.org/wiki/Single_responsibility_principle
164
-
165
- even though rails is the sweet, its ActiveRecord class violates (or, at
166
- least, encourages a programmer to violate) the single responsibility
167
- - principle. uncle bob sums it up this way
168
- + principle
169
- +
170
- + this leads to obvious problems
171
-
172
- "
173
- + Jim Weirich, at the end of his SOLID Ruby Talk at the 2009 Ruby
174
- + Conference, asks the audience: "ActiveRecord objects implement a domain
175
- + concept and a persistence concept. Does this violate the SRP (Single
176
- + Responsibility Principle)?" The audience agrees that it does violate the
177
- + SRP. Jim asks if this bothers them. Many members of the audience say
178
- + yes. Why? It makes testing harder. It makes the persistence object a lot
179
- + heavier.
180
- + "
181
- + - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles#comment293734_119352
182
-
183
- + and subtle yet sweeping consequences (as described by uncle bob)
184
- +
185
- + "
186
- The problem I have with ActiveRecord is that it creates confusion about
187
- - these two very different styles of programming. A database table is a
188
- + ... two very different styles of programming. A database table is a
189
- data structure. It has exposed data and no behavior. But an ActiveRecord
190
- appears to be an object. It has “hidden” data, and exposed behavior. I
191
- put the word “hidden” in quotes because the data is, in fact, not
192
- @@ -96,25 +105,49 @@ SYNOPSIS
193
- to a dilemma. On which side of the line does the Active Record really
194
- fall? Is it an object? Or is it a data structure?
195
-
196
- - "
197
- + This dilemma is the basis for the oft-cited impedance mismatch between
198
- + relational databases and object oriented languages. Tables are data
199
- + structures, not classes. Objects are encapsulated behavior, not database
200
- + rows.
201
- +
202
- + ...
203
-
204
- - - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles?answertab=oldest#tab-top
205
- + The problem is that Active Records are data structures. Putting business
206
- + rule methods in them doesn’t turn them into true objects. In the end,
207
- + the algorithms that employ ActiveRecords are vulnerable to changes in
208
- + schema, and changes in type. They are not immune to changes in type, the
209
- + way algorithms that use objects are.
210
-
211
- - and
212
- + ...
213
-
214
- + So applications built around ActiveRecord are applications built around
215
- + data structures. And applications that are built around data structures
216
- + are procedural—they are not object oriented. The opportunity we miss
217
- + when we structure our applications around ActiveRecord is the
218
- + opportunity to use object oriented design.
219
- "
220
- + - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
221
-
222
- - Jim Weirich, at the end of his SOLID Ruby Talk at the 2009 Ruby
223
- - Conference, asks the audience: "ActiveRecord objects implement a domain
224
- - concept and a persistence concept. Does this violate the SRP (Single
225
- - Responsibility Principle)?" The audience agrees that it does violate the
226
- - SRP. Jim asks if this bothers them. Many members of the audience say
227
- - yes. Why? It makes testing harder. It makes the persistence object a lot
228
- - heavier.
229
- + and a clear solution (again, uncle bob -- emphasis added)
230
-
231
- "
232
- + I am not recommending against the use of ActiveRecord. I think the
233
- + pattern is very useful. **What I am advocating is a separation between the
234
- + application and ActiveRecord.**
235
- +
236
- + ActiveRecord belongs in the layer that separates the database from the
237
- + application. It makes a very convenient halfway-house between the hard
238
- + data structures of database tables, and the behavior exposing objects in
239
- + the application.
240
- +
241
- + **Applications should be designed and structured around objects, not data
242
- + structures. Those objects should expose business behaviors, and hide any
243
- + vestige of the database.**
244
- + "
245
- + - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
246
- +
247
- + welcome to the dao
248
-
249
- - - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles#comment293734_119352
250
-
251
- DESCRITPION
252
-
253
-
254
- From 16acaf4c5c1f3508b076b61d466dcb49ebf8b7fa Mon Sep 17 00:00:00 2001
255
- From: Kerry Ivan Kurian <kerry@dojo4.com>
256
- Date: Sun, 13 Oct 2013 13:48:42 -0600
257
- Subject: [PATCH 3/4] no markdown, no emphasis
258
-
259
- ---
260
- README | 10 +++++-----
261
- 1 file changed, 5 insertions(+), 5 deletions(-)
262
-
263
- diff --git a/README b/README
264
- index 0fcddf9..a24e620 100644
265
- --- a/README
266
- +++ b/README
267
- @@ -128,21 +128,21 @@ SYNOPSIS
268
- "
269
- - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
270
-
271
- - and a clear solution (again, uncle bob -- emphasis added)
272
- + and a clear solution (again, uncle bob)
273
-
274
- "
275
- I am not recommending against the use of ActiveRecord. I think the
276
- - pattern is very useful. **What I am advocating is a separation between the
277
- - application and ActiveRecord.**
278
- + pattern is very useful. What I am advocating is a separation between the
279
- + application and ActiveRecord.
280
-
281
- ActiveRecord belongs in the layer that separates the database from the
282
- application. It makes a very convenient halfway-house between the hard
283
- data structures of database tables, and the behavior exposing objects in
284
- the application.
285
-
286
- - **Applications should be designed and structured around objects, not data
287
- + Applications should be designed and structured around objects, not data
288
- structures. Those objects should expose business behaviors, and hide any
289
- - vestige of the database.**
290
- + vestige of the database.
291
- "
292
- - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
293
-
294
-
295
- From 4614426f7fc66c97850359b2b3153771065d41ef Mon Sep 17 00:00:00 2001
296
- From: Kerry Ivan Kurian <kerry@dojo4.com>
297
- Date: Sun, 13 Oct 2013 13:51:05 -0600
298
- Subject: [PATCH 4/4] spell bettah
299
-
300
- ---
301
- README | 2 +-
302
- 1 file changed, 1 insertion(+), 1 deletion(-)
303
-
304
- diff --git a/README b/README
305
- index a24e620..b56999b 100644
306
- --- a/README
307
- +++ b/README
308
- @@ -149,7 +149,7 @@ SYNOPSIS
309
- welcome to the dao
310
-
311
-
312
- -DESCRITPION
313
- +DESCRIPTION
314
-
315
- API
316
- applications that are written on dao look like this in ruby