Rake Error with FubuValidation

[Matt S.]

Hey guys,

I've looked around for similar issues, but I get the feeling this is new stuff for Ripple 2. I'm trying to build my clone of fubuvalidation, so I can open it up in VS and dig in to the source. When I run rake, I get the following, regardless of my feeble attempts to overcome.

 

src/packages/Bottles.1.0.0.465.nupkg/tools/BottleRunner.exe alias hellovalidation src/FubuMVC.HelloValidation
rake aborted!
Command failed with status (127): [src/packages/Bottles.1.0.0.465.nupkg/tools...]
Tasks: TOP => default => compile => aliases

I can't get to a point where the references in the projects are valid, due to missing assemblies. Can anyone help, please? Trace shows the last status message as "** Execute aliases". I can provide the full trace output, if it helps.

Thank you,

-Matt

[Joshua Arnold]

Try this:

git clean -xfd
cd buildsupport

git fetch origin

git rebase origin/master

cd ../

rake

--
You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fubumvc-deve...@googlegroups.com.
To post to this group, send email to fubumv...@googlegroups.com.
Visit this group at http://groups.google.com/group/fubumvc-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Joshua Arnold]

(You have leftover artifacts from ripple 1.0)

[Matt S.]

Hmmm. This was a fresh clone from this morning. However, your solution worked like a charm! Now I can enjoy all your hard work on validation.

Thanks, Josh!

-Matt

[Joshua Arnold]

Ah, I think validation was one of the first ones to get converted. I've slept and updated buildsupport since then. I'll fix it when work lets up.

As always, ping me if you have any questions.

[Joshua Arnold]

I just pushed the fixed repo so nobody else hits this.

[Matt S.]

Yes, sleep does wonders for the coding mind.

Thanks! I may post another thread about a MatchingFieldRule that I'm interested in creating for comparing a password to its password confirmation on a model. I'd be more than happy to send a pull request for such an animal, as I don't see anything in there for such a thing.

[Joshua Arnold]

I think you might wanna find me on Skype about that. When you're working against multiple fields, you're going to want an IValidationRule (class-level) rather than an IFieldValidationRule (field-level).

[Matt S.]

I was just starting to question how viable this was as a field rule when you posted again. I think I get it, but I'll likely track you down on Skype anyway to see if this is even worth adding to the repo. I also need to crack open the JS to see about adding such a thing for client-side.

[Joshua Arnold]

Jaime and I have talked about this a few times. I think it's going to involve opening up the RemoteRuleGraph to support IValidationRules as well.  We can also extend the querying and span multiple fields.

[Matt S.]

I'll play around some to get a feel for the quick and dirty. I was thinking (coming in late to this party obviously) about adding a data attribute to either the form tag or the first of the 2 properties' inputs that are being compared. It would look like: "<form ... data-fieldsToMatch='Password|PasswordConfirm,OtherField|MatchingOtherField'>". Add some extra JS to your existing bits to look for that data attribute, parse it on commas, then paired on pipes, to run through a list of inputs to match the values on.

I have a new rule class now that takes 2 expressions for accessors, then evaluates them on the validation context and uses Equals to compare. It's simple enough, but I have to test it now.

I don't see a really clean way to have a class attribute for this rule either, due to the expressions. Other than some lame magic string support (e.g. [MathingFields("Password", "PasswordConfirm")]); eww.

[Jaime Jhon]

Remember not to rely on attributes, let them be just a way to achieve what you could do using a regular policy or convention.

When I've needed to link one property to another using attributes I often take a different path.

Let's say you have that MatchingFieldsAttribute class....

public class Model

{

[MatchingFields(Key="PasswordMatch",Role=MatchingRole.Source)]

public string Password{get;set;}

[MatchingFields(Key="PasswordMatch",Role=MatchingRole.Target)]

public string PasswordConfirm{get;set;}

}

Later, you have a policy, that scans input types, checks for the pair of matching fields that have the same Key ("PasswordMatch") and join them together using the corresponding roles.

Then you populate that into some sort of graph (using accessors as keys), which can be later queried to create html conventions.

That removes entirely the need to use strings to link properties together, which in the end is refactor friendly.

Now, if you keep this only as a policy, you can create other conventions to populate this graph.

E.g.: Any property that has the suffix "Confirm" should use the MatchingFields validation rule.

The underlying infrastructure remains the same, you just use different methods to populate the graph.

Just my 2 cents.

Regards

--
You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fubumvc-deve...@googlegroups.com.
To post to this group, send email to fubumv...@googlegroups.com.
Visit this group at http://groups.google.com/group/fubumvc-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Jaime Febres Velez

