blocks 3.0.4 → 4.0.0.rc1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
-SHA1:
-  metadata.gz: 28b70c91650eda16f6cda3d72ca19a977332f467
-  data.tar.gz: 5252175f83781196d574e23204416e463289b0e0
+SHA256:
+  metadata.gz: ac889f821c446485bd1f322997668b8918bcbf2ad7537101ff63d8fc072b2b50
+  data.tar.gz: c051d2d14d83d092f4194eefc0c42bfc348e9ee67d5c13d371a7f57cbd5cf04d
 SHA512:
-  metadata.gz: f6af914aa5361e53600908075718aaf31b01e6393da021a475a1c1feee0c09f4fe8bfe9518d358e9eec1076b820b606c3f2e8c4826cbccb80eb65202f1dedebb
-  data.tar.gz: 8e5fff9507774531d1062c89118e41adea3ee1726bda6d74f39bbb094f0cbbff6f5dc6cbd0de997bec5c8d059d435c58ddfe48d07848a4defea70c27d8789836
+  metadata.gz: cf7c5360fa45839ec5f7b43d0a3a0206698d60ee1ba44d456c525c2a35ca5da15f35b4f500330effd8102d28a75daa1dc36fe3ad7c1be8866ff6a203de418aa7
+  data.tar.gz: 1721d9b28d74306501327f1a05e638cb1b27a700099ae385bfa9653d650840e2f56c7a7899ce8bbebf8efd1ffa1a066dfd0e3be200bf92a2e94df1c4fd3abea1

data/.ruby-version

@@ -1 +1 @@
-2.4
+2.7.0

data/.travis.yml

@@ -2,15 +2,26 @@ language: ruby
 cache: bundler
 
 before_install:
-  - gem update bundler
-
+  - function version { echo "$@" | awk -F. '{ printf("%d%03d%03d%03d\n", $1,$2,$3,$4); }'; };
+    if [ $(version $TRAVIS_RUBY_VERSION) -ge $(version '2.7.0') ]; 
+    then
+      gem install "rubygems-update" --no-document;
+      update_rubygems;
+      gem install bundler -v 1.17.3;
+    else
+      gem install "rubygems-update:<3.0.0" --no-document;
+      update_rubygems;
+      gem install bundler -v 1.17.3;
+    fi
 rvm:
-  - 1.9.3
   - 2.0.0
   - 2.1.10
-  - 2.2.7
-  - 2.3.4
-  - 2.4.1
+  - 2.2.10
+  - 2.3.8
+  - 2.4.9
+  - 2.5.6
+  - 2.6.5
+  - 2.7.0
 
 gemfile:
   - gemfiles/Gemfile.rails-3-0-stable
@@ -21,36 +32,69 @@ gemfile:
   - gemfiles/Gemfile.rails-4-2-stable
   - gemfiles/Gemfile.rails-5-0-stable
   - gemfiles/Gemfile.rails-5-1-stable
+  - gemfiles/Gemfile.rails-5-2-stable
   - Gemfile
 matrix:
-  allow_failures:
-    - rvm: ruby-head
   exclude:
-    - rvm: 1.9.3
-      gemfile: gemfiles/Gemfile.rails-5-1-stable
-    - rvm: 1.9.3
-      gemfile: gemfiles/Gemfile.rails-5-0-stable
-    - rvm: 1.9.3
-      gemfile: Gemfile
+    # Exclude Rails 5 from Ruby < 2.3
+    - rvm: 2.0.0
+      gemfile: gemfiles/Gemfile.rails-5-2-stable
     - rvm: 2.0.0
       gemfile: gemfiles/Gemfile.rails-5-1-stable
     - rvm: 2.0.0
       gemfile: gemfiles/Gemfile.rails-5-0-stable
-    - rvm: 2.0.0
-      gemfile: Gemfile
+    - rvm: 2.1.10
+      gemfile: gemfiles/Gemfile.rails-5-2-stable
     - rvm: 2.1.10
       gemfile: gemfiles/Gemfile.rails-5-1-stable
     - rvm: 2.1.10
       gemfile: gemfiles/Gemfile.rails-5-0-stable
+    - rvm: 2.2.10
+      gemfile: gemfiles/Gemfile.rails-5-2-stable
+    - rvm: 2.2.10
+      gemfile: gemfiles/Gemfile.rails-5-1-stable
+    - rvm: 2.2.10
+      gemfile: gemfiles/Gemfile.rails-5-0-stable
+    # Exclude Rails 6 from Ruby < 2.5
+    - rvm: 2.0.0
+      gemfile: Gemfile
     - rvm: 2.1.10
       gemfile: Gemfile
