I have a problem with the Microsoft EnterpriseLibrary validation framework.
Let's say we have a DateTime? field. When using the NotNullValidator with another validator (let's say, the datetime validator) I always run in an exception.
The scenario is: I pass a null value. The NotNullValidator works fine (it sets the validation issue) but then the other validator throws a NullReferenceException, trying to apply its rules to the null value I passed.
I tried putting a CompositeValidator with AND logic, hoping that if the first validator reported an issue, the following validators would be ignored (as it should with an AND logic) but I had no luck.
How is it possible to make coexists the NotNullValidator with other validators, having the first one take priority (obviously) over the others?
The above is currently not possible. Unfortunately the Composite validator does not short circuit.
If you need to do it I would just write a custom validator , quick and relatively painless.
Related
Just wanted to ask for the best way to solve my problem:
I got a form with multiple inputs/selects and also buttons to add new objects to the databean behind the form. Now my problem is the validation. E.g.: in one of those selects i chose an option. If this option is selected the user has to add a specific type of an object to the large databean behind the form. That's done by selecting values in two further selects. As soon as those are selected (they are submitted onchange by ajax) the user generates a new object by hitting an "Add" button.
On submit those added object (consisting of two values) must have a specific enum type depending on the first selected value and so on..
Now this all (and a lot more) should be validated and error/info messages should be added to the view.
Now my question: whats the best way to achieve this? The error message has to be at a specific place in the view.
I thought of multiple hidden input fields and using the validate attribute to call validation methods of the underlying bean (cause bean values are needed too). And then rendering an error message right at the position of the hidden field. Is this a good solution? Working with the validator attribute and validating the whole form would lead to error messages in areas where the user hasn't made any input yet, right? I would like to avoid that and just validate the current area. Is that possible by using one bean? Otherwise i would have to use multiple validators with a lot of attributes, or use the beanManager to get my underlying bean?
The JSF validation is done per component, not per form. This is by design (and it has a good purposes). There is a lot of misunderstanding on this point and many teams make the mistake of shoehorning their business logic validation into component validation, just because the word "validation" sounds right to them.
The validation you need is different - it's a business level validation. You don't really validate state of a single component, but rather coherence of the data, which is behind the components. You can still use the message framework to display the errors where you want them.
The clean and "proper" way to do it in JSF will be to:
skip the JSF component validation (because it's designed for different case than yours); you want all the values from the component to be put into your backing beans;
put anywhere you need an error message displayed;
write validation logic in your action method. You can use Bean Validation Framework or write the logic by hand;
if no errors are found, the action method performs an action;
on error, depending on the error, display a message in a proper place (using the component id);
if any error occured, don't perform the action and return from the action method.
The action method should look somewhat like this (this is not a copy-paste example, it's just to give you an idea of the flow):
public void doSomething() {
boolean valid = true;
if (startData.after(expiryDate)) {
FacesContext.getCurrentInstance().addMessage("expiryDate", new FacesMessage("Expiry date should come after creation date"));
valid = false;
}
// other checks
// checks could also make use of BVF validator - but then it's better to switch the BFV validation for the whole form
// (if you don't, then any single field validation will disable error checking for the business validation, which
// will look strange for your users)
if (!valid) {
// if we returned immediately upon detecting an error, we would only display the first one.
return;
}
// do the real stuff
}
I have just started using Pyramid for one of my projects and I have a case where in I need to validate a form field input, by taking that form field value and making a web-service call to assert the value's correctness. Like for example there is a field called your bank's CUSTOMER-ID. I need to take that(alone) as input and validate at the server level by making a web-service call (like http://someotherdomain/validate_customer_id/?customer_id=<input_value>)lets say.
I am using Colander for form schema management and Deform for all form validation logic. I am confused about where I need to place my validation logic for the CUSTOMER-ID case. Is it at MySchema().bind(customer_id=<input_value>) (which has a deferred validator that queries the web-service) or something at the form.validate(request.POST.items()) ? If I take the deferred validator's path, then MySchema().bind is raising colander.Invalid error for incorrect CUSTOMER-ID. Thats fine. But that error is not at the form level but at the schema level. So how would I tell the user about this in a sane way ?
I have good experience with Django forms so I was expecting something like clean method. A form error like form['customer_id'].error is what I am expecting at the template level. Is it possible with Pyramid's Deform or with Colander ?
So I think the big problem you're having is understanding the separation of concerns of Colander and Deform. Colander is what people like to call a general schema validation library. Which means we define a schema, where each node has a particular data type and some nodes might be required/optional. Colander is then able to validate that schema, and tell us whether or no the data we passed to colander conforms to that schema. As an example, in my web apps, I am often building apis that accept GET/POST params that need to be validated. So in Pyramid, let's say I have this scenario:
request.POST = {
'post_id': 1,
'author_id': 1,
'unnecessary_attr': 'stuff'
}
I can then validate it like so:
# schema
schema = SchemaNode(Mapping(),
SchemaNode(Integer(), name='post_id'),
SchemaNode(Integer(), name='author_id'))
schema.deserialize(request.POST)
And it will error if it can't conform the data to the specified schema. So you can see, colander can actually be used to validate ANY set of data, whether that comes from POST/GET/JSON data. Deform on the other hand is a form library, and helps you create/validate forms. It uses colander for all of the validation needs and as you can see it pretty much just completely delegates validation to colander. So to answer your question, you would do all of your validation stuff in colander, and deform would mostly handle the rendering of your forms.
To see a vivid pyramid example application and deform in action look at todopyramid as a part of IndyPy Python Web Shootout. A todo application was implemented in pyramid, django, flask and bottle. I studied the pyramid example - it is well written, shows deform schema validation and uses bootstrap to show validation messages.
Find more pyramid tutorials here:
I'm using the #Check annotation in order to validate my dsl. my dsl is for json.
at first the method was invoked for a specific object and once per change
but it suddenly doesn't work in the same way anymore (and i'm not sure what i've done that effected it)
the method signature is:
#Check
public void validateJson(ObjectValue object) {...}
now its entering this method for each node in the gui although i'm editing only one node
The validator works normally in this case. When Xtext re-parses your model, it cannot always avoid re-creating the EMF model that is validated in the Check expression - in other words, the model is practically re-created every time, thus warranting a full validation.
However, in some cases, it is possible that only a partial re-creation of the model is necessary - in these cases it is possible that not all elements are re-validated (however, I am not sure whether this optimization was included).
I'm am currently building two custom validators that extends Zend_Validate_Abstract which are named respectively Lib_Validate_TimeAfter and Lib_Validate_TimeBetween. The names a pretty straight forward, the first one is used to test if a date/datetime/time comes after an other one and the second is used to test if a date/datetime/time comes between two other date/datetime/time.
Both of those validators would rely on the same method named _buildDate($value) which take a value in the form of a datestamp, a hourstamp(either hh:mm or hh:mm:ss), a timestamp or an ISO_8601 timestamp and convert it in a usable date format.
Since I dont want to repeat myself and copy/paste the method in both of my validator, I was looking for the best way to do it.
The avenues I am looking at right now would be to develop somekind of class helper that my validators would be able to use (kind of messy way of doing things since it add unessesary dependencies) or I could add an other layer of abstraction by building an other validator that validate date/datetime/time and then extend my two validators on that since I could share the method _buildDate($value), but then I don't think I would really need the validator.
So, what would be a good way (I am not really looking for the "Way of the gods" of doing thing) to structure that kind of code to avoid repetition (DRY)?
You might want to build one validator instead of two, where you can pass in a dateBefore, dateAfter which are both optional. If you pass only dateBefore, your $value will be valid if it is after that date, if you pass in both, it will have to be between them and if you pass in only dateAfter, the value will have to be before that date.
This would be flexible, clear, generic, less code and even cover one more case.
What about a class Lib_Validate_Common which extends Zend_Validate_Abstract which has your common method. And Lib_Validate_TimeAfter and Lib_Validate_TimeBetween extends Lib_Validate_Common .
In this question, someone asked how to write a validation method for Core Data. I did that, and it looks cool. But one thing doesn't happen: The validation. I can easily set any "bad" value and this method doesn't get called automatically. What's the concept behind this? Must I always first call the validation method before setting any value? So would I write setter methods which call the appropriate validation method first?
And if yes, what's the point of following a strict convention in how to write the validation method signature? I guess there's also some automatic way of validation, then. How to activate this?
Validation is not "automatic" especially on iOS. On the desktop you will have the UI elements handling the call to validation. On iOS you should be calling validateValue:forKey:error: with the appropriate key and dealing with the error should there be one. The reason for this is the lack of a standard error display on iOS and the overhead of validating all values.
Note this comment in the documentation:
If you do implement custom validation methods, you should typically not invoke them directly. Instead you should call validateValue:forKey:error: with the appropriate key. This ensures that any constraints defined in the managed object model are also applied.