I'm defining entities in RAML 1.0, and I feel that it's wasteful that the required attribute must be defined for each item if we want to make sure that it's (non-)optional. Is there a default value for this, and if so, which?
According to the RAML 1.0 specs, the required attribute in RAML 1.0 entities defaults to "true", so it's only necessary to specify required: false for optional attributes.
Moreover, we can append a ? to the attribute name (e.g: age?), to signify that it's optional (required: false), unless the required attribute is defined, in which case the question mark will be part of the actual attribute name.
Related
In my use case I have a RAML 1.0 library created by our R&D department that contains definition of multiple data types. Those data types are defined in a generic, parametrized manner so when I reference them in my RAML I do so using following syntax:
type: { resourceTypes.collectionWithCriteria: {itemName: reward, itemCriteria: types.RewardCriteria, itemType : types.RewardList} }
This generates proper GET request with query string defined by types.RewardCriteria and response defined by types.RewardList. It also generates the description for the GET resource defined as: Retrieves the list of <<itemName | !pluralize>>, which ends up being Retrieves the list of rewards.
In my RAML I would like to append additional description to my GET resource, however I 'd rather avoid overwriting library-generated one. Is that possible? I've already tried inline description and using overlay file, both of which simply replace description from the library.
You cannot append for a single value simple property.
The merging rules for traits / resource types state that the description will be replaced:
Every explicit node wins over the ones that are declared in a resource
type or trait. The rest are simply merged.
Also, the merging rules of overlays and extensions states that:.
If the property is a Simple Property
If the property is a Single-value Simple Property,
The property value in the identically named Current Target Tree Object property is replaced with its value from Current Extension Tree Object property.
I have the requirement to specify an API in raml where the object properties have to be specified otherwise the validation should fail. This is achieved by additionalProperties: false.
In addition I would like to specify that the request objects can contain pattern properties, similaryl to the official example:
/^note\d+$/?: # restrict any properties whose keys start with "note"
# followed by a string of one or more digits
type: string
Those two things are ok alone, but when brought together they do not work anymore (as specified in the RAML spec):
Moreover, if additionalProperties is false (explicitly or by inheritance) in a given type definition, then explicitly setting pattern properties in that definition is not allowed. If additionalProperties is true (or omitted) in a given type definition, then pattern properties are allowed and further restrict the additional properties allowed in that type.
So the question is how can I achieve this requirement. something like:
types:
Person:
description: |-
Document representing a person.
additionalProperties: false
properties:
firstName?:
description: |-
The person's first name
type: string
/^person_info_.+$/?:
description: Additional person info.
type: string
Please note that this example will fail saying something like
extraneous key [person_info_1] is not permitted
The way I read the RAML specification, it is saying that there are 3 levels of strictness when validating against the properties:
additionalProperties=false: The only allowed properties are the ones declared by the type.
additionalProperties=true AND pattern properties specified : Any additional property name is valid, but IF the name matches the pattern for a pattern property THEN the value must match the value specification for that pattern property.
additionalProperties=true AND no pattern properties specified : Any additional property is valid.
I'm happy to be corrected on the meaning of 2, but that's how the specification seems to read.
Is there a way to tell cerberus to have required set to True by default for all keys in the schema? This would save me some time, because most often I want to assert the existence of a key.
I think there's no general solution to this, and different approaches are suited for different overall scenarios. Let me propose two:
Extending the schema
This is fairly simple, just add the required rule to all fields of a schema before employing it:
for field in schema:
field['required'] = True
Custom validator
As the Validator class has a method that checks all fields in regard to this rule, it can be overridden in a subclass:
from cerberus import errors, Validator
class MyValidator(Validator):
def __validate_required_fields(self, document):
for field in self.schema:
if field not in document:
self._error(field, errors.REQUIRED_FIELD)
Note that this proposal doesn't consider the excludes rule as the original implementation.
However, as this is part of the non-public methods, the underlying design might change unannounced in the future.
Both validators are no real validators, rather they can change an attribute value. If such pseudo validators are used in model rules, do they have any effect on other real validators?
For example, when a default and a required validator are used for the same attribute, will the required validator never fail?
Or are there any precedences with such validators? Or is the order of the validation rules crucial?
The pseudo validators alter the values of attributes. Thus any subsequent validators on the same attributes will validate against the altered values.
The order is crucial. The validators are created from rules() using \yii\base\Model::createValidators() in the order they appear in rules().
For your specific example, when the required rule is first, validating against it will return false. However, when the default rule is first, the attribute already has a set value thus the validation for required will return true.
How can I disable the built-in validation for a property of float type?
We have our own custom validation attributes that work fine.
But we have this scenario where we want a float property to accept ( .1 ) as a valid float number. Which obviously means ( 0.1 ), but this number is not accepted by the built-in validation.
Basically I want to disable validation on property-by-property bases and still enforce my own custom validations.
Use a nullable type in your viewmodel property e.g:
float? MyProp {get; set;}
This stops the built in validation from occurring but will still use your custom validation. Obviously as you have now made the property nullable, you may want to put a Required validation attribute on the property to ensure you get a value.
Turns out that .3 is actually accepted by the default model binder. The problem is actually with the client validation implementation. If client validation isn't important to you, you can solve this problem by opening the web.config and changing ClientValidationEnabled to false within AppSettings.