+    - rvm: 2.2.10
+      gemfile: Gemfile
+    - rvm: 2.3.8
+      gemfile: Gemfile
+    - rvm: 2.4.9
+      gemfile: Gemfile
+    # Exclude Rails 3.0 from Ruby => 2.5
+    - rvm: 2.5.6
+      gemfile: gemfiles/Gemfile.rails-3-0-stable
+    - rvm: 2.6.5
+      gemfile: gemfiles/Gemfile.rails-3-0-stable
+    #  Exclude Rails 3 and 4 from Ruby 2.7, as they require 
+    #   Bunder < 2, and Ruby 2.7 ships with Bundler 2.1.2, and
+    #   I can't seem to force it to use an earlier version
+    - rvm: 2.7.0
+      gemfile: gemfiles/Gemfile.rails-3-0-stable
+    - rvm: 2.7.0
+      gemfile: gemfiles/Gemfile.rails-3-1-stable
+    - rvm: 2.7.0
+      gemfile: gemfiles/Gemfile.rails-3-2-stable
+    - rvm: 2.7.0
+      gemfile: gemfiles/Gemfile.rails-4-0-stable
+    - rvm: 2.7.0
+      gemfile: gemfiles/Gemfile.rails-4-1-stable
+    - rvm: 2.7.0
+      gemfile: gemfiles/Gemfile.rails-4-2-stable
+
 script: 'bundle exec rake'
 
 jobs:
   include:
+    # ./bin/deploy_docs will exit if the current branch is not master
     - stage: documentation
       script: './bin/deploy_docs'
-      rvm: 2.4.1
+      rvm: 2.6.5
       gemfile: Gemfile
 
 notifications:

data/CHANGELOG.rdoc

