dao 5.3.3 → 5.4.0

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.
Files changed (8) hide show
  1. checksums.yaml +8 -8
  2. data/10.patch +316 -0
  3. data/README +107 -16
  4. data/dao.gemspec +3 -3
  5. data/lib/dao.rb +1 -1
  6. data/lib/dao/form.rb +5 -0
  7. metadata +3 -3
  8. data/a.rb +0 -8
checksums.yaml CHANGED
@@ -1,15 +1,15 @@
1
1
  ---
2
2
  !binary "U0hBMQ==":
3
3
  metadata.gz: !binary |-
4
- OTRlMDY3ZGVhYzRmY2RiNzY5NTM2OGI2NDFmZWI3ZDBjN2Y4NTVjMw==
4
+ MGZhZTE2YzNhMmEwMWIxMjBmZmNmMzFkNjliNjFjNzhmZWUwZTZkYg==
5
5
  data.tar.gz: !binary |-
6
- MjJlMGQwOWQ4OWRmMWJkMjYzMDlmZmFjOTU4MTMwYTRiNWIyNDJkMA==
6
+ MGVmMzI5ZmMxNWJiZDYyYTFhYmQxMThhMzRiMjEyY2NkZDRkMGNlNA==
7
7
  !binary "U0hBNTEy":
8
8
  metadata.gz: !binary |-
9
- YmZkNGI3MGY4MTcwNTM1ZWM1ZjA0MTQyY2Y2ZGE0M2M4NGVlOTY3YzdlNjAy
10
- ZGU0YzIwODM3M2RlZmUyNDU4NjllZTNjMGU4YTU1N2RmZWM4Njc0MWNmMmYx
11
- MWJmMjE4ZWJhMzk0MmY0MzU5ZDM1OWEzMDdiZDJhOTFjNTJiODg=
9
+ ZGY4Mzk2YWYwMWQyYWIyZDVmMzkxZWNjYzIyZmY2Y2FjNDk0YzM3MTQ2NGNj
10
+ ZGMwNzQwODUwOWQ5Y2RlMjYwODJjMDE4Njg4NmEyMjkxNDFmZjdlMzE0MWEw
11
+ MTUwN2I0ZWRkZmExNTI0YjU2MmQ5ZmNmMzhlMGVmMGIxMmZlM2U=
12
12
  data.tar.gz: !binary |-
13
- MGRhMTk2Mzg3YTg5Nzc1M2E4YjNmYjVlZTBhM2I3YWU0OTVkMGRkM2IzM2Zh
14
- YmFhMmJkNDhkNzkzMGE3ZGU0ZTMwYWZhNTUyZjU0M2NmOWQ1NGZkOGE4MmM1
15
- ZWQwZDg5YTg1NjA4M2IyYjFjZmRjNDgwMmYwNDc0YTQ3YjY3OWM=
13
+ Y2VmY2VmNGUyNjhjYjYyNGJkYzViNDgwNjdiODk0MzlhNzE2ZGRjZDE5ZjMy
14
+ ZWE0ODdiNWVhZDE3NjYzMmQ3NmY3NGY1N2ZkNTViYjVmZGJjYTE2YWUzZmEy
15
+ YzVkYWY5NzJkNDg1MDNiNTIxN2RkYThhNTY5Y2EwNjZiZjAyN2I=
@@ -0,0 +1,316 @@
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
data/README CHANGED
@@ -36,29 +36,120 @@ SYNOPSIS
36
36
  wikipedia has this to say about dao in general
37
37
 
38
38
  "
39
-
40
39
  In computer software, a data access object (DAO) is an object that
