DRY principle form validations

Rails
21

On Thu, 16 Mar 2006 19:17:06 +0100, Cody S. wrote:

How would we get a project off the ground to implement this type of
generation?

Typically, for new, highly-desirable Rails functionality like this,
three
to six programmers would go off and create their own, vaguely
incompatible,
orthogonally incomplete implementations - one or two as a generator, a
few
plugins, and at least one engine. For best effect, they should all be
named similarly.

Jay L.

22

Adam.Cooper wrote:

That sounds about right for my impression of the rails community.

Instead of a DRY principle we really should have something like a DRYOO
where its Don’t Repeat Yourself Or Others principle. (or some other
cuter
variation.)

I would really like to see this feature and I could see a lot of people
using it but lets hope its done right instead of the 10 login generators
which 90% are out of date and dead.

Adam

Getting it organized under one project is kind of what I’m hoping for
here. Get the guys who are interested in actually putting together a
generator or engine or plugin under just one project. Get them to agree
on a design, and begin implementation.

I know, that’s just a little too much to ask, but it works better when
everyone contributes to the same effort. :o)

Is anyone interested in actually doing this?

23

Avdi G. wrote:

Get the guys who are interested in actually putting together a
generator or engine or plugin under just one project.

Can I add “patch” to this list? It seems like the sort of thing that
might be appropriate in the Rails core.

Is anyone interested in actually doing this?

Sadly, by the time I bone up on Javascript enough to make myself
useful to this effort, I’m afraid it will be long-solved…

~Avdi

The AJAX in Action book is about an inch thick. Not exactly a weekend
read! :o)

24

Struts is actually using commons-validator from the Apache Jakarta
project… and I hate
to say it, but I don’t think it’s very dry.

It has an xml configuration file into which you can put your javascript
validations (in
CDATA tags) or it can link to the name of a javascript file in the
package structure
(that’s what the built-in validations do). This javascript is included
into the jsp page
by use a Struts tag (not sure how you include the javascript if you’re
not using struts).

However, these javascript files are not run on the server side… there
are separate java
classes for that. I’ve always thought this isn’t the best design…
Apache has had the
Rhino javascript engine for years; they could have used that. And now,
Java 6 is going to
introduce script handling (javascript, php, and ruby! I believe). I hope
they get around
to a re-write after that.

Anyway, I agree that having one source for the validation logic would be
ideal.

b

25

Get the guys who are interested in actually putting together a
generator or engine or plugin under just one project.

Can I add “patch” to this list? It seems like the sort of thing that
might be appropriate in the Rails core.

Is anyone interested in actually doing this?

Sadly, by the time I bone up on Javascript enough to make myself
useful to this effort, I’m afraid it will be long-solved…

~Avdi

26

This is bit off topic, but…

I’m not that crazy about pushing almost any kind of logic onto the data
store. IMO, rules should be delegated to the middle tier. Any logic
you put into the data store has to be replicated if you switch to a
different database engine.

At a previous job, we supported three or more database engines at a time
on the same middle tier. As long as we kept rules in the middle tier,
supporting a different database engine was almost trivial.

Our earlier architecture contained stored procedure, constraints,
triggers, etc, and we were completely bound to one db vender as a
result.

27

Take also look at known attempts: http://dev.rubyonrails/ticket/861 and
http://www.schuerig.de/michael/boilerplate/

Ben M. wrote:

Anyway, I agree that having one source for the validation logic would be
ideal.

Well, SQL allows to define fairly good amount of constraints over table
attribute values - I think it’s a good place for single source of
validation logic.

Here’s list of possible SQL constraint and some thoughts about
complexity of Ruby(or JS) code to perform validations before sending
data to server:

  1. NOT NULL - trivial

  2. STANDARD TYPE (numeric, string, boolean, date, time, etc.) -
    validation as check if presentation format allows value to be correctly
    type-casted can be quite easily performed.

  3. VALUE LIMITS (sizes of varchar, numeric) - trivial

  4. CHECK CONSTRAINTS - are the most complex, as can include calls to
    standard functions (length(), current_date, trim, etc.), operators(+,
    -, /, * etc.), comparisons( <, >, ==, !=, between etc.), set inclusion
    (in, not in), regular expression matches (=~, !~), logical operations
    (OR, AND, NOT), nested expressions, and refer to SEVERAL columns at once
    (say, ‘CHECK ( gross_price >= net_price )’ ) - and that’s only brief
    overview :)))

Ideal solution would be to declare ALL constraints in SQL DDL and when
retrieving model metadata a code generator would inject appropriate
methods to model class, thus deriving validations directly from
constraints and produce JS code for client-side validations.