@@ -1,3 +1,30 @@
+3.1.1
+* Injecting blocks method into controller to be able to define blocks from the controller that the view will use.
+
+3.1.0
+* Added content_tag utility block, wrapping around Rails' content_tag method, which
+  may be used directly or indirectly (such as via a wrapper or hook)
+* Removed dead / outdated experimental code
+* Removed dynamic configurator (which was really just an almost copy of Rails' class_attribute)
+  of Blocks in favor of mattr_accessor
+* Removed Ruby 1.9.3 support, now requires >= 2.0
+* Added Extensive Test coverage
+* Deprecated Blocks::Builder#render_with_overrides and made it an alias for Blocks::Builder#render
+* Added GTM to documentation
+* Added a Rails Engine for autoconfiguration of eager_loading options
+* Moved and deprecated content_tag_wrapper utility block into Blocks::LegacyBuilders
+* Hooks and Wrappers now may render with their own sets of Hooks and Wrappers
+* Cleaned and fixed logic around generation / merging of options for hooks and
+  and wrappers of a block
+* Moved Haml Extensions into a separate module that only executes if Haml is defined
+* Deprecated with_template method injected into ActionView::Base
+* Moved Blocks::HashWithCaller into a module and now conditionally inject based
+  on global configuration
+* Switched Blocks::HashWithRenderStrategy to use symbols for hash keys instead of string,
+  allowing it to be extracted as hash keyword arguments to methods
+* Removed blocks.define :collection functionality
+
+
 3.0.0 (September 27, 2017)
 * Complete rewrite of the blocks gem
 * Extensive test coverage added

data/Gemfile

@@ -2,24 +2,25 @@ source "https://rubygems.org"
 
 gemspec
 
-gem "nokogiri"
+# Requires min Ruby version 2.3
+
+gem "nokogiri", "1.10.7"
 gem "capybara"
 gem "rspec", "~> 3.6.0"
-gem "arel", github: "rails/arel"
-gem "rails", github: "rails/rails"
+gem "rspec-its", "~> 1.2.0"
+gem "rails", github: "rails/rails", branch: "6-0-stable"
 gem "rack"
-gem "shoulda-matchers", "~> 2.0"
-gem "haml"
+gem "shoulda-matchers", "3.1.3"
+gem "haml", "~> 5.0.0"
 
 # Extra development utilities
-gem "ruby_dep"
-gem "guard-rspec", "~> 4.7"
-gem "terminal-notifier-guard"
-gem "byebug"
 gem "codeclimate-test-reporter", "~> 1.0.8"
 
 group :development, :test do
+  gem "terminal-notifier-guard"
+  gem "guard-rspec", "~> 4.7"
+  gem "byebug"
   gem "jekyll"
   gem "jekyll-feed", "~> 0.6"
   gem "jekyll-coffeescript"
-end
+end

data/Guardfile

@@ -9,6 +9,7 @@ rspec_options = {
 
 guard :rspec, cmd: "bundle exec rspec" do
   watch(%r{^spec/.+_spec\.rb$})
+  watch(%r{^spec/support/.+\.rb$})     { "spec" }
   watch(%r{^lib/blocks/(.+)\.rb$})     { |m| ["spec/features", "spec/unit/#{m[1]}_spec.rb"] }
   watch(%r{^lib/blocks.rb$})           { "spec" }
   watch('spec/spec_helper.rb')         { "spec" }

data/README.md

@@ -21,6 +21,8 @@ Please checkout the documentation for the Blocks gem here: http://hunterae.githu
 
 ## Installation
 
+Blocks requires Rails 3.0 or greater and Ruby 2.0 or greater.
+
 Add this line to your application's Gemfile:
 
 ```ruby

data/bin/deploy_docs

@@ -27,7 +27,7 @@ function build_site {
 function deploy {
 	echo "deploying changes"
 
-	if [ -z "$TRAVIS_PULL_REQUEST" ]; then
+	if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then
 	    echo "except don't publish site for pull requests"
 	    exit 0
 	fi

data/blocks.gemspec

@@ -27,8 +27,10 @@ Gem::Specification.new do |spec|
   spec.executables   = spec.files.grep(%r{^exe/}) { |f| File.basename(f) }
   spec.require_paths = ["lib"]
 
-  spec.add_dependency "call_with_params"
   spec.add_dependency "rails", ">= 3.0.0"
 
   spec.add_development_dependency "simplecov"
+  if RUBY_VERSION >= "2.1"
+    spec.add_development_dependency "memory_profiler"
+  end
 end

data/docs/_includes/configuration.md

@@ -16,8 +16,7 @@ Global Options are merged into the set of options generated when rendering a blo
 {% highlight erb %}
 Blocks.configure do |config|
   config.
-    global_options_set.
-    add_options runtime: {
+    set_global_options runtime: {
       a: 1, b: 2
     }
 end
@@ -27,8 +26,7 @@ end
 {% highlight erb %}
 Blocks.configure do |config|
   config.
-    global_options_set.
-    add_options a: 1, b: 2
+    set_global_options a: 1, b: 2
 end
 {% endhighlight %}
 
@@ -36,8 +34,7 @@ end
 {% highlight erb %}
 Blocks.configure do |config|
   config.
-    global_options_set.
-    add_options defaults: {
+    set_global_options defaults: {
       a: 1, b: 2
     }
 end

data/docs/_includes/defining.md

@@ -1,14 +1,18 @@
 # Defining Blocks
 
+With Blocks, you can define a block of code for later rendering using Ruby blocks, Rails partials, and proxies to other blocks or methods.
+
+A block consists of a name, an optional hash of options, and a rendering strategy (also called its definition).
+
 ```erb
 <% blocks.define :my_block %>
-<!-- OR -->
+<!-- SAME AS -->
 <% blocks.define "my_block" %>
 ```
 
 ```haml
 - blocks.define :my_block
-#- OR
+#- SAME AS
 - blocks.define "my_block"
 ```
 
@@ -16,14 +20,10 @@
 # where builder is an instance
 #  of Blocks::Builder
 builder.define :my_block
-# OR
+# SAME AS
 builder.define "my_block"
 ```
 
-With Blocks, you can define a block of code for later rendering using Ruby blocks, Rails partials, and proxies to other blocks.
-
-A block consists of a name, a hash of options, and a rendering strategy (also called its definition).
-
 A block's name can be a symbol or a string. The underlying system treats symbols and strings the same. Therefore, any block that is defined with a String name can be accessed with its corresponding symbol name and vice-versa.
 
 ## With a Ruby Block

data/docs/_includes/{introduction.md → features.md}

@@ -1,4 +1,4 @@
-# Introduction
+# Features
 
 **VERSION {% gem_version %}**
 
@@ -7,7 +7,7 @@ The [blocks gem](http://github.com/hunterae/blocks) is many things.
 It acts as:
 
 * a container for reusable blocks of code and options
-* a common interface for rendering code, whether the code was defined previously in Ruby blocks, Rails partials, or proxies to other blocks of code
+* a common interface for rendering code, whether the code was defined previously in Ruby blocks, Ruby Methods, Rails partials, or proxies to other blocks of code
 * a series of hooks and wrappers that can be utilized to render code before, after, and around other blocks of code, as well as before each, after each, and around each item in a collection
 * a templating utility for easily building reusable and highly customizable UI components
 * a means for DRYing up oft-repeated code in your layouts and views

data/docs/_includes/helper-blocks.md

@@ -0,0 +1,5 @@
+# Helper Blocks
+
+Blocks comes with some prebuilt utility blocks to aid in your development efforts.
+
+{% include helper-blocks/content_tag.md %}

data/docs/_includes/helper-blocks/content_tag.md

@@ -0,0 +1,44 @@
+## The :content_tag Block
+
+> According to Bootstrap's documentation, a standard card has the following markup:
+
+The :content_tag block is more or less a direct wrapper around [ActionView's content_tag method](https://apidock.com/rails/ActionView/Helpers/TagHelper/content_tag).
+However, by defining it as a block, it may be used in several useful ways.
+
+### As the definition for a block
+
+```erb
+<% blocks.define :title, with: :content_tag, tag: :h1, html: { style: "color: red" } %>
+<%= blocks.render :title do %>
+  My Title
+<% end %>
+```
+
+```haml
+- blocks.define :title, with: :content_tag, tag: :h1, html: { style: "color: red" }
+= blocks.render :title do
+  My Title
+```
+
+```ruby
+builder = Blocks::Builder.new(view_context)
+builder.define :title, with: :content_tag, tag: :h1, html: { style: "color: red" }
+# Since no overrides block is provided, this
+#  call is synonymous with:
+builder.render :title do
+  "My Title"
+end
+```
+
+> The output from running the code will be:
+{% highlight html %}
+<h1 style="color: red">
+  My Title
+</h1>
+{% endhighlight %}
+
+When used as the definition for a block (using the with keyword), you may choose to specify the tag to use or any html options to be applied to the tag.
+Then, you can either provide the definition a block of its own or supply as a render option when calling render.
+
+### As a wrapper or a surrounding hook for a block
+

data/docs/_includes/installation.md

@@ -1,8 +1,8 @@
 # Installation & Prerequisites
 
-Blocks requires Rails 3.0 or greater.
+Blocks requires Rails 3.0 or greater and Ruby 2.0 or greater.
 
-It has been tested with Ruby 1.9.3 through 2.4.1, and Rails 3.0 - 5.1 (as well as Edge Rails)
+It has been tested with Ruby 2.0.0 through 2.5.1 (as well as ruby-head), and Rails 3.0 - 5.2 (as well as Edge Rails)
 
 ```
 gem 'blocks'
@@ -22,4 +22,18 @@ Then run this from your project directory command line:
 
 <aside class="success">
 In most cases, this will be all you need to do. The "blocks" helper method is now available within your Rails views
+</aside>
+
+{% highlight ruby %}
+if !Object.respond_to?(:yaml_as)
+  class Object
+    def self.yaml_as(*args)
+      yaml_tag(*args)
+    end
+  end
+end
+{% endhighlight %}
+
+<aside class="warning">
+To get Blocks working for Rails 3.0 with a Ruby version of 2.5 or greater, use the following patch:
 </aside>

data/docs/_includes/overview.md

@@ -0,0 +1,21 @@
+# Overview
+
+There are many ways to render content to the screen in web applications. Ruby on Rails offers a couple of default strategies right off the bat through its combination of ActionController, ActionView, and ERB templating language:
+
+* Rendering content within an ActionView template (the controller action) and layout
+* Pulling in additional content through rendering partials
+* Capturing content from a block and outputting that content at some later point
+* Calling a different method from the controller action which determines what and how to render
+
+There are obviously additional means to render output, such as the redirect methods in a controller and rendering inline code, but generally speaking, most generated output come about through one of those above methods.
+
+The approaches listed above can essentially be generalized as follows
+
+* Rendering using a method
+* Rendering fragments (using a Rails' partial)
+* Storing content for later rendering (using a Ruby Block)
+* Proxying to another source that knows what to / how to render
+
+The Blocks gem attempts to take these four concepts and provide one common interface.
+
+The reasoning behind this is simple.

data/docs/_includes/templating.md

@@ -20,7 +20,7 @@
 
 ```ruby
 builder = Blocks::Builder.new(view_context)
-builder.render_with_overrides partial:
+builder.render partial:
   "PATH_TO_PARTIAL" do |builder|
   # Perform overrides here
   #  using the builder.

data/docs/_includes/templating/bootstrap_4_cards.md

@@ -55,7 +55,7 @@ Templating is best demonstrated through example. In the following set of iterati
 
 ```ruby
 builder = Blocks::Builder.new(view_context)
-builder.render_with_overrides partial: "shared/card"
+builder.render partial: "shared/card"
 # Since no overrides block is provided, this
 #  call is synonymous with:
 builder.render partial: "shared/card"
@@ -215,7 +215,7 @@ Because all of :block_wrapper's options are default options, they are easily ove
 
 :card_block, :card_title, and :card_text each follow the same paradigm. Notice that :card_text overrides the :wrapper_tag to :p and :card_title overrides it to :h4.
 
-<aside class="notice">This paradigm of using a block wrapper that wraps a block within an HTML element is so common, that Blocks provides a similar block by default called :content_tag_wrapper (also accessible as the constant Blocks::Builder::CONTENT_TAG_WRAPPER_BLOCK). If this automatically defined block is used instead, the code to the right would only need to change by removing the :block_wrapper definition and changing all references to :block_wrapper to Blocks::Builder::CONTENT_TAG_WRAPPER_BLOCK.</aside>
+<aside class="notice">This paradigm of using a block wrapper that wraps a block within an HTML element is so common, that Blocks provides a similar block by default called :content_tag (purposely named to match the ActionView method). If this automatically defined block is used instead, the code to the right would only need to change by removing the :block_wrapper definition and changing all references of :block_wrapper to :content_tag.</aside>
 
 <aside class="notice">The only two blocks that are not using the :block_wrapper are :card_image and :card_action. While both could utilize the :block_wrapper wrapper, it makes more sense not to do so. This will enable us to utilize Rails' link_to and image_tag helper methods instead, since links and images need a bit more fine-tuning than regular HTML elements.</aside>
 
@@ -348,7 +348,7 @@ builder = Blocks::Builder.new(view_context,
   card_text: "My Text",
   card_action_path: 'http://mobilecause.com',
   card_image: "my-image.png")
-builder.render_with_overrides partial: "shared/card"
+builder.render partial: "shared/card"
 ```
 
 > The above code will output the following:
@@ -439,7 +439,7 @@ Now that the template is defined, we can start rendering it with actual override
 
 ```ruby
 builder = Blocks::Builder.new(view_context)
-text = builder.render_with_overrides partial:
+text = builder.render partial:
   "shared/card" do |builder|
   builder.define :card do
     "I am a complete replacement for the card"
@@ -447,7 +447,7 @@ text = builder.render_with_overrides partial:
 end
 
 builder = Blocks::Builder.new(view_context)
-text2 = builder.render_with_overrides partial:
+text2 = builder.render partial:
   "shared/card" do |builder|
   # Change card_title's tag to h2
   builder.define :card_title,
@@ -607,7 +607,7 @@ Finding the option overrides aren't enough? There's always block overrides. Any
 
 ```ruby
 builder = Blocks::Builder.new(view_context)
-builder.render_with_overrides partial:
+builder.render partial:
   "shared/card" do |builder|
   builder.skip :card_image
   builder.after :card_title do
@@ -662,7 +662,7 @@ We also have access to the full arsenal of hooks, wrapper with relation to the v
 > Assume the following partial exists in /app/views/shared/\_team_card.html.erb:
 
 {% highlight erb %}
-<%= builder.render_with_overrides partial:
+<%= builder.render partial:
   "shared/card" do |builder| %>
   <% builder.define :card_title,
     card_title: team.name %>
@@ -708,7 +708,7 @@ team = OpenStruct.new(
   description: "Donate money"
 )
 builder = Blocks::Builder.new(view_context)
-builder.render_with_overrides partial:
+builder.render partial:
   "shared/team_card",
   team: team do |builder|
     builder.after :card_title do
@@ -749,5 +749,5 @@ An example might be create new templates that render different versions of a car
 In the example to the right, a team-specific version of card is created as a template. Code then renders this new template with some overrides of if its own. The overrides have been kept very basic in order to clearly demonstrate how to setup a template that extends another template.
 
 <aside class="warning">
-  Take note that with the team_card template, builder.render_with_overrides is used instead of just render_with_overrides. This is forcing the two templates to render using the same Blocks::Builder instance, i.e. to share a Blocks namespace. This is what allows the overrides block for the team_card template to affect the defaults in card template.
+  Take note that with the team_card template, builder.render is used instead of render_with_overrides. This is forcing the two templates to render using the same Blocks::Builder instance, i.e. to share a Blocks namespace. This is what allows the overrides block for the team_card template to affect the defaults in card template.
 </aside>