41
- provides an abstract interface to some type of database or persistence
42
- mechanism, providing some specific operations without exposing details
43
- of the database. It provides a mapping from application calls to the
44
- persistence layer. This isolation separates the concerns of what data
45
- accesses the application needs, in terms of domain-specific objects and
46
- data types (the public interface of the DAO), and how these needs can be
47
- satisfied with a specific DBMS, database schema, etc. (the
48
- implementation of the DAO).
49
-
50
- "
40
+ provides an abstract interface to some type of database or other
41
+ persistence mechanism. By mapping application calls to the persistence
42
+ layer, DAOs provide some specific data operations without exposing
43
+ details of the database. This isolation supports the single
44
+ responsibility principle. It separates what data accesses the
45
+ application needs, in terms of domain-specific objects and data types
46
+ (the public interface of the DAO), from how these needs can be satisfied
47
+ with a specific DBMS, database schema, etc. (the implementation of the
48
+ DAO).
49
+ "
51
50
  - http://en.wikipedia.org/wiki/Data_access_object
52
51
 
53
- and
52
+ and this to say about the single responsibility principle
53
+
54
+ "
55
+ In object-oriented programming, the single responsibility principle
56
+ states that every class should have a single responsibility, and that
57
+ responsibility should be entirely encapsulated by the class. All its
58
+ services should be narrowly aligned with that responsibility.
59
+
60
+ Responsibility [is defined] as a reason to change, and [single
61
+ responsibility means] that a class or module should have one, and only
62
+ one, reason to change. As an example, consider a module that compiles and
63
+ prints a report. Such a module can be changed for two reasons. First,
64
+ the content of the report can change. Second, the format of the report
65
+ can change. These two things change for very different causes; one
66
+ substantive, and one cosmetic. The single responsibility principle says
67
+ that these two aspects of the problem are really two separate
68
+ responsibilities, and should therefore be in separate classes or
69
+ modules. It would be a bad design to couple two things that change for
70
+ different reasons at different times.
71
+ "
72
+ - http://en.wikipedia.org/wiki/Single_responsibility_principle
73
+
74
+ even though rails is the sweet, its ActiveRecord class violates (or, at
75
+ least, encourages a programmer to violate) the single responsibility
76
+ principle
77
+
78
+ this leads to obvious problems
79
+
80
+ "
81
+ Jim Weirich, at the end of his SOLID Ruby Talk at the 2009 Ruby
82
+ Conference, asks the audience: "ActiveRecord objects implement a domain
83
+ concept and a persistence concept. Does this violate the SRP (Single
84
+ Responsibility Principle)?" The audience agrees that it does violate the
85
+ SRP. Jim asks if this bothers them. Many members of the audience say
86
+ yes. Why? It makes testing harder. It makes the persistence object a lot
87
+ heavier.
88
+ "
89
+ - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles#comment293734_119352
90
+
91
+ and subtle yet sweeping consequences (as described by uncle bob)
92
+
93
+ "
94
+ The problem I have with ActiveRecord is that it creates confusion about
95
+ ... two very different styles of programming. A database table is a
96
+ data structure. It has exposed data and no behavior. But an ActiveRecord
97
+ appears to be an object. It has “hidden” data, and exposed behavior. I
98
+ put the word “hidden” in quotes because the data is, in fact, not
99
+ hidden. Almost all ActiveRecord derivatives export the database columns
100
+ through accessors and mutators. Indeed, the Active Record is meant to be
101
+ used like a data structure.
102
+
103
+ On the other hand, many people put business rule methods in their
104
+ ActiveRecord classes; which makes them appear to be objects. This leads
105
+ to a dilemma. On which side of the line does the Active Record really
106
+ fall? Is it an object? Or is it a data structure?
107
+
108
+ This dilemma is the basis for the oft-cited impedance mismatch between
109
+ relational databases and object oriented languages. Tables are data
110
+ structures, not classes. Objects are encapsulated behavior, not database
111
+ rows.
112
+
113
+ ...
114
+
115
+ The problem is that Active Records are data structures. Putting business
116
+ rule methods in them doesn’t turn them into true objects. In the end,
117
+ the algorithms that employ ActiveRecords are vulnerable to changes in
118
+ schema, and changes in type. They are not immune to changes in type, the
119
+ way algorithms that use objects are.
120
+
121
+ ...
122
+
123
+ So applications built around ActiveRecord are applications built around
124
+ data structures. And applications that are built around data structures
125
+ are procedural—they are not object oriented. The opportunity we miss
126
+ when we structure our applications around ActiveRecord is the
127
+ opportunity to use object oriented design.
128
+ "
129
+ - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
130
+
131
+ and a clear solution (again, uncle bob)
54
132
 
