Forum: Ruby on Rails How do I? Same Model, Different Controllers, Different Valid

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
3319ab6fb19fcf97c8a3d66b8a9b68bf?d=identicon&s=25 Josh on Rails (Guest)
on 2006-02-02 17:12
(Received via mailing list)
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
42a64442dad4115d8104d5c09289767d?d=identicon&s=25 Simon Robson (Guest)
on 2006-02-02 17:34
(Received via mailing list)
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
0091f92762685860109bbcb02edfdf27?d=identicon&s=25 Alain Ravet (Guest)
on 2006-02-02 17:58
(Received via mailing list)
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
4005a47a8f2ceee49670b920593c1d52?d=identicon&s=25 Ben Munat (Guest)
on 2006-02-02 20:23
(Received via mailing list)
Not getting anything at that link... are you sure it's correct?

b
Ce8b03e5750097942c58e12b46724312?d=identicon&s=25 Giles Bowkett (Guest)
on 2006-02-07 00:26
(Received via mailing list)
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 Robson <simon@intropica.com> 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
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
Giles Goat Boy

http://gilesmakesmusic.blogspot.com
http://gileswritescode.blogspot.com
4005a47a8f2ceee49670b920593c1d52?d=identicon&s=25 Ben Munat (Guest)
on 2006-02-07 02:03
(Received via mailing list)
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 Fowler and Eric Evans about it (Evans used a
bunch of stuff from this in his chapter in the book):

http://www.martinfowler.com/apsupp/spec.pdf

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
Ce8b03e5750097942c58e12b46724312?d=identicon&s=25 Giles Bowkett (Guest)
on 2006-02-07 18:44
(Received via mailing list)
Thanks Ben -- I'm going through the white paper, it looks pretty good.

On 2/6/06, Ben Munat <bent@munat.com> 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
> >>>
> >>Rails@lists.rubyonrails.org
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
Giles Goat Boy

http://gilesmakesmusic.blogspot.com
http://gileswritescode.blogspot.com
This topic is locked and can not be replied to.