Alternate Style of Validations

rubyonrails-talk
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

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

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

4

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).

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

@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!

6

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).

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 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

>> 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). > 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.

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

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.

10

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

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.

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.

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)