NHV mappings

[Fabio Maulo]

Hi.

I'm going to add a new way to map validators trough an implementation based on fluent-interface.

This will be the 3th kind of embedded configuration: Reflection, XML, FI

The FI is "strogly-typed" as Reflection but it is external (from the point of view of an entity-implementation) as XML.

For the ValidatorMode feature I would like to equate FI to Reflection (XmlOverAttributeClassMapping).

The API should look like:

var v = new ValidationDef<Person>();

v.Define(x=>x.Name).AsNotNull().AsNotEmpty();

v.Define(x=>x.Surname).AsNotNull().AsNotEmpty().WithMaxLength(10).WithMinLength(3);

v.Define(x=>x.Assoc).MustBeValid();

and/or

    public class PersonValidationDef : ValidationDef<Person>

    {

        public PersonValidationDef()

        {

          Define(x=>x.Name).AsNotNull().AsNotEmpty();

          Define(x=>x.Surname).AsNotNull().AsNotEmpty().WithMaxLength(10).WithMinLength(3);

          Define(x=>x.Assoc).MustBeValid();

        }

    }

Validators available will be strongly-typed that mean, for example, that giving a DateTime property (DateTime or DateTime?) only 2 validators will be available

var v = new ValidationDef<Person>();

v.Define(x=>x.BornDate).  here you will see only IsInThePast and IsInTheFuture

Obviously each one may implements his extension methods.

Thoughts?

--
Fabio Maulo

[Simone Busoli]

Cool!

[Simone Busoli]

...although.. this moves the validation logic out of the domain class, which might not be very cool ;)

[Dario Quintana]

I think with this, NHV is going to be more famous :-)
Here you can get ideas:
http://www.codeplex.com/FluentValidation

BTW, how are you going to treat the "metadata layer", we should discuss this, don't know what plans you have.

--
Dario Quintana
http://darioquintana.com.ar

[Dario Quintana]

You already get this using Xml

On Wed, Feb 11, 2009 at 2:34 PM, Simone Busoli <simone...@gmail.com> wrote:

...although.. this moves the validation logic out of the domain class, which might not be very cool ;)

[Fabio Maulo]

2009/2/11 Simone Busoli <simone...@gmail.com>

...although.. this moves the validation logic out of the domain class, which might not be very cool ;)

It is very very cool for me.

The entity is MINE!! without any kind of reference to other matters.

I can validate it in different ways as I can persist it in different ways. ;) 

--
Fabio Maulo

[Dario Quintana]

With this feature we can validate passing "live" or "non-constant" parameters to the validation process, and that you cannot do it with xml nor attributes. Cool.
http://nhjira.koah.net/browse/NHV-16

On Wed, Feb 11, 2009 at 2:26 PM, Fabio Maulo <fabio...@gmail.com> wrote:

[Fabio Maulo]

2009/2/11 Dario Quintana <cont...@darioquintana.com.ar>

BTW, how are you going to treat the "metadata layer", we should discuss this, don't know what plans you have.

We have it from the begin... well from the begin in NH-Contrib.

--
Fabio Maulo

[Fabio Maulo]

2009/2/11 Dario Quintana <cont...@darioquintana.com.ar>

With this feature we can validate passing "live" or "non-constant" parameters to the validation process, and that you cannot do it with xml nor attributes. Cool.
http://nhjira.koah.net/browse/NHV-16

I didn't understand that feature request.

--
Fabio Maulo

[Dario Quintana]

I know, that means: attributes is the metatada ? For me it's and is enough.

[Dario Quintana]

I know...when you finish Fluent NHV, you will.

[Dario Quintana]

You don't remember, but we talked about it with Gustavo, you and me.

[Simone Busoli]

Shouldn't validation be independent from persistence? I mean, you can change the persistence mechanism, but the validation logic is the same.

 

--
Fabio Maulo

[Fabio Maulo]

2009/2/11 Dario Quintana <cont...@darioquintana.com.ar>

I know, that means: attributes is the metatada ? For me it's and is enough.

IClassMapping has metadata and we have 4 implementation of it.

--
Fabio Maulo

[Dario Quintana]

This is for another thread.

On Wed, Feb 11, 2009 at 2:48 PM, Simone Busoli <simone...@gmail.com> wrote:

Shouldn't validation be independent from persistence? I mean, you can change the persistence mechanism, but the validation logic is the same.

 

--

Dario Quintana
http://darioquintana.com.ar

[Simone Busoli]

You're right :|

[Fabio Maulo]

2009/2/11 Dario Quintana <cont...@darioquintana.com.ar>

I know...when you finish Fluent NHV, you will.

Don't be so sure... 

--
Fabio Maulo

[Fabio Maulo]

2009/2/11 Simone Busoli <simone...@gmail.com>

Shouldn't validation be independent from persistence? I mean, you can change the persistence mechanism, but the validation logic is the same.