[Joshua Arnold]

@Matt,

You might checkout ClassValidationRules<T>. There are examples of usage in ClassValidationRulesTester and a good example of usage in the StoryTeller project. That's the class-level DSL we provide. It gets registered by the ValidationRegistrationActivator in FubuMVC.Validation - which says "anything that implements IValidationRegistration" gets registered automatically.

Right now that class is primarily used to register field level rules but it has the ability to go class level. That would enable you to do something like: Compare(x => x.ConfirmPassword).To(x => x.Password).

I haven't thought through the querying yet for something like that. Let me keep it in the back of my mind for a while and see what I come up with.

[Matt S.]

Jaime,

I absolutely agree with the idea of attributes as "bonus". I like your idea for field-level attributes. With a class-level attribute, the "key" would be implied by the pair of property names, but you'd be dealing with magic strings. Your solution takes care of that quite nicely. Thanks!

-Matt

[Matt S.]

Josh,

I will definitely do that. I'm not against having this implemented server-side with a quick hack of manual JS for client-side...for now. ;-) Being able to have something like this emit the necessary JS would be very cool indeed. Just to be thorough here, I started with something like this for my rule (untested yet; was at a client site all day today).

public class MatchingFieldsRule<T> : IValidationRule, DescribesItself

  where T : class {

  private readonly Accessor _firstAccessor;

  private readonly Accessor _secondAccessor;

  public StringToken Token { get; set; }

  public MatchingFieldsRule(StringToken token, Expression<Func<T, object>> firstField, Expression<Func<T, object>> secondField) {

    Token = token;

    _firstAccessor = firstField.ToAccessor();

    _secondAccessor = secondField.ToAccessor();

  }

  public void Validate(ValidationContext context) {

    object firstValue = _firstAccessor.GetValue(context.Target);

    object secondValue = _secondAccessor.GetValue(context.Target);

    if (firstValue.Equals(secondValue)) {

      return;

    }

    context.Notification.RegisterMessage(Token);

  }

  

  ...

}

The rest is the Equals overrides, etc. This type of rule could even be the start of others for comparisons of IComparable fields/properties. Now, getting this out as JS is another story, but I'm still leaning toward some data attribute on the form, or even using Jaime's idea of a key that could be the name of a data attribute.

I'll see if I end up doing it "right" in my current site after my quick fix hack. If so, I'll post back ideas/implementation details.

Thanks again, guys!

[Joshua Arnold]

Yes, that's looking like the kind of rule I would expect to see. I have some notes on this in a notebook to extend the querying mechanisms to have it flow through to the JS cleanly. Once I get out of this hole of a deployment, I'll send them your way.

[Matt S.]

Cool. That sounds great; much appreciated.

[Jaime Jhon]

It just get tricky when you have this kind of rules and they need to be applied to collection items.

E.g., a table-like interface where the user needs to enter the min and max range of income in the last 7 years, thus, each item has a comparison rule telling one cannot be greater than the other.

--
You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fubumvc-deve...@googlegroups.com.
To post to this group, send email to fubumv...@googlegroups.com.
Visit this group at http://groups.google.com/group/fubumvc-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Jaime Febres Velez

[Matt Sollars]

True. However, we could limit it to IComparable field/property values. Your example would fall into a non-standard rule that would require custom code.

Now, that still carries with it the intricacies of flowing your custom rule down to JS. I haven't dug in enough to determine how to "hook" into the main client-side validation mechanism with your own custom JS that can look for some markup that your HTML conventions emit when finding your custom rule.

I'd be willing to bet it's easier than most other libraries we've had to deal with in our careers. ;-)

--
You received this message because you are subscribed to a topic in the Google Groups "FubuMVC Development Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fubumvc-devel/nAH-ov2nuJE/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to fubumvc-deve...@googlegroups.com.

[Joshua Arnold]

While it might be "tricky", I don't think the scenario Jaime mentioned is all the complicated. I think we need to teach the Validator to properly handle IEnumerables. If we did that, then applying a continuation field rule on a collection would let the rest flow through on the server-side. 

The key would be to define the validation rules on the nested item. So if you had:

public class IncomeEntry
{
    public int Min { get; set; }
    public int Max { get; set; }
}

You would define the rule to say that Max must be greater than Min on the IncomeEntry itself. I would use a Partial to render the template of inputs for IncomeEntry (which would let the html conventions flow all the way down). Dynamically appending those templates clientside would trigger the validation and everything would work together just fine.

Matt, to your point: "I'd be willing to bet it's easier than most other libraries we've had to deal with in our careers. ;-)"

