Sha256: 67d6281b1fa230d6fab9d862cbfd827fda915036f9c03a44b6314cde17648cca
Contents?: true
Size: 1.63 KB
Versions: 2
Compression:
Stored size: 1.63 KB
Contents
# Custom Builders {% highlight ruby %} class MyCustomBuilder < Blocks.builder_class def initialize(view, options={}) super view, options # Additional initialization / # block definitions could happen here end end {% endhighlight %} {% highlight ruby %} # From a controller action: builder = MyCustomBuilder.new(view_context) builder.define :some_block do "Hello" end builder.render :some_block {% endhighlight %} > This will output "Hello" Blocks::Builder is the main class for storing information about block definitions and their corresponding hooks and wrappers. Wherever a Block is defined, or a hook is registered for a Block, or a block is skipped, or a Block is rendered, all actions will be executed on an instance of Blocks::Builder. When the "blocks" keyword is called from the view for the first time, it will instantiate a new instance of a Blocks::Builder (or a subclass of Blocks::Builder if the Blocks.builder_class is configured to something else - [See Configuring the Builder Class](#configuring-the-builder-class)). A custom builder is just a subclass of Blocks::Builder. Instead of extending the Blocks::Builder class directly though, it is usually better to extend Blocks.builder_class (which will be Blocks::Builder unless it has been configured to something else). The one general exception to this rule is on the class that is configured to be the Blocks.builder_class - this should extend Blocks::Builder directly. If #initialize is overridden in the subclass, it must, at a minimum call super with a reference to the view or view_context, and optionally, the init options hash. ## Custom Builders with Helper Methods
Version data entries
2 entries across 2 versions & 1 rubygems
Version | Path |
---|---|
blocks-3.0.0.rc7 | docs/_includes/custom-builders.md |
blocks-3.0.0.rc6 | docs/_includes/custom-builders.md |