Sure... and even you may have different constraints in different app installations for different customers.

With NHV you can define "fixed" application constraint in the entity trough Attribute and you can mix(add/override) the constraints definition, for a particular customer, with an XML.

--
Fabio Maulo

[Dario Quintana]

Cool.

[Simone Busoli]

You're talking about multi tenancy then, which is another topic. But I'm stopping here since it's going OT.

Anyways, cool! :)

[Fabio Maulo]

2009/2/11 Simone Busoli <simone...@gmail.com>

You're talking about multi tenancy then, which is another topic. But I'm stopping here since it's going OT.

Try NHV to understand the flexibility it has for multi-tenant 

--
Fabio Maulo

[Simone Busoli]

I have no doubt about it.

[Dario Quintana]

Maybe I wasn't clear enough.

What I mean with metadata is that right now, to define a custom Validator we need:
1) Create the validator (inherits from IValidator)
2) Create the Attribute with parameters

Now with this fluent cfg, for custom "Fluent-Validators", we need to add 1) and 2) plus:
3) Extension methods with pointing to custom rules.

That way ?

[Fabio Maulo]

3) Yes, if you want use it trough Loquacious strongly-typed configuration
We talk about Attributes long time ago and the end was:

We need a class where hold a specific-Validator-parameters, why not use directly the attribute ?

The conclusion was: use Attribute.

2009/2/11 Dario Quintana <cont...@darioquintana.com.ar>

--
Fabio Maulo

[Fabio Maulo]

3) Yes, if you want use it trough Loquacious strongly-typed configuration
We talk about Attributes long time ago and the end was:

We need a class where hold a specific-Validator-parameters, why not use directly the attribute ?

The conclusion was: use Attribute.

2009/2/11 Dario Quintana <cont...@darioquintana.com.ar>

Maybe I wasn't clear enough.

--
Fabio Maulo

[Dario Quintana]

Ok, was just to be sure we are going in the same direction.

Saludos :-)

On Wed, Feb 11, 2009 at 4:36 PM, Fabio Maulo <fabio...@gmail.com> wrote:

... The conclusion was: use Attribute.

[Fabio Maulo]

Do you have some advise about the API ?

Check the first post from start to end, please.
--
Fabio Maulo

[Gustavo Ringel]

I just don't like the As and With...it's a matter of taste may be, but then i have to do MaxLength, then it is AsMaxLength or WithMaxLength or HasMaxLength? i think MaxLength is easier to understand and easier to find...

Gustavo.

[Dario Quintana]

My advice, validate against handlers as an option.

 public class PersonValidationDef : ValidationDef<Person>

    {

        public PersonValidationDef()

        {

          Define(x=>x.Assoc).MustBe(MyMethodThatReturnABoolean);

        }

    }

The API seems to fine, but +1 for the Gustavo requeriment about the names.

Note: That was a change from NUnit to XUnit, they removed all: "Are" "Is" at the beggining of the methods, is a silliness but helps.

[Gustavo Ringel]

At the end as it is working until now it should be translated to an attribute...how are you going to translate this into an attribute? I may be missing something.

For now to implement this you should create an attribute and a validator, are you suggesting creating attributes and validators on the fly?

Gustavo.

[Fabio Maulo]

Ok, even if it is not so "Loquacious' as fluent-interface expect ;)

2009/2/11 Gustavo Ringel <gustavo...@gmail.com>

--
Fabio Maulo

[Gustavo Ringel]

lol

[Gustavo Ringel]

We had a large discussion by mail. Our concerns (Fabio and me) where about using NHV Validator as a kind of DSL, or using it as it is now as a static validator.

The argument was that if you depend only on the object itself then you can do the same validation in every layer. If you put some business concerns, then in different layers there is a chance you don't have enough info to validate your entity...

Gustavo.

[Tuna Toksoz]

Go Fabio, go! This is very cool and complex logic can be handled in a much easier way. I really like this approach.


Tuna Toksöz
http://tunatoksoz.com
http://twitter.com/tehlike

Typos included to enhance the readers attention!

[Dario Quintana]

With this, the only metadata of the Fluent rule, would be the Message, and yes, we can create attributes on the fly (with a unique name). Why I said it should be only the message, because the parameters can setted in the handler, maybe via ctor, like

...MustBe(new MyFoo(param1).Rule())

[Fabio Maulo]

2009/2/11 Fabio Maulo <fabio...@gmail.com>

For the ValidatorMode feature I would like to equate FI to Reflection (XmlOverAttributeClassMapping).

Sorry I was wrong, it have no sense.

The main is Attribute and anything else is an "external-mapping-source".

There is no sense to override a fluent-conf with XML-conf because, in general, who are using fluent-conf not use xml-conf. 

--
Fabio Maulo

[Gustavo Ringel]

agree