The design of the clientside work is modeled directly off of the server-side stuff. Essentially, the "validator" is an aggregator of IValidationSource instances. Each source is responsible for defining rules for a particular validation target. Server side that target is the actual object. Client-side the target is an individual element. 

Examples of the clientside sources:

1. CSS source (uses css classes to pick up rules ala jquery validation)

2. Basic html markup source (e.g., maxlength)

3. Rule-specific data attribute sources (we use these for the built-in rules like min, max, range, etc.)

4. The remote validation on the clientside uses data attributes emitted through the html conventions (much like #3)

The flexibility was my absolute highest priority when I made that so hopefully it holds up when you start playing with it ;).

[Jaime Jhon]

hi josh...in fact my pull request just do thay, it leverages validation rules for collections

[Joshua Arnold]

I'm about to crash for the night -- it's been a LONG week. I think I might nudge you to support more than just IList<T> for this particular case. Any reason why you didn't just go for the IEnumerable<T>?

[Jaime Jhon]

let me check the details of it in the morning...im in bed actually :p

[Jaime Jhon]

@Josh, I've reviewed the code and I did it that way because strictly speaking you need at least an IList<> to be Accessor friendly, as in, InputFor(x=>x.Collection[z].Property)...

I couldn't resolve the element by index if the type does not expose an indexer, which IList<> does.

But I'm open for discussion and being proved wrong.

https://github.com/emiaj/fubuvalidation/commit/1555a02b9c6be79d8b9f1ee2dd9a15e07cf12e2f#L8R16

https://github.com/emiaj/fubuvalidation/commit/1555a02b9c6be79d8b9f1ee2dd9a15e07cf12e2f#L8R26

--
Jaime Febres Velez

[Joshua Arnold]

Ah, ok. This is strictly for lofi scenarios, right?

[Jaime Jhon]

No, checkout the ajax integration test.

--
You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fubumvc-deve...@googlegroups.com.
To post to this group, send email to fubumv...@googlegroups.com.
Visit this group at http://groups.google.com/group/fubumvc-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Jaime Febres Velez

[Joshua Arnold]

Sorry, I meant server side validation. Ok, let me think about this one some more. I hate the IList restriction so I'll see what I can come up with

--

You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fubumvc-deve...@googlegroups.com.
To post to this group, send email to fubumv...@googlegroups.com.
Visit this group at http://groups.google.com/group/fubumvc-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Jaime Febres Velez

[Matt S.]

Josh,

Thanks for pointing me to the tests. I looked at ClassValidationRules<T> and the corresponding tests. It makes sense that class should allow me to add my class-level rule, but I cannot clearly see how to do it. I'm only seeing DSL for Property and Required that seem to apply to field-level rules.

So, given my MatchingFieldsRule<T>, how can I hook an instance of one of those up to my input model? I changed my OverridesFor<T> subclass to inherit from ClassValidationRules<T> and to implement IValidationSource for the custom rule. I'm just not sure if I should break out the IValidationSource implementation to its own class (am I wasting cycles with the ctor wiring up the field-level rules in that class or is only a single instance being created?).

public class RegisterInputModelRules : ClassValidationRules<RegisterInputModel>, IValidationSource {

  public RegisterInputModelRules() {

    Require(m => m.FirstName, m => m.LastName, m => m.Password, m => m.PasswordConfirmation);

    Property(m => m.Email).Required().Email();

  }

  public IEnumerable<IValidationRule> RulesFor(Type type) {

    yield return new MatchingFieldsRule<RegisterInputModel>(Tokens.PasswordConfirmationRule, m => m.Password, m => m.PasswordConfirmation);

  }

}

Thanks again for taking the time to assist.

-Matt

On Friday, April 5, 2013 7:18:15 PM UTC-4, jmarnold wrote:

[Joshua Arnold]

@Matt,

Sorry, I should've been a little more clear. I think this is a good place to *add* the ability to specify class-level rules ;). I would like to see something like:

public class MyClassRules : ClassValidationRules<MyClass>

{
    public MyClassRules()

    {
        Require(x => x.FirstName);
        Register<MyClassLevelValidationRule>();
    }

}

Where "Register" is just:

public void Register<T>() where T : IValidationRule

We could just build up a configured IValidationSource inside of the ClassValidationRules that matches on the type (T). Happy to walk you through a PR on that. I'm deep in some ripple enhancements tonight otherwise I would take it real quick.

[Matt S.]

Ah, that makes sense. I definitely don't want to distract you from ripple enhancements. ;-)

I'll take a look around tomorrow and see if I can come up with something. Otherwise, I'll take you up on the walk-through for a pull request.

Thanks!