Modifying error messages for Command Objects embedded in controller - grails

I am trying to modify the messages.properties file for form input validated by a Command Object that is in specified in the controller. The output I get from the standard error message (that I modified slightly to assure I was hitting that specific one) is:
email cannot be empty test class com.dashboard.RegisterController$DashboardUserRegistrationCommand
but no variant of com.dashboard.RegisterController$DashboardUserRegistrationCommand.null.message
works
I am wondering what the correct specification should be.

Try to put DashboardUserRegistrationCommand outside (below) of RegisterController but still in the same file. Then com.dashboard.DashboardUserRegistrationCommand.. should work.
i.e. com.dashboard.DashboardUserRegistrationCommand.message.nullable

The typical layout of error messages is:
${packageName}.${className}.${propertyName}.${errorCode}
So for your example it would be:
com.dashboard.DashboardUserRegistrationCommand.message.nullable
In the Grails Reference on the right hand side there is a header titled 'Constraints'. On each page of the specific constraints listed under that header the ${errorCode} value is listed at the bottom of the page.
And sometimes you have to restart a run-app to get new messages to populate in a Grails project.

Just to help others in the future, I had the same issues and my problem was the way I was defining my key, I use now:
For default messages:
default.null.message=Write a value for {0}
For commmand error messages:
my.package.UserCommand.name.nullable=Please tell us your name
It is strange that sometimes you use nullable and sometimes you use null. The best thing is going to the Grails Constraints directly and check how is it done for example:
http://grails.org/doc/latest/ref/Constraints/nullable.html

Related

Log4j2 JsonTemplateLayout issue

I am trying to set up json logging for log4j2 described here:
https://logging.apache.org/log4j/2.x/manual/json-template-layout.html
However, the format of the output is not matching what I expect. This is what I am getting:
{"#version":1,"source_host":"localhost","message":"hello world","thread_name":"main","#timestamp":"2021-08-17T15:44:54.948-04:00","level":"INFO","logger_name":"com.logging.test.LoggingTest"}
At first I created my own template but this wasn't working so I set it to the logstash one described in the docs:
<JsonTemplateLayout eventTemplateUri="classpath:LogstashJsonEventLayoutV1.json"/>
I am not getting the line number in the output or a lot of other fields. I know it is picking up the eventTemplateURI field because if I set it to a value I know doesn't exist then I get an exception on start up.
I am using log4j-slf4j-impl, does anything special need to be done to make it work with this?
Thanks

Can a <name> tag have a #nullValue and still have text inside?

The current implementation of a CCDA generator I'm working on, prints a message on a <name> tag (in header sections, where no <text> is available) when something's name is not found:
<name>No information</name>
I know the right way to express not found information is through the #nullFlavor attribute:
<name nullFlavor="NI" />
But right now there is a component on the application that reads the value on the tag and shows it in a human-readable view of the CCDA document. If I use #nullflavor only, the field that shows such name will be empty, instead of "No information".
In order to avoid changing such component, I was thinking on adding the #nullFlavor attribute but still letting the message there:
<name nullFlavor="NI">No information</name>
I know this is syntactically correct, because I've tested it with the reference validator and it passes. My question is: from a semantic point of view, is it valid?
Yes it's valid. The particular specification in question - the v3 abstract data types, simple says:
invariant(ST x) where x.nonNull {
x.headCharacter.notEmpty;
};
So if there's no nullFlavor, there must be some content. But the reverse rule is not applied; there can be content if there's a nullFlavor
Although it is not restricted, my point of view is that it is not a good strategy. I understand that you have a restriction regarding this component but, when you are building a CDA, it is important to keep in mind that it is something to be shared with everyone, and I would never expect to find content inside a nullFlavor attributed element.

built-in language change doesn't work at Grails2

I have Grails 2 application where I've already added i18n/messages_ru.properties. So, according to documentation I use request ?lang=ru (f.e. userOperations/index?lang=es) but nothing changed. Languages is still default, lang cookies wasn't created.
What's wrong? How can I fix it up?
PS. I use Oracle Java7 on Ubuntu
What are you expecting to change? If you look at the default index page (the one that lists controllers, etc) it doesn't use messages - it's all hard-coded.
I just tested and it works for me in 2.0.3. Here is what I did:
Create new Application
Create domain class with single field (String name)
Run "Generate All" for that class
The gsp's created will have something like this:
<g:message code="yourDomainClass.name.label" default="Name" />
Now if I don't do anything and look at the page, even with lang=ru or lang=es it is STILL going to say Name. But then I went in and added to the messages_es.properties file the following:
yourDomainClass.name.label=Nombre
and when I refreshed the page it says "Nombre" instead of "Name."
There are defaults in the message files for certain messages like "default.home.label" and when I used the lang=es those did change to Spanish like they should without me doing anything.
The problem is that you configured url(or it was default "/"(view:"index")) mapping to render view directly without a controller. Create a controller and render a view in it. Without a controller it doesn't work!

grails i18n error customization: various inconsistencies

As an example, the default i18n message in message.properties for blank fields is:
default.blank.message=Property [{0}] of class [{1}] cannot be blank
If one wants to customize this with a given class (e.g. user) and field (e.g. login), one does
user.login.blank=Your login name must be specified
with the ".message" suffix left-off. This threw me off for a bit (as I had it in there and it didn't work), so I'm wondering if there is a specific purpose to how the ".message" suffix is used / not used in message.properties?
There seem to be quite a bit of mismatches in the use of message customization, beyond just the use of ".message". See example below*.
I believe the grails software developers might include a comment at the top of the message.properties file, guiding the user to look at the right place for defining the custom error messages, e.g. in the Constraints quick reference list, http://www.grails.org/doc/latest/ref/Constraints/matches.html. The top level Contraints section in the quick reference does not include the error code field names, but might it be useful to add there.
*For example, the default match failure is "default.doesnt.match.message", but the specific error is, for example, "user.login.matches.invalid".

Omit attribute name from validation error message (at start of it)?

I write code in English but I'm currently doing a site which is fully translated to another language (validation error messages included). However, I have a problem because validation error messages always seem to include the name of the attribute the error is on at the start of the error, e.g.:
Title Prosimo izpolnite naziv fakultete.
I want to get rid of the Title at the start, like so:
Prosimo izpolnite naziv fakultete.
Any help is appreciated. I would rather see if this can be solved without installing any 3rd party plugins.
If it's possible to provide translations for attribute names, that would be a cool solution too, but I would still like to know how it can be done both ways (omit or translate).
There is no need to use the error_messages_for helper for errors, you can write your own helper using the record's errors attribute.
You can just iterate over the error objects and display their messages.

Resources