Alternate Style of Validations

Rails
1

I’m not fond of Rails’ style of validation where one rule is followed
by many fields.

Trying to determine the rules of any one field is rather tedious with
this setup.

I’d rather have one field, followed by many rules.

Anyone know if someone has already written something to do it that
way? If not, I think I’ll take a crack at it. It would likely look
something like this:

validates_field
‘field_name’, :isRequired, :isAlphaNumeric, :hasMaxLength => 10

Which would ultimately just translate and inject definitions into
Rails’ existing internal structure, but at least I can read it field
by field (and with a number of explicit easier-to-read keywords I’ll
borrow from my past work).

– gw (www.railsdev.ws)

2

On Nov 25, 2007, at 12:13 PM, Josh S. wrote:

way? If not, I think I’ll take a crack at it. It would likely look
If all you want is greater readability, just arrange your

default.)
Yeaaah, but it’s not the same. Not as compact.

validates_field ‘email’, :isRequired, :hasLength=>
(6…255), :isEmail, :isUnique
validates_field
‘handle’, :hasMinLength=>3, :isUnique, :isAlphaUnderscore
validates_field ‘password’, :isPassword

This is how I did validations in my own framework. I have a bunch of
common isX & hasX and then of course the type of regex options that
Rails depends on as well. It looks more cramped in email than in
code, but I find it fairly quick to read and write (and with
predefined formats, there’s far less regex to trip over).

This is probably going to be my first crack at a plugin, but I’m
going to have to figure out how to translates to and inject into
Rails’ native storage for validations.

– gw (www.railsdev.ws)

3

Greg W. wrote:

I’m not fond of Rails’ style of validation where one rule is followed
by many fields.

Trying to determine the rules of any one field is rather tedious with
this setup.

I’d rather have one field, followed by many rules.

Anyone know if someone has already written something to do it that
way? If not, I think I’ll take a crack at it. It would likely look
something like this:

validates_field
‘field_name’, :isRequired, :isAlphaNumeric, :hasMaxLength => 10

Which would ultimately just translate and inject definitions into
Rails’ existing internal structure, but at least I can read it field
by field (and with a number of explicit easier-to-read keywords I’ll
borrow from my past work).

If all you want is greater readability, just arrange your validations by
field.

Here’s an example:

validates_presence_of :email
validates_length_of :email, :in => (6…255)
validates_format_of :email, :with => VALID_EMAIL_REGEXP
validates_uniqueness_of :email # used for unique login
identifier

validates_length_of :handle, :allow_nil => true, :minimum => 3
validates_format_of :handle, :allow_nil => true, :with =>
/\w+/
validates_uniqueness_of :handle, :allow_nil => true

validates_confirmation_of :password

(Seeing it that way, I really get the idea that :allow_nil should be the
default.)

–
Josh S.
http://blog.hasmanythrough.com

4

On Nov 25, 12:38 pm, Greg W. [email protected] wrote:

something like this:

validates_field
‘field_name’, :isRequired, :isAlphaNumeric, :hasMaxLength => 10

Which would ultimately just translate and inject definitions into
Rails’ existing internal structure, but at least I can read it field
by field (and with a number of explicit easier-to-read keywords I’ll
borrow from my past work).

Making up new keywords from your past work is fine if you are the only
one who
will have to read this code. But you will slow understanding for all
the
developers who read AWDWR and are familiar with the standard names.
Also, your use of camelCase is non-standard and will make other Ruby
programmers
think you are just an unreformed Java hacker.

5

On Nov 25, 12:38 pm, Greg W. [email protected] wrote:

I’m not fond of Rails’ style of validation where one rule is followed
by many fields.

Trying to determine the rules of any one field is rather tedious with
this setup.

I’d rather have one field, followed by many rules.
…

Well, once ou use :format, there isn’t much need for any of the
others, but…

This took about ten minutes to write and test:

#===Example

validates_field :some_field, :presence, :format => { :with => /w

+/ }, :length => { :minimum => 3 }

# is equivalent to:

validates_presence_of :some_field

validates_format_of :some_field, :with => /w+/

validates_length_of :some_field, :minimum => 3

