Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for variable messages at runtime #117

Closed
goblinhero opened this issue Nov 24, 2017 · 4 comments
Closed

Add support for variable messages at runtime #117

goblinhero opened this issue Nov 24, 2017 · 4 comments
Milestone

Comments

@goblinhero
Copy link
Contributor

E.g. for translation of the error messages depending on user's culture.

Basic usage would be something along the lines of
.WithMessage(()=> _translationService.GetError("Missing_Email"))

@GooRiOn
Copy link
Member

GooRiOn commented Nov 26, 2017

Can you tell me what is the advantage of this solution over message provider? I guess, I simply miss something :D

@goblinhero
Copy link
Contributor Author

It is a lot simpler, since you do not need to define a separate class for just getting translated texts - and it is extremely versatile since you can put in as much logic as you'd like. I'll look into expanding it to support using the entity under test as a parameter, so you can go: .WithMessage(person => $"{person.Email} is not a valid email")

@GooRiOn
Copy link
Member

GooRiOn commented Nov 27, 2017

Now I get it :D

@GooRiOn GooRiOn added this to the 0.2.0 milestone Nov 27, 2017
@arekbal
Copy link
Contributor

arekbal commented Nov 27, 2017

I think that it could be achieved in different fashion but the utility this solution provides is higher than the cost.

But I would go with convention where you provide a current property value first and then separate overload with value and "entity under test"/"model" as second parameter just as I suggested in #114. So it would go like this:
.WithMessage(v => $"{v} is not a valid email")
.WithMessage((endDate, m) => $"{endDate} predates {m.StartDate} for whatever reason, lol")
So the difference between your proposal and mine is to always have same argument at same position, no matter how many overloads.

@GooRiOn GooRiOn closed this as completed Nov 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants