Viola! Heed the cautionary voice of a volunteering veteran on the veritable vices of the vulgar habit of non-convention. The victims who venture upon the vast theatre of validation, and share vicariously in their pain of projects vacant of vanguards and void of standards.
For when vigilance and virtue are violated it inevitably veers into virulent and volatile misadventures. Vexation awaits in a variety of vindictive vicissitudes.
Verily, variable validation verbiages are but an illusive veneer and vastly vaunts the vanity of instant gratification.
These false visions vandalise our view and must be vanquished with vigour and conviction for inevitably their visitation will be violent and our valuable development time will suffer viciously by their virtual and voracious vengeance.
We must vouch to vacate such vices and lift the vale of vague validation, vindicating us from villainy.
It is vital, to conventionalise is to be victorious!
Validation is a surprisingly tricky business
Its also a vital part to any software system. It helps keep the state of the application sane. When you work in big teams on a project, one has to establish best practices and conventions in order to avoid validation errors, especially compound string validations.
Lets take an example
You want to validate a bunch of rules and return the list of messages in a SOAP response, or store it in a database or show them in a pop-up. What happens if you return a positive response? Do you return a blank, or an empty in your microflow? Do you assert positive, or negative? Is it clear for the next person who works on this. Is it explicit?
Some developers test for blank strings, others test for an empty value, others use brute forces and test for both. Lets face it, its dirty asserting something so implicit, not to mention the fact that having all these tests around your model is not a very good way of enforcing a pattern.
If you don’t, the harder it will be to maintain the model, because you will be forced to make assumptions that isn’t obvious.
The moment another business engineer uses your microflow, he (or she) will need to know what constitutes a successful or failed validation inside a split-node or the result of a microflow. Its implicitness can ruin your model further down the road.
For example: You want to return a message saying that both name and surname are mandatory fields and the are missing in some input. The final validation message would read like:
The following errors need to be corrected:
– Please specify name
– Please specify surname.
If your microflow returns a string you can assume that validation failed. So far all is good, except how do you test for a positive validation? Do you check if the string is empty or have a string value of blank or both?
stringValidation != ” (meaning success)
or stringValidation != empty
or both the above assertions
All shapes and sizes
In a large project, each business engineer adopts his or her own style of assertion and that makes for lots of pain and suffering later in the game when someone else has to maintain it. Your code might work, but someone else might break it.
Implicit code doesn’t read well. Although you might annotate a split in a microflow, the expression on the inside could be cryptic.
We see that despite having an awesome tool like Mendix, there is no excuse to throw away good practice, conventions and discipline out the window. Its a precision tool that needs precision skill to wield it.
In part 2 of V for validation series, I’ll discuss
our vendetta a potential solution to this problem and part 3 add the additional complexity of maintaining validation in the context of I18N.