How can I query a request for validation rules in order to set HTML conventions?

[Matt S.]

I'm betting Josh has a quick answer for this one.

I have some HTML conventions now that set the label to bold for any input property that is deemed "required". Right now, that relies on the detection of the RequiredAttribute and a simple property type evaluation via something like this:

Labels.AddClassForAttribute<RequiredAttribute>(RequiredClass);

Labels.IfPropertyTypeIs(t => !t.IsNullable() && t.IsValueType && !t.IsBoolean()).AddClass(RequiredClass);

However, now I am also adding rules via ClassValidationRules<T>. So, it's common to see this near my input classes:

public class RegisterInputModelRules : ClassValidationRules<RegisterInputModel> {

    public RegisterInputModelRules() {

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

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

    }

}

How can I query for such validation rules in my HTML conventions to ensure that my labels are adorned with the "required" class? Those validation rules already take care of the editors in order to enforce validation client-side, but my labels are naked.

Thank you,

-Matt

[Joshua Arnold]

I would go the top-level IElementModifier route (or you can use the DSL overload that gives you the element request).

When you have the element request, graph the ValidationGraph and then you can query the rules for the accessor:

https://github.com/DarthFubuMVC/fubuvalidation/blob/master/src/FubuMVC.Validation/UI/FieldValidationElementModifier.cs#L11

--
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 Jhon]

I think that's for input's, right? not for labels.

You can find some inspiration from here:

https://github.com/DarthFubuMVC/fubuvalidation/blob/master/src/FubuMVC.Validation/UI/InputElementModifier.cs

--
Jaime Febres Velez

[Joshua Arnold]

Yeah, I was just showing it for reference of how to use the graph.

[Ryan Rauh]

Added this thread to the FAQ. Good stuff

[Matt S.]

Guys,

Thanks for the insight. I'm really close, but I'm hitting a null reference exception on ElementRequest.Get<T>(). Apparently, when I'm calling it, the _services field is null. I could very likely be doing this all in the wrong place, so please bear with me.

I added this line to my SiteHtmlConventions class:

Labels.If(request => 

    request.Get<ValidationGraph>().Query().HasRule<RequiredFieldRule>(request.Accessor))

    .AddClass(RequiredClass);

I'm importing my SiteHtmlConventions from within my FubuRegistry class:

Import<SiteHtmlConventions>();

I'm on the latest public NuGet: FubuMVC.Core.UI version 1.0.1.351. If the service locator is null on that ElementRequest, I'm betting I have things in the wrong order.

Thanks!

[Joshua Arnold]

@Matt,

That predicate is memoized early to keep the html conventions running fast. You don't have access to everything there, unfortunately. I usually base the predicate on type information. In the execute, you can just do a sanity check and exit out.

[Matt S.]

Thanks, Josh.

I'm not quite sure I follow you. If request.Get<T>() is throwing an exception at that point (due to the null ElementRequest._services field), is there a way I can test that it will fail, or will I have to catch the exception and ignore it? I thought about calling ElementRequest.Attach() to ensure the request has a IServiceLocator, but that doesn't feel like a great idea.

I see that ElementRequest.HolderType() checks to see if _services is null before attempting to call Get<ITypeResolver>. Perhaps, Get<T> should check for a null _services field and return default(T), if so? I'm not familiar enough with the broader picture of the framework to know if that would screw anything up or not. For example, is there code that wraps a call to ElementRequest.Get<T>() in a try/catch? Should Get<T>() guarantee no exception?

I can hunt around myself to see if there are any issues that stands out, if that were it's new behavior. If not, I'd be glad to write the additional test(s) for it and submit a PR.

[Jeremy D. Miller]

Matt,

My original concept -- and it's not holding up well in real life -- is that the matching predicate would only act upon the information available via reflection on properties and the holding types so that we could create and cache a "tag plan" the first time that the html conventions sees a new property.  The services are not yet available at Matches() time as it stands today.  The reality is that Josh and now you want to use a registered service as part of the matching process.

I vote that we change the html conventions permanently to enable the services to be available during the predicate time and not just at tag building time.

How does that sound?  I made the original choice based on performance considerations, but it's kind of a moot point if it doesn't work at all.

Thanks,

Jeremy

[Joshua Arnold]

+1 from me. 

[Matt S.]

Jeremy,

I totally understand that reasoning. That's tough considering the amount of predicate exercising I can imagine a site would need to display views. However, it seems the only way validation querying (and similar) can work for this sort of thing is to eat some perf.

You've got my +1.

For now, I'm using the RequiredAttribute with a TODO to come back and put everything into the fluent calls on a ClassValidationRules instance, which I'm still using for email, range, etc. validation.

Thanks,

-Matt

[Joshua Arnold]

In the meantime, Matt, you go this route: https://github.com/DarthFubuMVC/fubuvalidation/blob/master/src/FubuMVC.Validation/UI/FormValidationModifier.cs

Your tag modifier would be different but the pattern is basically: "I always match". Then do a check in the Modify to make sure the conditions are met before you actually do anything.

[Matt Sollars]

Ah, okay. That's slick and lets me do what I want without having to change how I'm doing things with my models now.

Thanks Josh!

On May 20, 2013 4:32 PM, "Joshua Arnold" <rncod...@gmail.com> wrote:

In the meantime, Matt, you go this route: https://github.com/DarthFubuMVC/fubuvalidation/blob/master/src/FubuMVC.Validation/UI/FormValidationModifier.cs

Your tag modifier would be different but the pattern is basically: "I always match". Then do a check in the Modify to make sure the conditions are met before you actually do anything.

--
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/9WHYYstKKFc/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to fubumvc-deve...@googlegroups.com.

[Matt S.]

Jeremy,

Does Josh's suggestion hold weight as an alternative to undoing the caching with the "tag plan" you discussed? I get that my new IElementModifier runs on all elements (well, all Labels in my case), but is that still better while keeping everything else intact? This is working just fine for me with only a few lines of code really.

-Matt

On Monday, May 20, 2013 6:51:55 PM UTC-4, Matt S. wrote:

Ah, okay. That's slick and lets me do what I want without having to change how I'm doing things with my models now.

Thanks Josh!

On May 20, 2013 4:32 PM, "Joshua Arnold" <rncod...@gmail.com> wrote:

In the meantime, Matt, you go this route: https://github.com/DarthFubuMVC/fubuvalidation/blob/master/src/FubuMVC.Validation/UI/FormValidationModifier.cs

Your tag modifier would be different but the pattern is basically: "I always match". Then do a check in the Modify to make sure the conditions are met before you actually do anything.

--
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/9WHYYstKKFc/unsubscribe?hl=en.

To unsubscribe from this group and all its topics, send an email to fubumvc-devel+unsubscribe@googlegroups.com.

[Jeremy D. Miller]

As a workaround, yes. Longer term I say we make the change we talked about.  We could have the tag plan and eat the services cake too I suppose.

I'm thinking I might make a sweep through FubuMVC.Core.UI this weekend.  Got a bunch of pull requests outstanding for it anyway.

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.

[Matt Sollars]

Ah, I understand. It's not an either/or situation. Great.

To unsubscribe from this group and all its topics, send an email to fubumvc-deve...@googlegroups.com.