dao 5.3.3 → 5.4.0

checksums.yaml

@@ -1,15 +1,15 @@
 ---
 !binary "U0hBMQ==":
   metadata.gz: !binary |-
-    OTRlMDY3ZGVhYzRmY2RiNzY5NTM2OGI2NDFmZWI3ZDBjN2Y4NTVjMw==
+    MGZhZTE2YzNhMmEwMWIxMjBmZmNmMzFkNjliNjFjNzhmZWUwZTZkYg==
   data.tar.gz: !binary |-
-    MjJlMGQwOWQ4OWRmMWJkMjYzMDlmZmFjOTU4MTMwYTRiNWIyNDJkMA==
+    MGVmMzI5ZmMxNWJiZDYyYTFhYmQxMThhMzRiMjEyY2NkZDRkMGNlNA==
 !binary "U0hBNTEy":
   metadata.gz: !binary |-
-    YmZkNGI3MGY4MTcwNTM1ZWM1ZjA0MTQyY2Y2ZGE0M2M4NGVlOTY3YzdlNjAy
-    ZGU0YzIwODM3M2RlZmUyNDU4NjllZTNjMGU4YTU1N2RmZWM4Njc0MWNmMmYx
-    MWJmMjE4ZWJhMzk0MmY0MzU5ZDM1OWEzMDdiZDJhOTFjNTJiODg=
+    ZGY4Mzk2YWYwMWQyYWIyZDVmMzkxZWNjYzIyZmY2Y2FjNDk0YzM3MTQ2NGNj
+    ZGMwNzQwODUwOWQ5Y2RlMjYwODJjMDE4Njg4NmEyMjkxNDFmZjdlMzE0MWEw
+    MTUwN2I0ZWRkZmExNTI0YjU2MmQ5ZmNmMzhlMGVmMGIxMmZlM2U=
   data.tar.gz: !binary |-
-    MGRhMTk2Mzg3YTg5Nzc1M2E4YjNmYjVlZTBhM2I3YWU0OTVkMGRkM2IzM2Zh
-    YmFhMmJkNDhkNzkzMGE3ZGU0ZTMwYWZhNTUyZjU0M2NmOWQ1NGZkOGE4MmM1
-    ZWQwZDg5YTg1NjA4M2IyYjFjZmRjNDgwMmYwNDc0YTQ3YjY3OWM=
+    Y2VmY2VmNGUyNjhjYjYyNGJkYzViNDgwNjdiODk0MzlhNzE2ZGRjZDE5ZjMy
+    ZWE0ODdiNWVhZDE3NjYzMmQ3NmY3NGY1N2ZkNTViYjVmZGJjYTE2YWUzZmEy
+    YzVkYWY5NzJkNDg1MDNiNTIxN2RkYThhNTY5Y2EwNjZiZjAyN2I=

data/10.patch

@@ -0,0 +1,316 @@
+From e8155d4abba61db094defcf1c6dc0c42d7f4f26c Mon Sep 17 00:00:00 2001
+From: Kerry Ivan Kurian <kerry@dojo4.com>
+Date: Sun, 13 Oct 2013 13:13:16 -0600
+Subject: [PATCH 1/4] update teh readme
+
+---
+ README | 84 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------
+ 1 file changed, 71 insertions(+), 13 deletions(-)
+
+diff --git a/README b/README
+index 6d72aa7..cc0ca30 100644
+--- a/README
++++ b/README
+@@ -38,25 +38,83 @@ SYNOPSIS
+     "
+ 
+       In computer software, a data access object (DAO) is an object that
+-      provides an abstract interface to some type of database or persistence
+-      mechanism, providing some specific operations without exposing details
+-      of the database.  It provides a mapping from application calls to the
+-      persistence layer. This isolation separates the concerns of what data
+-      accesses the application needs, in terms of domain-specific objects and
+-      data types (the public interface of the DAO), and how these needs can be
+-      satisfied with a specific DBMS, database schema, etc. (the
+-      implementation of the DAO).
+-
+-    " 
++      provides an abstract interface to some type of database or other
++      persistence mechanism. By mapping application calls to the persistence
++      layer, DAOs provide some specific data operations without exposing
++      details of the database. This isolation supports the single
++      responsibility principle. It separates what data accesses the
++      application needs, in terms of domain-specific objects and data types
++      (the public interface of the DAO), from how these needs can be satisfied
++      with a specific DBMS, database schema, etc. (the implementation of the
++      DAO).
++
++    "
+       - http://en.wikipedia.org/wiki/Data_access_object
+ 
++  and this to say about the single responsibility principle
++
++    "
++
++      In object-oriented programming, the single responsibility principle
++      states that every class should have a single responsibility, and that
++      responsibility should be entirely encapsulated by the class. All its
++      services should be narrowly aligned with that responsibility.
++
++      Responsibility [is defined] as a reason to change, and [single
++      responsibility means] that a class or module should have one, and only
++      one, reason to change. As an example, consider a module that compiles and
++      prints a report. Such a module can be changed for two reasons. First,
++      the content of the report can change. Second, the format of the report
++      can change. These two things change for very different causes; one
++      substantive, and one cosmetic. The single responsibility principle says
++      that these two aspects of the problem are really two separate
++      responsibilities, and should therefore be in separate classes or
++      modules. It would be a bad design to couple two things that change for
++      different reasons at different times.
++
++    "
++
++      - http://en.wikipedia.org/wiki/Single_responsibility_principle
++
++  even though rails is the sweet, its ActiveRecord class violates (or, at
++  least, encourages a programmer to violate) the single responsibility
++  principle. uncle bob sums it up this way
++
++    "
++
++      The problem I have with ActiveRecord is that it creates confusion about
++      these two very different styles of programming. A database table is a
++      data structure. It has exposed data and no behavior. But an ActiveRecord
++      appears to be an object. It has “hidden” data, and exposed behavior. I
++      put the word “hidden” in quotes because the data is, in fact, not
++      hidden. Almost all ActiveRecord derivatives export the database columns
++      through accessors and mutators. Indeed, the Active Record is meant to be
++      used like a data structure.
++
++      On the other hand, many people put business rule methods in their
++      ActiveRecord classes; which makes them appear to be objects. This leads
++      to a dilemma. On which side of the line does the Active Record really
++      fall? Is it an object? Or is it a data structure?
++
++    "
++
++      - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles?answertab=oldest#tab-top
++
+   and
+ 
+     "
+-      Models are not data access objects...
++
++      Jim Weirich, at the end of his SOLID Ruby Talk at the 2009 Ruby
++      Conference, asks the audience: "ActiveRecord objects implement a domain
++      concept and a persistence concept. Does this violate the SRP (Single
++      Responsibility Principle)?" The audience agrees that it does violate the
++      SRP. Jim asks if this bothers them. Many members of the audience say
++      yes. Why? It makes testing harder. It makes the persistence object a lot
++      heavier.
++
+     "
+ 
+-      - http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
++      - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles#comment293734_119352
+ 
+ DESCRITPION
+ 
+@@ -134,7 +192,7 @@ DESCRITPION
+       - forms and interfaces that involve dozens of models are as easy to deal
+         with as simple ones.
+ 
+-      - code can be optimized at the interface
++      - code can be optimized at the interface.
+ 
+ READING
+   http://blog.plataformatec.com.br/2012/03/barebone-models-to-use-with-actionpack-in-rails-4-0/
+
+From 07e3bc0733cc9e49c6e2f077a993bb85963da91b Mon Sep 17 00:00:00 2001
+From: Kerry Ivan Kurian <kerry@dojo4.com>
+Date: Sun, 13 Oct 2013 13:46:47 -0600
+Subject: [PATCH 2/4] mo betta problem/solution background/motivation
+
+---
+ README | 69 +++++++++++++++++++++++++++++++++++++++++++++++++-----------------
+ 1 file changed, 51 insertions(+), 18 deletions(-)
+
+diff --git a/README b/README
+index cc0ca30..0fcddf9 100644
+--- a/README
++++ b/README
+@@ -36,7 +36,6 @@ SYNOPSIS
+   wikipedia has this to say about dao in general
+ 
+     "
+-
+       In computer software, a data access object (DAO) is an object that
+       provides an abstract interface to some type of database or other
+       persistence mechanism. By mapping application calls to the persistence
+@@ -47,14 +46,12 @@ SYNOPSIS
+       (the public interface of the DAO), from how these needs can be satisfied
+       with a specific DBMS, database schema, etc. (the implementation of the
+       DAO).
+-
+     "
+       - http://en.wikipedia.org/wiki/Data_access_object
+ 
+   and this to say about the single responsibility principle
+ 
+     "
+-
+       In object-oriented programming, the single responsibility principle
+       states that every class should have a single responsibility, and that
+       responsibility should be entirely encapsulated by the class. All its
+@@ -71,19 +68,31 @@ SYNOPSIS
+       responsibilities, and should therefore be in separate classes or
+       modules. It would be a bad design to couple two things that change for
+       different reasons at different times.
+-
+     "
+-
+       - http://en.wikipedia.org/wiki/Single_responsibility_principle
+ 
+   even though rails is the sweet, its ActiveRecord class violates (or, at
+   least, encourages a programmer to violate) the single responsibility
+-  principle. uncle bob sums it up this way
++  principle
++
++  this leads to obvious problems
+ 
+     "
++      Jim Weirich, at the end of his SOLID Ruby Talk at the 2009 Ruby
++      Conference, asks the audience: "ActiveRecord objects implement a domain
++      concept and a persistence concept. Does this violate the SRP (Single
++      Responsibility Principle)?" The audience agrees that it does violate the
++      SRP. Jim asks if this bothers them. Many members of the audience say
++      yes. Why? It makes testing harder. It makes the persistence object a lot
++      heavier.
++    "
++      - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles#comment293734_119352
+ 
++  and subtle yet sweeping consequences (as described by uncle bob)
++
++    "
+       The problem I have with ActiveRecord is that it creates confusion about
+-      these two very different styles of programming. A database table is a
++      ... two very different styles of programming. A database table is a
+       data structure. It has exposed data and no behavior. But an ActiveRecord
+       appears to be an object. It has “hidden” data, and exposed behavior. I
+       put the word “hidden” in quotes because the data is, in fact, not
+@@ -96,25 +105,49 @@ SYNOPSIS
+       to a dilemma. On which side of the line does the Active Record really
+       fall? Is it an object? Or is it a data structure?
+ 
+-    "
++      This dilemma is the basis for the oft-cited impedance mismatch between
++      relational databases and object oriented languages. Tables are data
++      structures, not classes. Objects are encapsulated behavior, not database
++      rows.
++
++      ...
+ 
+-      - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles?answertab=oldest#tab-top
++      The problem is that Active Records are data structures. Putting business
++      rule methods in them doesn’t turn them into true objects. In the end,
++      the algorithms that employ ActiveRecords are vulnerable to changes in
++      schema, and changes in type. They are not immune to changes in type, the
++      way algorithms that use objects are.
+ 
+-  and
++      ...
+ 
++      So applications built around ActiveRecord are applications built around
++      data structures. And applications that are built around data structures
++      are procedural—they are not object oriented. The opportunity we miss
++      when we structure our applications around ActiveRecord is the
++      opportunity to use object oriented design.
+     "
++      - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
+ 
+-      Jim Weirich, at the end of his SOLID Ruby Talk at the 2009 Ruby
+-      Conference, asks the audience: "ActiveRecord objects implement a domain
+-      concept and a persistence concept. Does this violate the SRP (Single
+-      Responsibility Principle)?" The audience agrees that it does violate the
+-      SRP. Jim asks if this bothers them. Many members of the audience say
+-      yes. Why? It makes testing harder. It makes the persistence object a lot
+-      heavier.
++  and a clear solution (again, uncle bob -- emphasis added)
+ 
+     "
++      I am not recommending against the use of ActiveRecord. I think the
++      pattern is very useful. **What I am advocating is a separation between the
++      application and ActiveRecord.**
++
++      ActiveRecord belongs in the layer that separates the database from the
++      application. It makes a very convenient halfway-house between the hard
++      data structures of database tables, and the behavior exposing objects in
++      the application.
++
++      **Applications should be designed and structured around objects, not data
++      structures. Those objects should expose business behaviors, and hide any
++      vestige of the database.**
++    "
++      - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
++
++  welcome to the dao
+ 
+-      - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles#comment293734_119352
+ 
+ DESCRITPION
+ 
+
+From 16acaf4c5c1f3508b076b61d466dcb49ebf8b7fa Mon Sep 17 00:00:00 2001
+From: Kerry Ivan Kurian <kerry@dojo4.com>
+Date: Sun, 13 Oct 2013 13:48:42 -0600
+Subject: [PATCH 3/4] no markdown, no emphasis
+
+---
+ README | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/README b/README
+index 0fcddf9..a24e620 100644
+--- a/README
++++ b/README
+@@ -128,21 +128,21 @@ SYNOPSIS
+     "
+       - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
+ 
+-  and a clear solution (again, uncle bob -- emphasis added)
++  and a clear solution (again, uncle bob)
+ 
+     "
+       I am not recommending against the use of ActiveRecord. I think the
+-      pattern is very useful. **What I am advocating is a separation between the
+-      application and ActiveRecord.**
++      pattern is very useful. What I am advocating is a separation between the
++      application and ActiveRecord.
+ 
+       ActiveRecord belongs in the layer that separates the database from the
+       application. It makes a very convenient halfway-house between the hard
+       data structures of database tables, and the behavior exposing objects in
+       the application.
+ 
+-      **Applications should be designed and structured around objects, not data
++      Applications should be designed and structured around objects, not data
+       structures. Those objects should expose business behaviors, and hide any
+-      vestige of the database.**
++      vestige of the database.
+     "
+       - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
+ 
+
+From 4614426f7fc66c97850359b2b3153771065d41ef Mon Sep 17 00:00:00 2001
+From: Kerry Ivan Kurian <kerry@dojo4.com>
+Date: Sun, 13 Oct 2013 13:51:05 -0600
+Subject: [PATCH 4/4] spell bettah
+
+---
+ README | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/README b/README
+index a24e620..b56999b 100644
+--- a/README
++++ b/README
+@@ -149,7 +149,7 @@ SYNOPSIS
+   welcome to the dao
+ 
+ 
+-DESCRITPION
++DESCRIPTION
+ 
+   API
+     applications that are written on dao look like this in ruby

data/README

@@ -36,29 +36,120 @@ SYNOPSIS
   wikipedia has this to say about dao in general
 
     "
-
       In computer software, a data access object (DAO) is an object that
-      provides an abstract interface to some type of database or persistence
-      mechanism, providing some specific operations without exposing details
-      of the database.  It provides a mapping from application calls to the
-      persistence layer. This isolation separates the concerns of what data
-      accesses the application needs, in terms of domain-specific objects and
-      data types (the public interface of the DAO), and how these needs can be
-      satisfied with a specific DBMS, database schema, etc. (the
-      implementation of the DAO).
-
-    " 
+      provides an abstract interface to some type of database or other
+      persistence mechanism. By mapping application calls to the persistence
+      layer, DAOs provide some specific data operations without exposing
+      details of the database. This isolation supports the single
+      responsibility principle. It separates what data accesses the
+      application needs, in terms of domain-specific objects and data types
+      (the public interface of the DAO), from how these needs can be satisfied
+      with a specific DBMS, database schema, etc. (the implementation of the
+      DAO).
+    "
       - http://en.wikipedia.org/wiki/Data_access_object
 
-  and
+  and this to say about the single responsibility principle
+
+    "
+      In object-oriented programming, the single responsibility principle
+      states that every class should have a single responsibility, and that
+      responsibility should be entirely encapsulated by the class. All its
+      services should be narrowly aligned with that responsibility.
+
+      Responsibility [is defined] as a reason to change, and [single
+      responsibility means] that a class or module should have one, and only
+      one, reason to change. As an example, consider a module that compiles and
+      prints a report. Such a module can be changed for two reasons. First,
+      the content of the report can change. Second, the format of the report
+      can change. These two things change for very different causes; one
+      substantive, and one cosmetic. The single responsibility principle says
+      that these two aspects of the problem are really two separate
+      responsibilities, and should therefore be in separate classes or
+      modules. It would be a bad design to couple two things that change for
+      different reasons at different times.
+    "
+      - http://en.wikipedia.org/wiki/Single_responsibility_principle
+
+  even though rails is the sweet, its ActiveRecord class violates (or, at
+  least, encourages a programmer to violate) the single responsibility
+  principle
+
+  this leads to obvious problems
+
+    "
+      Jim Weirich, at the end of his SOLID Ruby Talk at the 2009 Ruby
+      Conference, asks the audience: "ActiveRecord objects implement a domain
+      concept and a persistence concept. Does this violate the SRP (Single
+      Responsibility Principle)?" The audience agrees that it does violate the
+      SRP. Jim asks if this bothers them. Many members of the audience say
+      yes. Why? It makes testing harder. It makes the persistence object a lot
+      heavier.
+    "
+      - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles#comment293734_119352
+
+  and subtle yet sweeping consequences (as described by uncle bob)
+
+    "
+      The problem I have with ActiveRecord is that it creates confusion about
+      ... two very different styles of programming. A database table is a
+      data structure. It has exposed data and no behavior. But an ActiveRecord
+      appears to be an object. It has “hidden” data, and exposed behavior. I
+      put the word “hidden” in quotes because the data is, in fact, not
+      hidden. Almost all ActiveRecord derivatives export the database columns
+      through accessors and mutators. Indeed, the Active Record is meant to be
+      used like a data structure.
+
+      On the other hand, many people put business rule methods in their
+      ActiveRecord classes; which makes them appear to be objects. This leads
+      to a dilemma. On which side of the line does the Active Record really
+      fall? Is it an object? Or is it a data structure?
+
+      This dilemma is the basis for the oft-cited impedance mismatch between
+      relational databases and object oriented languages. Tables are data
+      structures, not classes. Objects are encapsulated behavior, not database
+      rows.
+
+      ...
+
+      The problem is that Active Records are data structures. Putting business
+      rule methods in them doesn’t turn them into true objects. In the end,
+      the algorithms that employ ActiveRecords are vulnerable to changes in
+      schema, and changes in type. They are not immune to changes in type, the
+      way algorithms that use objects are.
+
+      ...
+
+      So applications built around ActiveRecord are applications built around
+      data structures. And applications that are built around data structures
+      are procedural—they are not object oriented. The opportunity we miss
+      when we structure our applications around ActiveRecord is the
+      opportunity to use object oriented design.
+    "
+      - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
+
+  and a clear solution (again, uncle bob)
 
     "
