> I implemented a "quick and dirty" solution by subclassing the edit control
> and overriding the setValidationMessage() method to substitute my own message.
If you subclassed, I would suggest to override the validate() method,
call the super.validate() and if that result is ok, proceed with your
validation and you messages, maybe using an additional value set in the
dialog configuration itself, that sets the max allowed length. Something
like this:
if ((result) && (StringUtils.length(this.getValue()) >
Long.parseLong(this.getConfigValue("maxLength")))) {
setValidationMessage(MessagesUtil.get("dialogs.validation.tooLong",
"info.magnolia.module.yourmodule.messages",
new String[]{ this.getConfigValue("maxLength") }));
return false;
}
> I think I will open a bug for this in JIRA...
Current dialogs/controls are totally unable to handle "complex"
validation, until that part is refactored (and I was just hoping in
Magnolia 5 for that) I will try to avoid using Magnolia when users
requires any bit of real world validation. I'm still struggling in a
project that required many validations, and the result was a real code
hell...
Most annoying points are:
- validation is called before the "data" is completely initialized: most
of the work is done in the save methods, both of the saveHandler and of
the various controls, so to have the same data you have to copy-paste
tons of "save()" code.
- there is only a single return message, set with AlertUtil, even if
there are many validation errors.
- there is no graphical hint of the fields that are in error.
Plus a lot of other minor things like MAGNOLIA-3826
Regards, Danilo.
----------------------------------------------------------------
For list details, see http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
