DEV Community: andriy-baran

FormBuilder Proxy vs Template Method

andriy-baran — Wed, 14 Jan 2026 14:00:00 +0000

Previously in this series:

Part 1: The Service Object Graveyard: Why Your POROs Failed and Handlers Won
Part 2: Constructor Hell and the "Owner" Bubble: Stealing from Browser JS

The Pattern Conflict

Take the paradox: Rails gives us ActionView::Helpers::FormBuilder - a thing literally named "Builder" - and yet complex forms still collapse into partial soup, param drift, and "where do errors render?" archaeology.

So let's pressure-test the premise.

Rails FormBuilder is a Proxy: a yielded object that forwards calls to view helpers (a toolbox you operate).
ActionForm (with Phlex) is Template Method: a rendering algorithm with named steps (an assembly line you override).

The difference is not "syntax." It's ownership of the rendering process.

Rails even says the quiet part out loud: FormBuilder "can be thought of as serving as a proxy for the methods in the FormHelper module" (Rails 8 FormBuilder docs).

1) The Pattern Conflict: Proxy vs Skeleton

Why did we spend a decade treating the form as a proxy for a model object instead of a skeleton of a rendering algorithm?

Because the ERB world is document-first.

You write a template; Rails yields a toolbox into it:

<%= form_with model: @person do |f| %>
  <%= f.text_field :name %>
  <%= f.checkbox :admin %>
<% end %>

The template owns sequencing, composition, and integration. The builder helps you emit tags, but it doesn't define the algorithm of "how a form is rendered."

2) The Source of Truth: Who Owns the Contract?

If a Rails FormBuilder is a proxy for helper methods, who owns the "data contract"?

In practice it gets split:

Model owns validations (sometimes).
Controller owns permitted params (always, if you use strong params).
View owns what fields exist (implicitly, by emitting tags).

That's a three-body problem. When complex domains enter, the contract becomes a moving target: the UI can ask for fields the controller doesn't permit; the controller can permit keys the UI doesn't render; the model can validate attributes the UI never sends.

3) The Algorithm vs the Toolbox

Why is a rigid rendering flow more resilient than yielding a toolbox?

Because "toolbox" means every view is forced to re-invent ordering:

where labels render
where errors render
how wrappers are structured
what happens for nested collections

With Template Method, the base class owns the skeleton:

def view_template
  render_form do
    render_elements
    render_submit
  end
end

The structure is an algorithm. And the steps have names.

This is what Phlex enables: a view is not a string with holes - it is a Ruby object with a view_template entrypoint.

4) Surgical Overrides: Override a Step, Not a Document

How does Template Method let you override a single step—like render_label - without subclassing a FormBuilder and juggling glue like objectify_options?

Rails' extension story is: subclass FormBuilder, add helper methods, and be careful to call objectify_options so the model binding isn't silently severed (Rails 8 FormBuilder docs).

Template Method flips the problem: you don't add more tools; you override the algorithm.

Example: suppress all labels (or change their wrapper) without touching every field call site:

class NoLabelForm < ProductForm
  def render_label(element)
    # intentionally empty
  end
end

The form stays a form. The rendering skeleton stays intact. Only one step changes.

5) The "Params Drift" Paradox

If FormBuilder is associated with a model, why is it so easy for parameters to drift away from the view definition?

Because "associated" is not "authoritative."

FormBuilder helps generate field names for an object. It does not produce the contract the controller permits. The contract is still written elsewhere, by hand, often long after the UI evolved.

ActionForm takes a different stance: the contract is derived from the form's declared elements.

That's the key inversion: instead of the UI being a projection of controller params, params become a projection of the UI's declared structure. (And because elements can be conditional—render?—it can generate a schema from the rendered structure when needed.)

The Form Elements DSL

How do you declare elements? ActionForm provides a DSL that defines both the UI structure and the data contract in one place:

class ProductForm < ActionForm::Base
  element :title do
    input type: :text
    output type: :string, presence: true
  end

  element :price do
    input type: :number, step: 0.01
    output type: :decimal, presence: true, numericality: { greater_than: 0 }
  end

  element :description do
    input type: :textarea, rows: 5
    output type: :string
  end
end

The DSL does three things at once:

Declares the input (input) - what HTML attributes and type the field needs
Declares the output (output) - what type and validations the parameter contract expects
Creates the element class - a Ruby object that can answer questions like render?, readonly?, disabled?, or value

This is why "drift" becomes impossible: the form definition is the contract. The controller doesn't manually permit fields—it receives an EasyParams object generated from the form's output declarations.

Element Methods: Behavior as Code

Elements aren't just data structures—they're Ruby objects with methods you can override. This is where Template Method shines: you override behavior, not markup.

render? - Controls whether the element should be rendered:

element :admin_field do
  input type: :text

  def render?
    object.admin?  # Only render for admin users
  end
end

readonly? - Controls whether the element is readonly:

element :email do
  input type: :email

  def readonly?
    object.verified?  # Readonly if email is verified
  end
end

disabled? - Controls whether the element is disabled:

element :username do
  input type: :text

  def disabled?
    object.persisted?  # Disable for existing records
  end
end

detached? - Indicates if the element is detached from the object (uses static values):

element :static_field do
  input type: :text, value: "Static Value"

  def detached?
    true  # This element doesn't bind to object values
  end
end

tags - Access element metadata for conditional rendering:

element :priority_field do
  input type: :text
  tags priority: "high", section: "important"
end

# In your rendering algorithm:
def render_element(element)
  render_label(element)
  render_input(element)
  render_inline_errors(element) if element.tags[:errors]
end

The tags hash automatically includes:

:input - The input type (e.g., :text, :email, :select)
:output - The output type (e.g., :string, :integer, :bool)
:options - true if the element has options (for selects/radios)
:errors - true/false based on validation state

These methods integrate with the rendering algorithm: render_elements can filter with select(&:render?), and render_input can check readonly? to add the readonly attribute. The element becomes a first-class participant in the rendering process, not just a data bag.

6) Composition vs Helpers

Why did we favor helpers for so long when Phlex-based composition lets UI elements be Ruby objects?

Because templates make composition look like copy/paste:

partials
locals
content_for
"just one more if"

Composition (Phlex) makes it look like programming:

objects
methods
inheritance
tests against behavior

The important shift: UI parts can have state, methods, and boundaries. They can answer questions like "should I render?" without hiding that logic in template conditionals.

7) Handling Nesting: From Manual Chore to Structured Algorithm

Why is accepts_nested_attributes_for + templates so painful?

Because the UI needs a repeatable mechanism for:

rendering each child
rendering a "new child" template
maintaining correct naming/indexing

In a toolbox world, you build that by convention and JS glue.

In an algorithm world, the base class can define the lifecycle: build instances, render instances, and even render a "NEW_RECORD" template consistently. Nesting becomes a first-class step, not a copy/pasted ritual.

8) Error Integration: Errors as a Built-In Phase

In proxy-based systems, error handling is typically "extra."

You decide:

where to show inline errors
how to style them
how to aggregate them

Template Method makes errors a phase in the algorithm:

def render_element(element)
  render_label(element)
  render_input(element)
  render_inline_errors(element) if element.tags[:errors]
end

That's not just convenience. It's enforcement: error rendering is now a default behavior of the skeleton, not an optional add-on scattered across templates.

9) The 6-Year Verdict

Is the FormBuilder proxy "enough" for simple CRUD? Yes.

But complex domains don't need more tools. They need a formal rendering algorithm:

stable steps
named override points
consistent nesting and error phases

The "Industrial Assembly Line" Metaphor

Rails FormBuilder is a high-end toolbox (Proxy). It gives you the wrenches, but you decide the order of assembly every time you enter the garage.

ActionForm (with Phlex) is the assembly line (Template Method). The skeleton of the process is built into the floor. You can swap specific parts (override steps), but the line enforces sequencing: chassis before engine, inspection before shipping.

That's the difference between "UI as emitted strings" and "UI as an algorithm."

Resources

Libraries / examples
- SteelWheel - Handler framework
- ActionForm - Form DSL
- EasyParams - Type-safe parameters
- Real App - Production example
- Rails 8 FormBuilder docs

Ask yourself:

Are you shipping forms, or are you rebuilding the assembly line every time you render a field?

If the domain is complex, maybe the right move isn't "more helpers." Maybe it's ownership of the algorithm.

Constructor Hell: Replacing Dependency Injection with Chain of Responsibility in Ruby

andriy-baran — Fri, 09 Jan 2026 14:00:00 +0000

Previously in this series:

Part 1: The Service Object Graveyard: Why Your POROs Failed and Handlers Won

The Hook: The One-Line Change That Touched Five Files

At what point did I realize my architecture was failing?

It wasn't a production crash. It was a request to add a single permission check to a nested form field.

"Show the wholesale_price field only if the user has enterprise_view permission."

Simple, right? Not in my app. Because to get that permission check into that nested field, I had to:

Update the Handler constructor to take current_user.
Pass it to the Form constructor.
Pass it to the Collection constructor.
Pass it to the Subform constructor.
Pass it to the Element instance.

I was manually dragging context through five layers of objects just so a tiny subform could check a single flag.

If I had to pass tenant_id or current_user into one more constructor, I was ready to quit web dev and become a hardware engineer. At least in hardware, wires don't have to be manually passed through every intermediate component.

The Constructor Hell Reality: "Pure" DI is a Trap

I was committed to "pure" dependency injection. I'd read the books. I knew "globals are evil." I knew "helpers are hidden state."

The logic: If an object needs something, it should be passed in the constructor. No exceptions.

The result:

# The "Pure" way to despair
form = ProductForm.new(
  object: product,
  current_user: current_user,
  account: account,
  feature_flags: feature_flags,
  pricing_tier: pricing_tier,
  policy: policy
)

# Deep in the subform...
subform = VariantForm.new(
  object: variant,
  current_user: current_user,      # PASSING
  account: account,                # PASSING
  feature_flags: feature_flags,    # PASSING
  pricing_tier: pricing_tier       # PASSING
)

Every intermediate layer became a context shuttle. These objects didn't use the context; they just carried it for their children.

It was fragile. It was noisy. And it made refactoring impossible—adding one piece of context meant changing five files.

The paradox: In my attempt to make dependencies "explicit," I made the system so rigid it was unmaintainable.

The False Choice: Sledgehammer vs. Spaghetti

I spent years thinking my only options were:

Constructor Hell: Passing everything down manually (The "Pure" Way).
Dirty Shortcuts: Using Current.user or global helpers (The "Lazy" Way).

I hated both.

Option 1 made my code unreadable and rigid.
Option 2 made my code untestable and mysterious.

I was looking for a third way: stop treating context like a constructor argument, and start treating your system like a tree.

Build an explicit ownership tree, and make one rule non-negotiable: every object knows its owner. Then children can request context from above instead of you injecting it through every layer.

This isn't just a theory. The libraries in this series implement this pattern directly:

SteelWheel builds the tree (handler owns the request and creates the form with owner: self)
ActionForm uses owner + owner_* to bubble context up the chain
EasyParams uses the same owner_* idea inside parameter objects, so validations can ask the handler (or other owners) for context

The Browser Epiphany: Why Does JS Bubble?

Think about how events work in the browser.

You click a button deep in the DOM. You don't have to pass an onClick handler from the <html> tag down through every single div to reach that button.

Instead, the event bubbles up.

The button "screams" that it was clicked, and it bubbles up the hierarchy until some parent element decides to handle it.

The insight: Why do we love the way events bubble up the DOM, yet I spent a decade forcing my Ruby objects to be strictly, painfully top-down?

Why can't my nested form element "scream" its request for context up the hierarchy?

Stop Passing Context. Start Requesting It

I decided to stop passing context and start letting components request it.

Instead of DI-by-constructor, I built a tree and gave every node an owner. Once every object knows who owns it, context can bubble upward on demand.

I used method_missing to implement an ownership chain. If an element doesn't know the answer, it asks its owner. If the owner doesn't know, it asks its owner.

# Instead of passing everything...
form = ProductForm.new(object: product, owner: handler)

# The element just screams its request
element :wholesale_price do
  def render?
    owner_can_view_wholesale?  # "Hey, someone up there, can I do this?"
  end
end

The mechanics:

Element calls owner_can_view_wholesale?.
method_missing intercepts the call because of the owner_ prefix.
The element strips the prefix and tries can_view_wholesale? on its owner (the subform).
Subform doesn't have it? It repeats the same delegation to its owner (the form).
Form doesn't have it? It repeats again to its owner (the handler).
Handler has can_view_wholesale?. Answer returned.

Context bubbles up, not down.

The Tree Duality: Composition Goes Both Ways

This works because your object graph is already a tree.

A Handler contains a Form. A Form contains Elements. That’s normal composition — objects containing other objects.

But here’s the missing mental model: trees support delegation in both directions:

Downward (Parent → Children): normal orchestration (handler calls form, form iterates elements)
Upward (Children → Parent): context bubbling (elements ask owners for context)

And the deeper your composition is, the more this pays off.

If your object graph is only 1–2 levels deep, constructor DI feels fine. But once you have real-world nesting—forms inside forms, collections, subforms, elements inside elements—every new piece of context becomes a change to every intermediate constructor.

Owner delegation flips that scaling: deep trees are no longer a liability. They’re exactly what makes bubbling powerful.

We’re taught to think composition is one-way. Parent creates children, parent calls children. Done.

Owner delegation adds the other half: children can ask upward without you manually shuttling context through every intermediate constructor.

# Downward: Normal composition (parent → children)
class ProductHandler < ApplicationHandler
  def form
    @form ||= ProductForm.new(owner: self)  # Handler → Form
  end

  def on_validation_success
    form.elements.each(&:finalize)  # Handler → Form → Elements
  end
end

# Upward: Context bubbling (children → parent)
class PriceElement < ActionForm::Element
  def render?
    owner_can_view_pricing?  # Element → Form → Handler
  end

  def currency
    owner_current_currency  # Element → Form → Handler
  end
end

Same tree. Two directions. No constructor hell. No hidden globals.

Transparent Structures: Runtime Specialization Without the Pain

This is the name I use for the broader idea: Transparent Structures.

A structure is “transparent” when you can open any component class at runtime (form, subform, element, params schema) and specialize its behavior in a precise, local way—without rewriting the whole graph or threading new dependencies through every constructor.

Owner delegation is one part of it: it makes context flow up through the structure when a deep leaf needs something.

The `owner_` Signal: Magic With Intent

I chose the explicit owner_ prefix for a reason.

I know it’s a "magic" trick. I know some Rubyists hate method_missing. But I needed it to be explicit.

I didn't want mysterious method calls where you don't know where the data comes from. I wanted any developer—including my future self—to see owner_ and immediately understand: "I am delegating this request up the ownership chain."

It’s a signal: "I don't have this context, but my owner does."

It turns a hidden dependency into an explicit request.

