GitHub Issue 57 - Default failure messages should be the same for both server and client side

[Bob Silverberg]

Dan has suggested in the issue at https://github.com/ValidateThis/ValidateThis/issues/57 that client-side and server-side default failure messages should be identical.  I agree with this in principle, and the only reason they are the way they are now is because I was lazy when I first created VT and just used the default messages that were available from the jQuery plugin. It meant less code for VT and allowed the plugin to do something that it was designed to do.

As I said, I can see the advantage in having identical failure messages on both sides, but my one concern is that if we implement this change then anyone running VT in production will experience changes in their client-side failure messages.  This may upset some people - there may be cases where all of these messages have been signed off by a client and now a bunch of them are going to change. I'm wondering if you folks agree that this is something we need to be worried about.  We could create a "compatibility mode" which would allow users to keep the current behaviour, but I really don't want to do that because it will mean a lot of extra code to maintain.

Does anyone have any thoughts on this?

Thanks,

Bob

--
Bob Silverberg
www.silverwareconsulting.com

[Jamie Krug]

I don't feel strongly, either way, but I like the idea of consistent default failure messages. I doubt we need to worry about such a change upsetting folks, but you could poll the main list if you're concerned. I agree that a "compatibility mode" would introduce unnecessary maintenance work--I'd shy way away from that if at all possible.

Just my 2 cents,

Jamie

--
You received this message because you are subscribed to the Google Groups "ValidateThis-dev" group.
To post to this group, send email to validate...@googlegroups.com.
To unsubscribe from this group, send email to validatethis-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/validatethis-dev?hl=en.

[John Whish]

I agree with Jamie

[Matt Quackenbush]

I agree with Jamie, too.  And no, contrary to popular belief, he did *not* pay me to say that!  :D

[Bob Silverberg]

Cool. That's good enough for me.

John, I have assigned the ticket to you as you are working on the client-side code right now.  We can discuss this ticket along with the other client-side stuff when we find a chance to chat.

Thanks,

Bob

Bob Silverberg
www.silverwareconsulting.com

[John Whish]

OK, I've started looking into this. The quick fix is to pretty much
copy/paste the validation message from the SRV into the CRV. That
isn't very DRY, but does make it easy to have different default
messages for the client and server side validation and also for
developers who want to create their own validators.

I'm not keen on that (although it would save me lots of time!).
Instead I'm thinking of having a separate object which is responsible
for generating default messages (if not specified in the rule)
depending on the "valtype" which would be called from addRule. The
downside to this approach is that it adds complexity and means when
new validator types are added then this object would need to modified
as well.

Any thoughts?

Thanks,

- John

[Dan G. Switzer, II]

John,

I would think you'd eventually want some kind of message object so that you can handle i18n stuff anyway, so it makes the most sense to me to store default messages in one location--that way someone could overwrite the language package or easily change the default messages.

-Dan

Dan G. Switzer, II

dswi...@pengoworks.com

http://blog.pengoworks.com/