How do I? Same Model, Different Controllers, Different Valid

Rails
1

Hi all –

The simple question is: How do I set different validations for the same
Model, when accessed in different Controllers?

Here’s the scenario: I have a store/cart app, with a customer-facing
shopping cart, and a typical Admin side. The Admin side also has an
Order Entry component, where our staff can enter orders received by fax,
telephone, etc. Both the customer-facing cart and the Admin-side Orders
would use the same model (same underlying data) for customer information

  • billing, shipping, etc.

However, the Admin side is intended to be a bit more flexible than the
customer-facing side. For example, we might take international orders by
phone, but not over the Web. Or we might allow payment with
PO/check/cash by an Admin-side order, but not from a Web order.

If I set something like “validate :credit_card_number” in the Model, it
will trigger on the Admin side, requiring a credit card, where I’d
prefer to allow a blank credit card. How do I set per-Controller
validation? Or, is there another, more idiomatic way to approach this
altogether?

– Joshua

2

Hi Josh,

You might want to take a look at some of the ideas in this great article
by Scott Baron:
http://lunchroom.lunchboxsoftware.com/pages/specifications/

I’m facing some similar issues in a project at the moment, and the key
concept is shifting business-logic (or multi-model, context dependent)
restraints out of the largely single-model validation framework in
rails.

Hope the links provides food for thought.

Simon

3

Josh

Using 2 related models is the simplest way :

class Cart < ActiveRecord::Base
   ...  validations for the admin

class PublicCart < Cart
   ...  validations for everybody else

Alain

4

Not getting anything at that link… are you sure it’s correct?

b

5

Any place besides the book he mentions (“Domain-Driven Design”) where
I can find more background about this? It’s an interesting article but
I can’t figure out if he intends specifications to exist solely for
the purpose of making validation easier, or if there’s more to it than
that. Is the goal just to decouple validation from the specification
you’re validating against?

On 2/2/06, Simon R. [email protected] wrote:

Hope the links provides food for thought.

Here’s the scenario: I have a store/cart app, with a customer-facing

Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

–
Giles Goat Boy

http://gilesmakesmusic.blogspot.com
http://gileswritescode.blogspot.com

6

Thanks Ben – I’m going through the white paper, it looks pretty good.

On 2/6/06, Ben M. [email protected] wrote:

an interesting read regardless.

you’re validating against?

concept is shifting business-logic (or multi-model, context dependent)

However, the Admin side is intended to be a bit more flexible than the

[email protected]

Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

–
Giles Goat Boy

http://gilesmakesmusic.blogspot.com
http://gileswritescode.blogspot.com

7

He’s talking about the Specification Pattern, in which you create an
object that handles verification of some group of
objects requirements.

Here’s a paper by Martin F. and Eric Evans about it (Evans used a
bunch of stuff from this in his chapter in the book):

There’s also the site for the book:

http://domaindrivendesign.org/

which unfortunately never really took off, but it does have a 40-page
.doc download that has summaries of the patterns
in the book.

There’s also this site:

http://patternshare.org/default.aspx/Home.DDD.HomePage

with an annoyingly small font size and short summaries of the patterns.

But basically, you should just get the book… at least if you’re going
to be doing fairly big applications. Well, it’s
an interesting read regardless.

b