The Sharp Edges (and Why It's Still Worth It)

Yes, method_missing is sharp. The trick is to use it with guardrails:

Make delegation opt-in: only delegate when the call starts with owner_.
Implement respond_to_missing?: so introspection and tooling don't lie.
Keep the API narrow: you’re not delegating “everything”, you’re delegating explicit requests for context.
Fail normally: if the chain can’t answer, let Ruby raise NoMethodError (or add a custom error message later if you want).

This isn’t “mysterious magic.” It’s a deliberate mechanism for one specific problem: context bubbling.

And it’s not hypothetical — the core idea in ActionForm::Composition is literally:

def method_missing(name, *attrs, **kwargs, &block)
  return super unless name.to_s.start_with?("owner_")

  owner_method = name.to_s.sub("owner_", "").to_sym
  return super unless (handler = owners_chain.detect { |o| o.respond_to?(owner_method) })

  handler.public_send(owner_method, *attrs, **kwargs, &block)
end

The Chain of Responsibility: A Multi-Level Power Grid

Passing context through constructors is like manually wiring every single lightbulb in your house directly back to the city's power plant. If you want to add one lamp in the attic, you have to rip open every floorboard to run the wire.

Owner Delegation is a modern electrical grid.

You just plug the lamp into the nearest wall socket (the owner_ call), and the house takes care of "bubbling" that request up to the main breaker for you.

The hierarchy:

Element: "I need the current user's role."
Subform: "Don't know, asking the form."
Form: "Don't know, asking the handler."
Handler: "Here it is."

Intermediate layers (Subform, Form) don't need to know anything about the current user's role. They just need to know who their owner is.

This is the Chain of Responsibility pattern, applied to composition.

The DX Shift: Vibe Coding Without the Weight

I’m now "vibe coding" without the weight of a thousand manual injections.

When a requirement changes, I don't dread it. I don't have to touch five files to add one permission check. I just call owner_something? and add the method to the handler.

Can I finally admit it? The "Rails Way" stopped being the most productive path for my complex domains a long time ago.

We’ve been taught to fear "magic" and "metaprogramming." But I’ve learned that the magic of structured delegation is far less dangerous than the boilerplate of manual injection.

One keeps your code clean. The other keeps you in the office until 11 PM on a Friday.

Resources

Series
- Part 1: The Service Object Graveyard: Why Your POROs Failed and Handlers Won
- Part 2: Constructor Hell and the "Owner" Bubble (this post)
Libraries / examples
- SteelWheel - Handler framework (builds the tree: handler owns the request + creates form with owner: self)
- ActionForm - Form DSL (implements owner + owner_* bubbling via ActionForm::Composition)
- EasyParams - Type-safe parameters (implements owner + owner_* bubbling via EasyParams::Composition)
- Real App - Production example

Next time you find yourself passing a variable through three constructors just to reach a child element:

Ask yourself: Are you building a house, or are you just running miles of redundant wire?

Remember: trees aren't just for pushing commands down. They're for pulling context up.

Maybe it's time to install the grid.

The Service Object Graveyard: Why Your POROs Failed and Handlers Won

andriy-baran — Wed, 07 Jan 2026 14:00:00 +0000

The Hook: A PORO Mustache on a Fat Controller

I spent years stuffing logic into app/services. Felt productive. Felt like I was doing "proper architecture."

Then I looked at what I'd actually built:

# app/services/products/create_service.rb
class Products::CreateService
  def initialize(params, current_user)
    @params = params
    @current_user = current_user
  end

  def call
    return failure("Unauthorized") unless authorized?
    return failure("Invalid params") unless valid_params?

    product = Product.new(product_params)

    if product.save
      add_to_stock(product)
      notify_team(product)
      log_creation(product)
      success(product)
    else
      failure(product.errors)
    end
  end

  private

  def authorized?
    @current_user.can_create_products?
  end

  def valid_params?
    # ... 50 lines of manual validation
  end

  def product_params
    @params.permit(:title, :description, :price)  # ← Still manual, still drifts
  end

  def add_to_stock(product)
    # ... 30 lines
  end

  def notify_team(product)
    # ... 20 lines
  end

  def log_creation(product)
    # ... 15 lines
  end

  def success(product)
    OpenStruct.new(success?: true, product: product)
  end

  def failure(error)
    OpenStruct.new(success?: false, error: error)
  end
end

# app/controllers/products_controller.rb
class ProductsController < ApplicationController
  def create
    result = Products::CreateService.new(params, current_user).call

    if result.success?
      redirect_to result.product
    else
      @errors = result.error
      render :new
    end
  end
end

What did I actually achieve?

I moved a 500-line controller method into a 400-line service object. Put a mustache on it. Called it "architecture."

The controller was thinner. But everything else—params drift, scattered validation, implicit contracts, duplication between new and create—remained.

I'd hidden the problem. Not solved it.

The Vibe Coding Reality: We Walked Halfway and Stopped

Let's examine what happened.

Around 2015, the Rails community realized: "Fat controllers are bad." Service objects emerged as the solution.

The promise:

Thin controllers
Testable business logic
Clear separation of concerns
Reusable operations

What we actually built:

✅ Business logic extracted
❌ Params still manual (permit still drifts)
❌ Validation still scattered (model? service? both?)
❌ No standard interface (what does call return?)
❌ No structured error handling (strings? hashes? objects?)
❌ No form integration (still writing ERB)
❌ No action grouping (new and create still separate)

We built the framing for a modern house—then stopped. Threw a tarp over it. Called it "good enough."

I lived under that tarp for years, getting wet every time it rained, calling it "minimalism."

Take this paradox: Service objects were supposed to make code clearer. But I still couldn't answer basic questions:

What data format does this operation expect? (Implicit)
Where does validation happen? (Scattered)
How do I handle different error types? (Manual conditionals everywhere)
Why am I duplicating setup between new and create? (¯\(ツ)/¯)

The community walked halfway toward "Thin Controllers" but forgot to build the infrastructure to support them.

The Sanity Tax: Settling for Params Drift

Here's the tax I paid every month:

Saturday, 11:47 PM. Production bug.

User reports profile not saving. I investigate. They filled out the form: name, email, phone, bio. Clicked save. Success message. But only email saved.

The archaeology begins:

Check the view (_form.html.erb) → phone and bio fields exist ✓
Check the model (User) → validations for phone and bio exist ✓
Check the service object (UpdateUserService) → validation logic for phone and bio exists ✓
Check the controller (params.permit) → Missing :phone and :bio ✗

Someone added the fields six months ago. Updated three files. Forgot the fourth.

# Controller (the silent killer)
def user_params
  params.require(:user).permit(:email)  # ← Forgot :phone, :bio
end

<%# View (looks fine) %>
<%= f.text_field :phone %>
<%= f.text_area :bio %>

# Service (validates fields that never arrive)
class UpdateUserService
  validates :phone, presence: true
  validates :bio, length: { maximum: 500 }
end

The dispersed architecture: View defines fields. Controller filters params. Model validates data. Service enforces business rules. Four files. Four places for drift.

The paradox: I extracted business logic to make it testable. But the test passed because it used a hash, not controller params. Production failed because params filtering happened before the service.

Service objects don't solve params drift. They just move where you forget to update things.

I patched it. Happened again next month with a different field. And again.

Why was I settling for this? Because everyone else was. We'd normalized the sanity tax.

The Unified Contrast: Form as a Solid Thing

The structure of submitted parameters mirrors the structure of the form. They aren't separate concerns - they're different states of the same contract. In the Handler+Form approach, this entire bug class disappears:

class UpdateUserForm < ActionForm::Base
  element :email { output type: :string, presence: true }
  element :phone { output type: :string, presence: true }
  element :bio { output type: :string, length: { maximum: 500 } }
end

One file. One source of truth.

The form defines its fields (UI)
The form defines validation (contract)
The form auto-generates the params schema (security)
The handler uses the form (business logic)

When you add a field, you add it in one place. The params filtering, the validation, and the UI are no longer three separate responsibilities that can drift—they're a unified declaration.

The test change: Instead of mocking four layers and hoping they align, you test the form as a cohesive unit. If the form test passes, the integration works. No archaeology required.

The Lifecycle: How the Solid Form Actually Works

Here's the mechanical flow that eliminates the drift:

Step 1: Handler defines the form template (class definition)

class UsersHandler < SteelWheel::Base
  def form_class
    UpdateUserForm  # The template
  end
end

Step 2: GET request — Create empty form instance

@form = UsersHandler.form_class.new(object: @user)
# Form renders itself with current user data

Step 3: User populates form — Browser submits params

Step 4: POST request — Form creates params instance from params template (which is reflection of form structure) and user's inputs

@params = UsersHandler.form_class.params_definition.new(params)
# Auto-generated schema validates input

Step 5: Validation feedback — Create form with errors

@form = @params.create_form(object: @params)
# Form instance now contains validation errors
# Renders itself with inline error messages

The key insight: The form is both the UI definition and the params schema generator. When you add a field to the form, you simultaneously:

Define its rendering
Define its validation
Auto-generate its params filter

No drift. No archaeology. One solid thing.

The Reformation: SteelWheel as Validation Machine

Here's what changed when I stopped treating service objects as "a call method in a void" and started using structured handlers:

# app/handlers/products/create_handler.rb
class Products::CreateHandler < ApplicationHandler
  # 1. URL validation (400 Bad Request if wrong)
  url_params do
    string :format
  end

  # 2. Form binding (generates params validation automatically)
  form Products::ModelForm

  # 3. Dependency validation (404 if missing)
  finder :category, -> { Category.find_by(id: form_params.category_id) }

  # 4. Form params validation (422 if invalid)
  # form_params automatically validated by form definition

  # 5. Business logic (only runs if all validation passes)
  def on_validation_success
    call if current_action.create?
  end

  def call
    product = Product.create!(form_params.to_h)
    add_to_stock(product)
    notify_team(product)
  end

  private

  def add_to_stock(product)
    PointOfSale.find_each do |pos|
      PosProductStock.create!(pos: pos, product: product, on_hand: 0.0)
    end
  end

  def notify_team(product)
    ProductMailer.created(product).deliver_later
  end
end

# Controller becomes declarative traffic cop
class ProductsController < ApplicationController
  action :new, handler: :create do |handler|
    @product = handler.product
    @form = handler.form
  end

  action :create do |handler|
    handler.success { redirect_to handler.product }
    handler.failure { @product = handler.product; @form = handler.form; render :new }
  end
end

What's different?

Not just "business logic extracted." The entire validation hierarchy is explicit:

URL params (400): Wrong format, invalid action
Dependencies (404): Resource doesn't exist
Form params (422): Invalid data format
Business logic: Only runs if 1-3 pass

Service objects collapse all of this into if result.success?

You can't tell if it failed because of invalid params, missing dependencies, or business logic. One bucket. Manual error handling everywhere.

Handlers separate concerns by HTTP semantics. Different failure modes get different responses.

Leveling Up: The Validation Hierarchy I Was Missing

Let me show you why this matters.

With service objects:

result = CreateProductService.new(params, current_user).call

if result.success?
  redirect_to result.product
else
  # result.error could be:
  # - "Unauthorized"
  # - "Invalid params"
  # - "Category not found"
  # - "Product already exists"
  # - Model validation errors
  #
  # All failures look the same. How do I respond?
  # Manual conditionals everywhere.

  flash[:error] = result.error  # ← String? Hash? Object?
  render :new
end

With handlers:

action :create do |handler|
  # url_params invalid? → 400 (automatic, before block runs)
  # category not found? → 404 (automatic, finder fails)
  # form_params invalid? → 422 (automatic, form validation fails)

  handler.success { redirect_to handler.product }  # ← Only business logic success
  handler.failure { render :new }  # ← Form errors automatically in @form
end

The mechanics:

400: Client sent garbage → reject before processing
404: Resource doesn't exist → can't proceed
422: Data format wrong → validation errors
200: Everything valid, business logic executed

Service objects treat all failures as equal. You manually sort them out.

Handlers treat failures by HTTP semantics. The framework sorts them out.

This isn't just cleaner code. It's correct failure modes mapped to HTTP semantics.

I spent years writing manual conditionals to distinguish these cases. The hierarchy was always there—I just wasn't making it explicit.

The Symmetry Revelation: One Handler, Multiple Actions

Here's a paradox I lived with for years:

new and create are two sides of the same coin. Same domain concept. Same data format. Same setup.

Yet I treated them as separate silos:

# Traditional approach
def new
  @product = Product.new
  @category = Category.find(params[:category_id])
  authorize @product
  setup_defaults(@product)
end

def create
  @product = Product.new(product_params)
  @category = Category.find(product_params[:category_id])  # ← Duplicated
  authorize @product  # ← Duplicated
  setup_defaults(@product) if @product.valid?  # ← Duplicated

  if @product.save
    redirect_to @product
  else
    render :new
  end
end

# With service objects
class CreateProductService
  def initialize(params, current_user)
    @params = params
    @current_user = current_user
    @category = Category.find(params[:category_id])  # ← Still duplicated
    authorize!  # ← Still duplicated
  end

  def call
    product = Product.new(product_params)
    # ...
  end
end

# But NEW action still does all the setup separately
def new
  @product = Product.new
  @category = Category.find(params[:category_id])  # ← STILL DUPLICATED
  authorize @product  # ← STILL DUPLICATED
end

Service objects don't fix this. They only handle create. new still duplicates setup.

Why? Because we think of them as separate actions. But they're not:

new (GET): Display the contract
create (POST): Fulfill the contract

Same contract. Same setup. Same handler.

class Products::CreateHandler < ApplicationHandler
  form Products::ModelForm

  finder :category, -> { Category.find_by(id: url_params.category_id || form_params.category_id) }

  verify memoize def product
    Product.new(form_params.to_h)
  end

  def on_validation_success
    call if current_action.create?  # ← Only execute on POST
  end

  def call
    product.save!
  end
end

# Controller
action :new, handler: :create do |handler|
  @product = handler.product  # ← Same product setup as create
  @form = handler.form        # ← Same form
  @category = handler.category  # ← Same category finding
end

action :create do |handler|
  handler.success { redirect_to handler.product }
  handler.failure { render :new }
end

One handler. Two actions. Zero duplication.

Category finding happens once. Authorization happens once. Product setup happens once.

new displays the form. create executes the logic. But they share the exact same soul and data contract.

This applies to show/edit/update/destroy too—one UpdateHandler for all four.

I spent years treating these as separate because controllers made me think in actions. Handlers made me think in domain operations.

The Declarative Traffic Cop

The controller becomes a declarative traffic cop:

# Before: Imperative coordination
def create
  @product = Product.new(product_params)  # ← Manual setup
  @category = Category.find(params[:category_id])  # ← Manual dependency

  authorize @product  # ← Manual authorization

  if @product.invalid?  # ← Manual validation
    @errors = @product.errors
    render :new
    return
  end

  if @product.save  # ← Manual persistence
    add_to_stock(@product)  # ← Manual side effects
    notify_team(@product)
    redirect_to @product
  else
    render :new
  end
end

# After: Declarative delegation
action :create do |handler|
  handler.success { redirect_to handler.product }
  handler.failure { render :new }
end

The controller doesn't coordinate. It delegates to a handler that has an explicit validation hierarchy.

The handler doesn't just execute business logic. It defines the entire contract:

What URL params are valid
What dependencies are required
What form data is expected
What business logic runs

The form generates params validation. Change the form, params update automatically.

No drift. One source of truth. Impossible to forget.

Service objects got me halfway: "extract business logic." Handlers finished the job: "make the contract explicit and automatic."

Completing the Abandoned Task: The Infrastructure We Forgot

Let's examine what the community actually did.

2012-2014: "Fat controllers are bad"
2015-2017: "Service objects are the answer"
2018-2020: "Wait, this still doesn't solve params drift / validation scatter / duplication"
2021-2026: ...crickets...

We identified the problem. We started the solution. Then we stopped before building the infrastructure.

Service objects are POROs. "Plain Old Ruby Objects." By definition: no framework support.

Which means:

No standard interface (everyone invents their own)
No automatic params generation (manual drift)
No validation hierarchy (one if statement for everything)
No form integration (still writing ERB)
No action grouping (still duplicating new/create)
No HTTP-semantic error handling (strings everywhere)

We called this "simplicity." It's not simplicity. It's incompleteness.

The "Rails Way™" didn't evolve because addressing these requires admitting:

Forms should generate their own params (tight coupling is good here)
Validation has a hierarchy (URL → Dependencies → Form → Business)
Related actions share a contract (new/create are one operation)
Controllers should be declarative, not imperative

This challenges core Rails assumptions.

So we lived with params drift. We duplicated setup. We manually sorted failure modes. We called it "pragmatic."

But it's not pragmatic when your app grows past 50 controllers and you're debugging params drift every month.

Is it time to admit traditional Rails patterns fail when the domain gets messy? And finally finish the architectural work we started?

The Half-Finished House Analogy

Refactoring with handlers is like moving into a house where the previous owners (the community) put up beautiful framing for "Thin Controllers" but left before installing the plumbing or the roof.

I spent years getting wet every time it rained (params drift, validation inconsistency, duplication bugs), calling it "minimalism," until I realized: properly applied architecture isn't over-engineering. It's finishing the house.

The framing (service objects):

Extract business logic ✓
Make it testable ✓

The plumbing (handlers):

Explicit data contract (form + params)
Structured validation hierarchy (400/404/422/200)
Action grouping (one handler, multiple actions)
Automatic params generation (no drift)

The roof (complete infrastructure):

Declarative controllers (traffic cops)
Form-driven development (contract-first)
HTTP-semantic error handling
Zero duplication by design

Service objects got us the framing. Handlers install the plumbing and roof.

You can live in a house with just framing. I did, for years. But you'll get wet when it rains. And eventually you'll wonder: why am I tolerating this?

The Paradox We Ignored

Here's the final paradox:

We extracted business logic to "simplify."

But we left the contract implicit, validation scattered, params manual, and actions duplicated.

The extraction didn't simplify. It just moved complexity around.

Handlers complete the simplification:

Contract explicit (form)
Validation structured (hierarchy)
Params automatic (generated)
Actions grouped (shared context)

True simplicity isn't "less code." It's explicit constraints that prevent entire classes of bugs.

I spent six years learning this. Maybe you can learn it faster.

Resources

SteelWheel - Handler framework
ActionForm - Form DSL
EasyParams - Type-safe parameters
Real App - Production example

If you're still living under the tarp, ask yourself:

Is params drift acceptable? Is validation scatter acceptable? Is new/create duplication acceptable?

Or is it time to finish installing the plumbing?

The framing has been up for a decade. Let's finish the house.

DEV Community: andriy-baran

FormBuilder Proxy vs Template Method

The Pattern Conflict

1) The Pattern Conflict: Proxy vs Skeleton

2) The Source of Truth: Who Owns the Contract?

3) The Algorithm vs the Toolbox

4) Surgical Overrides: Override a Step, Not a Document

5) The "Params Drift" Paradox

The Form Elements DSL

Element Methods: Behavior as Code

6) Composition vs Helpers

7) Handling Nesting: From Manual Chore to Structured Algorithm

8) Error Integration: Errors as a Built-In Phase

9) The 6-Year Verdict

The "Industrial Assembly Line" Metaphor

Resources

Constructor Hell: Replacing Dependency Injection with Chain of Responsibility in Ruby

The Hook: The One-Line Change That Touched Five Files

The Constructor Hell Reality: "Pure" DI is a Trap

The False Choice: Sledgehammer vs. Spaghetti

The Browser Epiphany: Why Does JS Bubble?

Stop Passing Context. Start Requesting It

The Tree Duality: Composition Goes Both Ways

Transparent Structures: Runtime Specialization Without the Pain

The owner_ Signal: Magic With Intent

The Sharp Edges (and Why It's Still Worth It)

The Chain of Responsibility: A Multi-Level Power Grid

The DX Shift: Vibe Coding Without the Weight

Resources

The Service Object Graveyard: Why Your POROs Failed and Handlers Won

The Hook: A PORO Mustache on a Fat Controller

The Vibe Coding Reality: We Walked Halfway and Stopped

The Sanity Tax: Settling for Params Drift

The Unified Contrast: Form as a Solid Thing

The Lifecycle: How the Solid Form Actually Works

The Reformation: SteelWheel as Validation Machine

Leveling Up: The Validation Hierarchy I Was Missing

The Symmetry Revelation: One Handler, Multiple Actions

The Declarative Traffic Cop

Completing the Abandoned Task: The Infrastructure We Forgot

The Half-Finished House Analogy

The Paradox We Ignored

Resources

The `owner_` Signal: Magic With Intent