Comments (6)
This is another thing I was planning to do once someone asked for it. Do you have any implementation ideas? I was thinking of providing an API function that allows you to specify the message for each error type, with support for a few basic placeholders. Like:
MySimpleSchema.messages({
"required": "[label] is required",
"stringMax": "[label] cannot exceed [max] characters"
});
Might be nice to support field-specific overrides, too. Could just support a field name in the key, separated by a space, like:
MySimpleSchema.messages({
"required": "[label] is required",
"required firstName": "I know it's a pain, but we need to insist that you enter your first name.",
"stringMax": "[label] cannot exceed [max] characters"
});
I can probably implement this later today or tomorrow, unless you have a better idea.
from meteor-simple-schema.
Maybe its better to let the requirements themselves contain messages:
MySchema( {
name: {
type: String
min: {val: 5, message: "must be longer than 5"}
max: {val: 100, message: "your name is too long. deal with it."}
}
...
On Mon, Aug 19, 2013 at 7:49 AM, Eric Dobbertin [email protected]:
This is another thing I was planning to do once someone asked for it. Do
you have any implementation ideas? I was thinking of providing an API
function that allows you to specify the message for each error type, with
support for a few basic placeholders. Like:MySimpleSchema.messages({
"required": "[label] is required",
"stringMax": "[label] cannot exceed [max] characters"});Might be nice to support field-specific overrides, too. Could just support
a field name in the key, separated by a space, like:MySimpleSchema.messages({
"required": "[label] is required",
"required firstName": "I know it's a pain, but we need to insist that you enter your first name.",
"stringMax": "[label] cannot exceed [max] characters"});I can probably implement this later today or tomorrow, unless you have a
better idea.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-22877369
.
from meteor-simple-schema.
I thought of that, too, but there are a number of downsides:
- Not every possible message corresponds to a schema key (required and array don't)
- You'd have to repeat the same message for every field, even if they are all essentially the same
- Having a separate
messages()
function makes it possible to rerun the function easily to swap out messages, for example if someone wanted to support multiple languages and pull the messages object from language files.
from meteor-simple-schema.
A couple of thoughts on this:
I think there should be both a messages function (and/or messages argument) to define/change default messages, as well as the ability to override with custom messages in the individual requirements. This gives the most flexibility while allowing code to be more terse if desired. Plus it makes more sense to me to put custom messages along with the requirements themselves.
i18n should probably be passed onto a separate i18n package, right? Something that can store strings by keys in different languages and then retrieve the correct string in the current locale.
Also, if required isn't associated with a schema key, then shouldn't the optional property be replaced with "required"? So this could work something like (using the simple-i18n package):
//at some point discover and assign the current locale
locale = "us-en";
...
var i18n = Meteor.I18n().collection;
MySchema = new SimpleSchema({
"name": {
required: {true, i18n.findOne({lang: locale, base_str: "schemaNameRequired"})},
min: 3,
max: {10, i18n.findOne({lang: locale, base_str: "schemaNameMax"})}
}
}, {
required: i18n.findOne({lang: locale, base_str: "schemaRequired"}),
min: i18n.findOne({lang: locale, base_str: "schemaMin"}),
max: i18n.findOne({lang: locale, base_str: "schemaMax"})
});
So the key "name" would use the i18n messages for the "us-en" locale under the keys "schemaNameRequired", "schemaNameMax", and "schemaMin". Not that anyone would have to use simple-i18n, but I think this would let you delegate i18n out of this package.
from meteor-simple-schema.
I find it kind of confusing to have the custom messages in one place and the generic messages in another place. I also think it makes the schema a little harder to read. If I'm alone in this, I would not be opposed to supporting the custom message definitions in the schema in addition to the message definitions object.
The reason I chose to use the messages()
function rather than the second argument of the constructor is because I can envision people wanting to change the messages on the fly. @sbking's example assumes that locale is going to be static, but sites often let you change it, and whenever this happens, you'd have to redefine the messages, which is easy with the messages()
function but you wouldn't want to continually re-construct the SimpleSchema object.
I do agree that externalizing I18N is best.
I know a lot of validation plugins and frameworks make you specify required
instead of optional
, but for some reason I decided optional was better. I think maybe it was because it seemed safer to have required be the default and make the developer opt out. It's not something I care deeply about, but I'd rather not make breaking changes like that without a good reason.
I any case, this is all implemented in the package already now, so maybe folks can play around with it and see what they do and don't like about the current implementation.
from meteor-simple-schema.
@aldeed fair point on the messages function
from meteor-simple-schema.
Related Issues (20)
- [solved] custom function validation error HOT 1
- autoValue: calling fields() and siblingFields() yields no results on insert HOT 2
- Overwriting SimpleSchema regEx messages HOT 5
- Error: Invalid definition for inMenu field HOT 1
- Match.Where being instantiated as a class, causes error on Meteor 1.6.1 boot HOT 5
- Make a field conditionally required bug HOT 1
- Explicitly indicate this repo is deprecated HOT 1
- How to define a Custom Validation Error in Autoform >= 6.0 HOT 1
- Removing old field from old users? Ignore schema when using $unset ? HOT 1
- typo in dependencies in version 3.0.0 HOT 1
- 1.6.2 Has removed Deps from Tracker package HOT 4
- Warn / strip global regEx schemas? HOT 1
- the optional: true afFieldInput have the required attribute with it HOT 1
- error in Documentation [max] > {{max}} HOT 1
- "must be an object" error even though typeof() returns Object HOT 3
- $pull not behaving as expected HOT 1
- Move this package to Community Packages to support simpl-schema >=3.x HOT 1
- Update autoValue to accept async function HOT 2
- Typescript error when importing SimpleSchema HOT 6
- Using Collection Hook's direct version breaks defaultValue and autoValue on an insert HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from meteor-simple-schema.