dao 5.4.0 → 5.5.0

checksums.yaml

@@ -1,15 +1,15 @@
 ---
 !binary "U0hBMQ==":
   metadata.gz: !binary |-
-    MGZhZTE2YzNhMmEwMWIxMjBmZmNmMzFkNjliNjFjNzhmZWUwZTZkYg==
+    ODJiYmNmMGY2MDdkYjM1MThiOTUyOGFkMzc5ZDkwMTNhYjA1YjNhYw==
   data.tar.gz: !binary |-
-    MGVmMzI5ZmMxNWJiZDYyYTFhYmQxMThhMzRiMjEyY2NkZDRkMGNlNA==
+    YzRmOWI5Y2ViYjM0NjM5MWFiMDYzZjFhMjEwYjNkMjJkMTJlNmY1Mw==
 !binary "U0hBNTEy":
   metadata.gz: !binary |-
-    ZGY4Mzk2YWYwMWQyYWIyZDVmMzkxZWNjYzIyZmY2Y2FjNDk0YzM3MTQ2NGNj
-    ZGMwNzQwODUwOWQ5Y2RlMjYwODJjMDE4Njg4NmEyMjkxNDFmZjdlMzE0MWEw
-    MTUwN2I0ZWRkZmExNTI0YjU2MmQ5ZmNmMzhlMGVmMGIxMmZlM2U=
+    YzU1M2Y0NWM5MGU2OWI0NTU5MGFlOGQzZWI0MjRkNzEwZTllZGRmMDJkOGNk
+    ZjhlNjAzZjc4OWFmM2M5YjhmMTNlNWVhMWMxNWFhOTgwZTQ4MDdlYTg1MGY0
+    YmY5NWI5N2E0NjYzZmM4NjA5ZDYwNWYyYmI5Zjk4NWJiZTNiOTg=
   data.tar.gz: !binary |-
-    Y2VmY2VmNGUyNjhjYjYyNGJkYzViNDgwNjdiODk0MzlhNzE2ZGRjZDE5ZjMy
-    ZWE0ODdiNWVhZDE3NjYzMmQ3NmY3NGY1N2ZkNTViYjVmZGJjYTE2YWUzZmEy
-    YzVkYWY5NzJkNDg1MDNiNTIxN2RkYThhNTY5Y2EwNjZiZjAyN2I=
+    YTc5NDY5OTBlYjA1MWRjZjA3MjI5MzliOTlhNzQ1MTljZjc3NGJiMjFhY2Y0
+    ZjJjYmQxN2RmZmViMDEzMjlhOWE5ZDEwODVlOTUwMmUwMGE3ZWZiMzEwZDkw
+    ZjdlNGFkMjJmN2JmZWZhZTg0N2U1ZDUyMWEwMGY4ZDJmMDJlYjg=

data/dao.gemspec

@@ -3,15 +3,14 @@
 
 Gem::Specification::new do |spec|
   spec.name = "dao"
-  spec.version = "5.4.0"
+  spec.version = "5.5.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 =
-["10.patch",
- "Gemfile",
+["Gemfile",
  "Gemfile.lock",
  "README",
  "Rakefile",
@@ -107,7 +106,7 @@ Gem::Specification::new do |spec|
   spec.test_files = nil
 
   
-    spec.add_dependency(*["rails", " >= 3.1"])
+    spec.add_dependency(*["rails", " ~> 3.1"])
   
     spec.add_dependency(*["map", " >= 6.0.0"])
   

data/lib/dao.rb

@@ -11,7 +11,7 @@
 # dao libs
 #
   module Dao
-    Version = '5.4.0' unless defined?(Version)
+    Version = '5.5.0' unless defined?(Version)
 
     def version
       Dao::Version
@@ -19,7 +19,7 @@
 
     def dependencies
       {
-        'rails'             => [ 'rails'             , ' >= 3.1'   ] ,
+        'rails'             => [ 'rails'             , ' ~> 3.1'   ] ,
         'map'               => [ 'map'               , ' >= 6.0.0' ] ,
         'fattr'             => [ 'fattr'             , ' >= 2.2'   ] ,
         'coerce'            => [ 'coerce'            , ' >= 0.0.3' ] ,

data/lib/dao/form.rb

@@ -470,6 +470,8 @@ module Dao
 
               option_(opts){ content }
             end
+          else
+            ' '
           end
         }
       end

metadata

@@ -1,27 +1,27 @@
 --- !ruby/object:Gem::Specification
 name: dao
 version: !ruby/object:Gem::Version
-  version: 5.4.0
+  version: 5.5.0
 platform: ruby
 authors:
 - Ara T. Howard
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2015-03-03 00:00:00.000000000 Z
+date: 2015-04-24 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: rails
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - ! '>='
+    - - ~>
       - !ruby/object:Gem::Version
         version: '3.1'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - ! '>='
+    - - ~>
       - !ruby/object:Gem::Version
         version: '3.1'
 - !ruby/object:Gem::Dependency
@@ -156,7 +156,6 @@ executables: []
 extensions: []
 extra_rdoc_files: []
 files:
-- 10.patch
 - Gemfile
 - Gemfile.lock
 - README

data/10.patch

@@ -1,316 +0,0 @@
-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