in reply to RFC: Verify Interpreter and Language

The perl Web application that I'm working on at the moment replicates validation logic in

I am manually replicating rules across different languages. I'd like is to be able to state these rules at one in place using one language.

Validation often takes you outside your perl comfort zone into other subsystems and languages. Often the same validation rules are replicated in different places using different languages. What a burden!

In short, I kind-of like the idea of a mini-language, and an interpretor, but what would really sell it to me is the added ability to use it as a cross language/platform lowest common denominator - specify my rules once translate it into validation libraries in other languages such as javascript and sql.

  • Comment on Re: RFC: Verify Interpreter and Language

Replies are listed 'Best First'.
Re^2: RFC: Verify Interpreter and Language
by exussum0 (Vicar) on Feb 22, 2006 at 18:00 UTC
    I've implemented the Verify language once. Having done so once, I've thought about translation. It's so small and simple, a lot if open to interpretation when translating it.

    Language translation is easy. Any 1 op maps to 1 or many more. Verify is simple enough, no memory allocation, type saftey and what not, it should be cake. :)

    What kind of db validation beyond unique and fk constraints are you thinking of? I'd advise against DB specific stuff if you can help it, since switching or using a product on another DB isn't your target isn't fun.

[reply]
      Modules such as Class::DBI has wrecked me forever when it comes to low level grovelling through databases with SQL validating primary keys in any language...

      To warrant serious consideration, a validation language it'll need to operate at a similar level of abstraction and portability. I'd like to write... 

        unless(get_Person_Company(:salesperson, :company))
    Return "E_INVALID_SALESPERSON"

      [download]

      ...and remain blithely unaware as to whether this is a cgi-form or an uncommitted database entry.

      The call to accesor get_Person_Company() remains the same.

      I'd agree with acid06's comments that different layers of abstraction is the way to go.

[reply]
[d/l]
        I see what you mean. I had the impression you wanted to embed it in pl/sql, transact-sql or similar. Yeah, the engine is completely seperate from the intended purpose. In my implementation, I created a base context that can be extended to "get stuff" from an object. 
        my $engine = Verify->new();
my $contex = ObjectInspectingVerifyContext->new();
context->set_object($someInput);
my $some_result = $engine->run($context);
...
...
...

        [download]
        I could imagine something like it could be thrown into catalyst as a plugin to validate every request.

        After chatting w/ bart in this thread, I'm coming to the conclusion that the data is valid for use as content vs. if it is correct in context. I regret bringing up checking if a person is valid.

        Is 1-818-287-1283 a valid phone number? Yes. Is it in use? Who knows. Is 82831 a valid zip code? Sure, because the rules for what a zip code is holds true. Is it valid within the context of the united states as a place to mail stuff, maybe not. Is someone's age, "chair"? No, impossible. I don't have to look at their birthdate and do some nasty calculations to figure it out. Assigning "chair" to "age", the content makes no sense. Assigning 50 makes sense in logical terms, just not in the context of any given person.

        Checking whehter something is feasable is very easy. Whether or not it can hold true in context usually takes more work.

        Maybe I'm wrong, and you can explain to me if there is no real deliniation and I'm off my rocker. Thoughts?

        Update: Think deterministic vs non-deterministic programming.

        P.S. I think Acid's main point was, he dislikes mini languages such as , and rather everything be in one language. I don't agree since perl is waaay too powerful (IMHO) for the intended purpose as I explained before.

[reply]
[d/l]

In Section Meditations