-      Models are not data access objects...
+      I am not recommending against the use of ActiveRecord. I think the
+      pattern is very useful. What I am advocating is a separation between the
+      application and ActiveRecord.
+
+      ActiveRecord belongs in the layer that separates the database from the
+      application. It makes a very convenient halfway-house between the hard
+      data structures of database tables, and the behavior exposing objects in
+      the application.
+
+      Applications should be designed and structured around objects, not data
+      structures. Those objects should expose business behaviors, and hide any
+      vestige of the database.
     "
+      - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
+
+  welcome to the dao
 
-      - http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
 
-DESCRITPION
+DESCRIPTION
 
   API
     applications that are written on dao look like this in ruby
@@ -134,7 +225,7 @@ DESCRITPION
       - forms and interfaces that involve dozens of models are as easy to deal
         with as simple ones.
 
-      - code can be optimized at the interface
+      - code can be optimized at the interface.
 
 READING
   http://blog.plataformatec.com.br/2012/03/barebone-models-to-use-with-actionpack-in-rails-4-0/

data/dao.gemspec

@@ -3,18 +3,18 @@
 
 Gem::Specification::new do |spec|
   spec.name = "dao"
-  spec.version = "5.3.3"
+  spec.version = "5.4.0"
   spec.platform = Gem::Platform::RUBY
   spec.summary = "dao"
   spec.description = "presenter, conducer, api, and better form objects for you rails' pleasure"
   spec.license = "same as ruby's"
 
   spec.files =