class ActiveRecord::Base
def self.validates_field(field_name, *args)
args.each do |arg|
case arg
when Hash
arg.each do |key, value|
self.send(“validates_#{key}of", field_name, value)
end
else
self.send("validates#{arg}_of”, field_name)
end
end
end

6

On Nov 26, 2007, at 1:33 PM, kevin cline wrote:

way? If not, I think I’ll take a crack at it. It would likely look
something like this:

validates_field
‘field_name’, :isRequired, :isAlphaNumeric, :hasMaxLength => 10

Which would ultimately just translate and inject definitions into
Rails’ existing internal structure, but at least I can read it field
by field (and with a number of explicit easier-to-read keywords I’ll
borrow from my past work).

This took about ten minutes to write and test:

Cool. I started someting similar, but the send idea was a good one
that should help finish the exepriment. Thanks for exploring it for me.

Making up new keywords from your past work is fine if you are the only
one who will have to read this code. But you will slow
understanding for all
the developers who read AWDWR and are familiar with the standard
names.

But once they use my way, I’ll speed them up because they won’t spend
five minutes mentally compiling what all the rules are for a given
field by hunting through all those inverted rules, and they won’t
spend time deciphering, remembering, and making typos in their regexs
for the common stuff. Regex is handy, but it’s a speed bump every
time you have to read it or write it.

Rails has lot sof neat stuff. Rails isn’t perfect. So, I’m working my
way through it and trying to decide where I need to spend time
filling in holes and providing alternatives that I think are better
from my past work. Some is just different, but a few I believe I had
better. I understand the advantages sticking to what’s provided, but
I think this is an area worth improving. The current method is quite
cumbersome to read, write, and maintain IMO.

Also, your use of camelCase is non-standard and will make other Ruby
programmers think you are just an unreformed Java hacker.

I’ve never liked underscore words. A line of rails code feels like
someone took a shot gun to it and filled it full of holes. Can’t tell
where phrases stop and start because it’s so full of empty spaces.
Not to mention how awkward it is to type. Conforming is fine (I
understand the advantages), but I hate that I have to conform to
something so ugly.

Right now I’m focused on just learning how Rails and Ruby do their
thing. Trying to do that and switch all my styles isn’t working –
functionality first, style second once I get used to thinking in Ruby.

I’ll conform by the time I publish something.

– gw (www.railsdev.ws)

7

I’ve never liked underscore words. A line of rails code feels like
someone took a shot gun to it and filled it full of holes. Can’t tell
where phrases stop and start because it’s so full of empty spaces.
Like a line of text in english ? :slight_smile:
ImGladCamelCaseNeverCaughtOnForEmail

Not to mention how awkward it is to type. Conforming is fine (I
understand the advantages), but I hate that I have to conform to
something so ugly.

pure opinion - I personally can’t abide camelcase once you get past
about 2 words, I find the lack of spaces makes it hard to read.

Fred

8

On Nov 26, 4:35 pm, Greg W. [email protected] wrote:

Rails’ existing internal structure, but at least I can read it field
the developers who read AWDWR and are familiar with the standard
way through it and trying to decide where I need to spend time
someone took a shot gun to it and filled it full of holes. Can’t tell
where phrases stop and start because it’s so full of empty spaces.
Not to mention how awkward it is to type.

That’s your editor’s fault. Get a better editor, or customize the one
you are using.
Since ruby does not use the semicolon, I customized mine to map
semicolon to underscore.
Now it’s easier for me to type an underscore than a capital letter.

Conforming is fine (I understand the advantages), but I hate that I have to conform to
something so ugly.

After a while, you will get used to it, and it won’t seem so ugly.
And if you go against standard
practices, the inconsistency between your code and the library code
will be even uglier.

9

@Greg:

You can pretty much do whatever you want in Ruby, as countless plugins
can
prove.

However, a major beneift to developing with Rails is that you have a
standard domain-specific language provided already. I can look at three
separate apps, made by three separate developers, and I can be up to
speed
with what they are doing really quickly provided they all followed the
Rails
conventions. I can’t do that with “Jim’s Custom PHP Framework.”

Don’t think of it as opinionated software - I hate that term.
Consistancy,
conformity, etc free me up to solve my clients’ problems. I could focus
on
writing a plugin or extention to make my code more pleasing to my eyes,
but
instead I choose to implement a new bit of functionality.

The choice is yours, but if you do develop this new method of
validation,
I’d love to see it.

Good luck!

10

On Nov 26, 2007, at 8:25 PM, kevin cline wrote:

end

end

Yeah, exactly, that kind of stuff.

Regex is handy, but it’s a speed bump every
time you have to read it or write it.

After a bit of practice that bump gets a lot smaller.

Yeah, I’ve used regex a lot, so I don’t find it to be akin to reading
klingon or anything, but I still find it quicker to read these other
versions – and, it’s more DSL-ish :slight_smile:

Page 111 in this PDF http://www.pageblocks.org/downloads/docs/
pbGuide_r8.pdf shows most of the ones I developed. I recently added
some newer ones not in that document.

have overlooked, or by an available plugin.
Agreed. However, I spent over 5 years evolving my own open source
framework extracted from real intranet apps in Gov, Edu, and Com
spaces, publishing hundreds of pages of docs, examples, etc. So
there’s some things I’ve learned and developed from experience as
well. And of course there’s things simply not in rails like Auth. I
know there’s a few auth plugins, but none have the scope of tools I
am accustomed to. So that’s one I’m pretty far along in porting
already. I have probably two more areas that I’ll build up. I had a
pretty nice system for abstracting and minimizing the code needed for
multi-form processes. I also had a pretty nice system for “multi-view-
strings” that provided internationalization, device adaptation, and
multi-facade adaptations to applications with a single simple API
designed to help apps auto-adapt to various dynamic view environments
(languages, PDAs, and hosted apps customized via configs). After
that, I think most stuff is just different, but certainly not worth
replacing.

My biggest challenge wil be in writing these tools to feel at home in
the Rails environment (despite some of the heebie jeebies I get from
Ruby/Rails conventions, I am aware of the advantages to making my
stuff feel Railsy).

– gw (www.railsdev.ws)

11

On Nov 26, 4:35 pm, Greg W. [email protected] wrote:

But once they use my way … they won’t
spend time deciphering, remembering, and making typos in their regexs
for the common stuff.

You should definitely factor out common validations. Here is one way:

class ActiveRecord::Base
def self.validate_as_phone_number field_name
validate_format_of field_name, :with => /\d{10}/
end
end

Regex is handy, but it’s a speed bump every
time you have to read it or write it.

After a bit of practice that bump gets a lot smaller.

Rails has lot sof neat stuff. Rails isn’t perfect. So, I’m working my
way through it and trying to decide where I need to spend time
filling in holes and providing alternatives that I think are better
from my past work.

RAILS has been around for a while and most of the typical uses
are well-supported. Before you spend time “filling in holes” you
should
probably ask more experienced RAILS developers how they would solve
your problem. It may well be that your need is met by a feature you
have overlooked,
or by an available plugin.