Rails plugins and libraries / Model-level / Validation

From WhyNotWiki

Contents 1 Validation Reflection 2 ValidationReflection (by Yossef) 3 Validates Unchangeable 4 validates_as_email 5 validates_email_format_of 6 Before Assignment: add a before_assignment callback to a belongs_to association 7 Name Nanny

[edit] Validation Reflection

Rating:
Categories/Tags:	[Validations (category)]
Documentation:	Readme
Source code:	svn://rubyforge.org//var/svn/valirefl/validation_reflection/trunk http://www.schuerig.de/michael/rails/validation_reflection/
As listed in other directories:	http://agilewebdevelopment.com/plugins/validation_reflection http://rubyfurnace.com/plugins/validation_reflection
Authors:	Michael Schuerig

http://agilewebdevelopment.com/plugins/validation_reflection

This plugin provides reflective access to validations

• ModelClass.reflect_on_all_validations
• ModelClass.reflect_on_validations_for(:property)

[edit] ValidationReflection (by Yossef)

Homepage:	http://www.rubybyraeli.org/blog/articles/2007/04/06/36-reflections-on-validity
Authors:	Yossef

Yossef (April 06, 2007). Reflections on Validity (http://www.rubybyraeli.org/blog/articles/2007/04/06/36-reflections-on-validity). Retrieved on 2007-05-11 11:18.

[...] All of these are covered by the Rails built-in validation helpers, but there’s a bit of a catch. That catch is reflection.

Ruby is one of those languages where reflection abounds. Rails, built with Ruby, takes advantage of this fact in some areas. It does not, however, when it comes to validation. And that’s yet another problem I have with how Rails handles validation. It’d be so wonderful if there was validation reflection. It’d be so nice to just query a model to see what it considers valid. It’d make a lot of interface problems easier to deal with. It’d make things more DRY. This idea started my journey into the bowels of ActiveRecord validation.

My first step this time was to see if anyone else had looked into this. It turns out Michael Schuerig did. He wrote a validation reflection plugin that seemed nice, but it wasn’t exactly what I wanted. That problem seems to come up from time to time. Is it me or everyone else? So I built on his idea, learning a good bit in the process, and came up with something that did what I wanted.

...

Some of the differences are cosmetic or more on the line of “syntactic sugar”. [...] And one of the differences is just something I wanted to make it a little more explicit. Where he used a plain MacroReflection object, I created a new class specifically for this purpose: ValidationReflection.

module ActiveRecord::Reflection
  class ValidationReflection < MacroReflection
    attr_accessor :block alias_method :klass, :active_record
    alias_method :attr_name, :name
    alias_method :validation, :macro
    alias_method :configuration, :options
  end
end

As you can see, it’s pretty much the same thing with a few aliases added for convenience. Even if that was the only difference, I’d want to have this class. It’s explicit. I lets me know exactly what type of reflection this is. I mean, there are AssociationReflection and AggregateReflection, so why use the abstract class for validations? I think they deserve more. And, of course, there’s more to this class. It includes another attribute, the block of code that composes this validation. The actual Proc object is stored within the reflection. But why?

Most of my problems with validation have to do with the messiness under the surface. Nothing (Hardly anything) is done centrally. Each individual validation repeats much of the same work done by all the rest: get the options, explicitly get the default message, create a block of code, do something to install the block of code. The actual validation process (simplified somewhat) involves getting a list of these blocks of code, running them, and checking for errors. There’s really no tie between validation-as-idea and validation-as-code. I mean, look at how validations are stored internally.

...

[edit] Validates Unchangeable

Have used:	no
Rating:
Homepage:	http://locusfoc.us/2007/2/1/validates_unchangeable-plugin
Source code:	svn://svn.locusfoc.us/plugins/trunk/validates_unchangeable
As listed in other directories:	http://rubyfurnace.com/plugins/validates_unchangeable

http://rubyfurnace.com/plugins/validates_unchangeable

Sometimes you want to allow users to save data only once to a field. For example, Ebay only allows you to change the price of an item if there are no bids and it is within a certain date range. I created the validates_unchangeable for similar situations.

[edit] validates_as_email

Have used:	yes
Rating:
Source code:	https://svn.greenpeace.org/repositories/rails_plugins/validates_as_email
Authors:	Ximon Eighteen, Dan Kubb, Thijs van der Vossen

[edit] validates_email_format_of

Have used:	no. How does this compare to validates_as_email??
Homepage:	http://multi-up.ca/code/
Source code:	http://multi-up.ca/code/validates_email_format_of/
As listed in other directories:	http://rubyfurnace.com/plugins/validates_email_format_of
Authors:	Alex Dunae

http://rubyfurnace.com/plugins/validates_email_format_of

Validate email addresses against RFC 2822

[edit] Before Assignment: add a before_assignment callback to a belongs_to association

Source code:	http://obiefernandez.com/svn/plugins/before_assignment
As listed in other directories:	http://rubyfurnace.com/plugins/before_assignment http://wiki.rubyonrails.org/rails/pages/Model+Extensions
Description:	* Adds support for a before_assignment callback to belongs_to relationships. Allows validation of the object being assigned to the relationship at the time of assignment, instead of having to depend on validations or before_save callbacks on the parent object. Complements the :conditions option of belongs_to

http://rubyfurnace.com/plugins/before_assignment

Plugin makes it possible to add a before_assignment callback to a belongs_to association, which enables things such as type and validity checking at the time of assignment instead of having to rely on later validation.

The idea came up while researching the :conditions option for belongs_to. I realized that Rails doesn’t prevent you from assigning a bogus value—even worse, you will be confused when you try to retrieve it later and nothing is there.

Some caboosers argued that this is not needed, because you can check the validity of the assignment as part of the validation rules for the model with the belongs_to association. To which I say: “Not always!”

Sure, there might be cases where it makes sense to check the validity of an assignment to belongs_to as part of the validation routines of the model. But in cases where a wrong assignment is NOT a state that is reachable normally by the end user, then I believe that it is better to fail fast!

If there is a programmer error or a hacker trying to breach my security, I want to know about it right away and in an explicit fashion.

Example:

class Approvable < ActiveRecord::Base
  belongs_to :approver,
             :class_name => 'User',
             :foreign_key => 'approver_id',
             :conditions => ['authorized_approver = ?', true],
             :extend => CheckApproverExtension  
end

module CheckApproverExtension
  def before_assignment(approver) 
    raise UnauthorizedApproverException unless approver.authorized_approver 
  end
end

Note: Rails (as of rev 5523) supports extension (:extend =>) of a belongs_to association, but it isn’t documented. I believe that it’s perfectly valid to extend a belongs_to relationship, and that belongs_to should accept a block parameter for extension methods, exactly how other associations do.

[edit] Name Nanny

Categories/Tags:	[Censoring (category)] [Filtering offensive content (category)] [Bleeping (category)] (Useful for but not limited to: [Users (category)] [Sign-up forms (category)] [User registration/enrollment (category)])
Homepage:	http://locusfoc.us/2007/2/13/name-nanny-plugin
Source code:	svn://svn.locusfoc.us/plugins/trunk/name_nanny/
As listed in other directories:	http://rubyfurnace.com/plugins/name_nanny

http://locusfoc.us/2007/2/13/name-nanny-plugin

I needed functionality to encourage user’s to be on their best behavior when they choosing a username or filling out a form. Bad behavior can come in many forms but specifically, I wanted to prevent people from registering usernames like “administrator”, “root”, “abuse”,”support” etc. I also didn’t want people to pick names like “whore” or even “hoar”,”h0ar”,”wh0r3” (you get the picture). It occurred to me that others would like this functionality too, so I created the name_nanny plug-in which can be employed in a couple of ways.

In the model you can use:

  validates_wholesomeness_of :login

This will check the login against values in two text files in the plug-in directory “badwords.txt”, and “restrictedwords.txt”. By default a match returns an non-descript error like “this username is already taken”. I chose a generalized error to dissuade users from trying to hack around the filter and find a word i missed.

If you are filtering the body of text you may want to allow words like “administrator” in the body of the document. Therefore namenanny has a second method called “bleeptext”, which you can use thusly:

  def before_save
    %w(description, title, author, tags).each do |column| 
      if self[column.to_sym]
        self[column.to_sym] = bleep_text(self[column.to_sym])
      end
    end
  end

A sample output might look like this:

p = Post.new
p.description = "Step two: put your dick in a box."
p.save
puts p.description # => "Step two: put your bleeep in a box."