55
133
  "
56
- Models are not data access objects...
134
+ I am not recommending against the use of ActiveRecord. I think the
135
+ pattern is very useful. What I am advocating is a separation between the
136
+ application and ActiveRecord.
137
+
138
+ ActiveRecord belongs in the layer that separates the database from the
139
+ application. It makes a very convenient halfway-house between the hard
140
+ data structures of database tables, and the behavior exposing objects in
141
+ the application.
142
+
143
+ Applications should be designed and structured around objects, not data
144
+ structures. Those objects should expose business behaviors, and hide any
145
+ vestige of the database.
57
146
  "
147
+ - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
148
+
149
+ welcome to the dao
58
150
 
59
- - http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
60
151
 
61
- DESCRITPION
152
+ DESCRIPTION
62
153
 
63
154
  API
64
155
  applications that are written on dao look like this in ruby
@@ -134,7 +225,7 @@ DESCRITPION
134
225
  - forms and interfaces that involve dozens of models are as easy to deal
135
226
  with as simple ones.
136
227
 
137
- - code can be optimized at the interface
228
+ - code can be optimized at the interface.
138
229
 
139
230
  READING
140
231
  http://blog.plataformatec.com.br/2012/03/barebone-models-to-use-with-actionpack-in-rails-4-0/
@@ -3,18 +3,18 @@
3
3
 
4
4
  Gem::Specification::new do |spec|
5
5
  spec.name = "dao"
6
- spec.version = "5.3.3"
6
+ spec.version = "5.4.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
- ["Gemfile",
13
+ ["10.patch",
14
+ "Gemfile",
14
15
  "Gemfile.lock",
15
16
  "README",
16
17
  "Rakefile",
17
- "a.rb",
18
18
  "dao.gemspec",
19
19
  "lib",
20
20
  "lib/dao",
data/lib/dao.rb CHANGED
@@ -11,7 +11,7 @@
11
11
  # dao libs
12
12
  #
13
13
  module Dao
14
- Version = '5.3.3' unless defined?(Version)
14
+ Version = '5.4.0' unless defined?(Version)
15
15
 
16
16
  def version
17
17
  Dao::Version
@@ -387,6 +387,7 @@ module Dao
387
387
  end
388
388
 
389
389
  if options[:multiple]
390
+ name = name.to_s
390
391
  name += '[]'
391
392
  end
392
393
 
@@ -658,5 +659,9 @@ module Dao
658
659
  string = string.titleize if string.respond_to?(:titleize)
659
660
  string
660
661
  end
662
+
663
+ def capture(*args, &block)
664
+ tagz(*args, &block)
665
+ end
661
666
  end
662
667
  end
metadata CHANGED
@@ -1,14 +1,14 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: dao
3
3
  version: !ruby/object:Gem::Version
4
- version: 5.3.3
4
+ version: 5.4.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: 2014-02-22 00:00:00.000000000 Z
11
+ date: 2015-03-03 00:00:00.000000000 Z
12
12
  dependencies:
13
13
  - !ruby/object:Gem::Dependency
14
14
  name: rails
@@ -156,11 +156,11 @@ executables: []
156
156
  extensions: []
157
157
  extra_rdoc_files: []
158
158
  files:
159
+ - 10.patch
159
160
  - Gemfile
160
161
  - Gemfile.lock
161
162
  - README
162
163
  - Rakefile
163
- - a.rb
164
164
  - dao.gemspec
165
165
  - lib/dao.rb
166
166
  - lib/dao/active_record.rb
data/a.rb DELETED
@@ -1,8 +0,0 @@
1
-
2
- f = Dao::Form.new
3
-
4
- f.scope_for(:foo) do
5
- p f.name_for(:bar)
6
- p f.key_for(:bar)
7
- end
8
-