-["Gemfile",
+["10.patch",
+ "Gemfile",
  "Gemfile.lock",
  "README",
  "Rakefile",
- "a.rb",
  "dao.gemspec",
  "lib",
  "lib/dao",

data/lib/dao.rb

@@ -11,7 +11,7 @@
 # dao libs
 #
   module Dao
-    Version = '5.3.3' unless defined?(Version)
+    Version = '5.4.0' unless defined?(Version)
 
     def version
       Dao::Version

data/lib/dao/form.rb

@@ -387,6 +387,7 @@ module Dao
         end
 
         if options[:multiple]
+          name = name.to_s
           name += '[]'
         end
 
@@ -658,5 +659,9 @@ module Dao
       string = string.titleize if string.respond_to?(:titleize)
       string
     end
+
+    def capture(*args, &block)
+      tagz(*args, &block)
+    end
   end
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: dao
 version: !ruby/object:Gem::Version
-  version: 5.3.3
+  version: 5.4.0
 platform: ruby
 authors:
 - Ara T. Howard
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2014-02-22 00:00:00.000000000 Z
+date: 2015-03-03 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: rails
@@ -156,11 +156,11 @@ executables: []
 extensions: []
 extra_rdoc_files: []
 files:
+- 10.patch
 - Gemfile
 - Gemfile.lock
 - README
 - Rakefile
-- a.rb
 - dao.gemspec
 - lib/dao.rb
 - lib/dao/active_record.rb

data/a.rb

@@ -1,8 +0,0 @@
-
-f = Dao::Form.new
-
-f.scope_for(:foo) do
-  p f.name_for(:bar)
-  p f.key_for(:bar)
-end
-