Pls give us a sneak peak about the future validation message

At some thread not long ago, @niden write that phalcon team will develop new validation message class so that we can override the default message. Can the dev team, give us a sneak peak of the interface gonna be implemented? I was hoping the new interface can: * be overriden so that we can write the message in our language * The message can use the Phalcon\Forms\Element::getLabel instead of the getField(). I personaly have "weird" field name that is not suitable to be displayed to the enduser. * Can merge Form validation with Model validation easily


We have some initial thoughts regarding this component which will be introduced in 2.0 if not sooner (time and workload permitting). We will of course discuss it with the community before we move ahead so as to find the best solution that would suit the majority if not all of the community.

At the moment the way we are envisioning this is as follows:

Every string that is echoed from the framework will have a unique key. The keys will be made public to the developer. So for instance at the moment you might get a message ```php Action not defined in CommonController ``` This internally, right now, is echoed as is. However with the new functionality it will be a key to a key/value array i.e. ```php echo phrases['actionnotdefined'] ``` (writing pseudo code here)

The developer will be able to use the new component (which we have yet to name) available through the DI container as follows ```php $phrases = new \Phalcon\Phrases() $phrases->set('actionnotdefined", "What are you doing? Forgot something didn't you?"); ``` which will then echo the appropriate message.

We are also thinking of helper functions such as: ```php $phrases->reset() // resets all strings to their default (English) $phrases->reset(string/array) // resets string or array of strings to the defaults $phrases->list() // Offers a json list of all the key/value pairs $phrases->get(key) // Gets the text of a key. ```

Note that these are just initial thoughts and we will definitely discuss this with the community prior to implementation. The above is a rough draft of what we are thinking of. Implementing this as is (procedural/stand alone component) would be OK but we are also thinking of hooking up interfaces to this so that (as Jeffrey pointed above) they can be extended at will.