lukesutton

Warden::Manager.serialize_into_session{|user| user.id }
Warden::Manager.serialize_from_session{|id| User.get(id) }
 
Warden::Manager.before_failure do |env,opts|
  # Sinatra is very sensitive to the request method
  # since authentication could fail on any type of method, we need
  # to set it for the failure app so it is routed to the correct block
  env['REQUEST_METHOD'] = "POST"
end
 

jasoncodes

class CreateItemChildrenCountView < ActiveRecord::Migration
  def self.up
    execute <<-SQL
      CREATE VIEW item_children_count AS
      SELECT parent_id AS item_id, COUNT(*) as children_count
      FROM items GROUP BY parent_id;
    SQL
  end

  def self.down

sundbp

# Buidling blocks to support injectionless DCI
require 'rubygems'
require 'active_support/core_ext/string/inflections'
#require 'pry'

module ContextAccessor
  def context
    Thread.current[:context]
  end
end

marksim

I'm not sure how to remove the dependency on VerificationMailer without pushing it into the profile model and making the model suddenly care about how to mail verifications.

I WANT to remove it so I don't have any need to load up rails when running the tests, but also want to keep my models sensible and without a lot of knowledge of business logic.

Example usage:

profile = Profile.find(1)
profile.extend Verifier

profile.verify(email: 'myemail@example.com')

rapimo

SELECT hstore(array_agg(v), array_agg(c::text)) FROM (
SELECT v, COUNT(*) as c ,1 as agg from  unnest(ARRAY['foo','bar','baz','foo']) v GROUP BY v) t
GROUP BY agg

--> "bar"=>"1", "baz"=>"1", "foo"=>"2"

practicingruby

Models, Roles, Decorators, and Interactions

A modest alternative to DCI that might be worth further thought

One of the problems with advancing the discussion on DCI is that we lack a comparable alternative pattern that has the same goals, but favors a low ceremony approach. The closest thing we have to that is Rails concerns, but they are more like distant relatives of the DCI concepts rather than first cousins, and that makes comparisions between the two approaches not especially fruitful.

I am considering the idea of experimenting with my own paradigm that captures the intent and purity of DCI, but with the convenience of concerns. Please note that this is just the starting point of a conversation, it is NOT a promise of comercially available cold fusion or a cure for cancer. It's just a gist with an idea on it I'd like to hear your thoughts on.

What if we had a top-level topology that was split into Models, **Rol

blaix

On Tue, Mar 12, 2013 at 1:26 PM, Martin Fowler martinfowlercom@gmail.com wrote:

The term pops up in some different places, so it's hard to know what it means without some context. In PoEAA I use the pattern Service Layer to represent a domain-oriented layer of behaviors that provide an API for the domain layer. This may or may not sit on top of a Domain Model. In DDD Eric Evans uses the term Service Object to refer to objects that represent processes (as opposed to Entities and Values). DDD Service Objects are often useful to factor out behavior that would otherwise bloat Entities, it's also a useful step to patterns like Strategy and Command.

It sounds like the DDD sense is the sense I'm encountering most often. I really need to read that book.

The conceptual problem I run into in a lot of codebases is that rather than representing a process, the "service objects" represent "a thing that does the process". Which sounds like a nitpicky difference, but it seems to have a real impact on how people us

fj

# In a context somewhere, we'd like to do this:
u = User.new
u.extend Passworded

# Unfortunately, this doesn't work:

module Passworded
  include ActiveModel::Model     # Can't do this because ActiveModel::Model wants to be included
                                 # on classes, not modules.

dhh

# config/routes.rb
resources :documents do
  scope module: 'documents' do
    resources :versions do
      post :restore, on: :member
    end

    resource :lock
  end
end

ludyna

# DCI EXAMPLE IN RUBY (with some prototype elements)
# Blog post: https://www.ludyna.com/oleh/dci-example-in-ruby
# 
# More info: 
#
#   Creator of MVC & DCI, Trygve Reenskaug: DCI: Re-thinking the foundations of 
#   object orientation and of programming
#   http://vimeo.com/8235394
#
#   James Coplien: Why DCI is the Right Architecture for Right Now