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.
Related
We are trying to use Stardoc when generating documentation for our Bazel macros.
I can get a table generated with parameter descriptions when follow the instruction here:
Macro/Function documenatation.
But we would also like to add the parameter Type in the table.
According to DocstringUtils.java it seems like we shall write the type in parentheses after the parameter name but before colon, as this example:
another_parameter (unused, mutable): a parameter may be followed
by additional attributes in parenthese
I have seen that it's possible to add a rule template to the stardoc() rule (attribute: func_template).
I started to use an own copy of the default template to play around with: //stardoc:templates/markdown_tables/func.vm
If I have understood correctly it doesn't seem that the attributes that I add in paranthese is fetched.
And I don't think that I will be able to retreive that information by just updating the template.
So I think that it will need an update in the Stardoc code for this, correct?!
Is that something that is already planned?
If I'm not correct then I would appreciate information how I can retreive the value of the attribute.
Thanks!
Best Regards
Elisabeth
In AppiumLibrary, as of version 1.4.5, a very handy keyword called Element Should Be Visible has been introduced. But I am looking for the opposite version of that keyword too, which would be something like Element Should Not Be Visible. Since AppiumLibrary doesn't have that yet, is there any way we could achieve this?
There's always the possibility of expanding the library's python code, this shouldn't be very difficult. You basically just need to clone the Element Should Be Visible keyword definition and change the condition to do the opposite.
But, if that's not a possibility for you, perhaps you could use the keyword Run Keyword And Expect Error, in combination with the keyword you mentioned, Element Should Be Visible. Using this keyword on an element that isn't visible would throw an error, which in this particular case would be the desired outcome.
Still, that's a fishy workaround which will not help the readability of your test, and you should consider first looking into expanding the library itself.
Thanks to Verv for the guidelines. I tried both approaches that he suggested, and both seem to be super easy. For future reference, I'm explaining both methods here.
Method 1:
Under AppiumeLibrary/keywords directory, there's a file called _element.py, which defines the Element Should Be Visible keyword. I was able to clone it to create the new keyword I was looking for.
Below is the code snippet that defines Element Should Be Visible
def element_should_be_visible(self, locator, loglevel='INFO'):
"""Verifies that element identified with locator is visible.
Key attributes for arbitrary elements are `id` and `name`. See
`introduction` for details about locating elements.
New in AppiumLibrary 1.4.5
"""
if not self._element_find(locator, True, True).is_displayed():
self.log_source(loglevel)
raise AssertionError("Element '%s' should be visible "
"but did not" % locator)
Next to the above code snippet, you can add the following code snippet to define a new keyword Element Should Not Be Visible
def element_should_not_be_visible(self, locator, loglevel='INFO'):
"""Verifies that element identified with locator is visible.
Key attributes for arbitrary elements are `id` and `name`. See
`introduction` for details about locating elements.
New in AppiumLibrary 1.4.5
"""
if self._element_find(locator, True, True).is_displayed():
self.log_source(loglevel)
raise AssertionError("Element '%s' should not be visible "
"but did" % locator)
Method 2
If you don't want to expand the existing library, you could just use the combination of existing keywords as follows:
${isVisible}= Run Keyword And Return Status Element Should Be Visible 'someElementSelector'
Should Be Equal ${isVisible} ${FALSE}
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
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".
Tagsoup is interfering with input and formatting it incorrectly. For instance when we have the following markup
Text outside anchor
It is formatted as follows
Text outside anchor
This is a simple example but we have other issues as well. So we made tagsoup cleanup/formatting optional by adding an extra attribute to textarea control.
Here is the diff(https://github.com/binnyg/orbeon-forms/commit/044c29e32ce36e5b391abfc782ee44f0354bddd3).
Textarea would now look like this
<textarea skip-cleanmarkup="true" mediatype="text/html" />
Two questions
Is this the right approach?
If I provide a patch can it make it to orbeon codebase?
Thanks
BinnyG
Erik, Alex, et al
I think there are two questions here:
The first Concern is a question of Tag Soup and the clean up that happens OOTB: Empty tags are converted to singleton tags which when consumed/sent to the client browser as markup gets "fixed" by browsers like firefox but because of the loss of precision they do the wrong thing.
Turning off this clean up helps in this case but for this issue alone is not really the right answer because we it takes away a security feature and a well-formed markup feature... so there may need to be some adjustment to the handling of at least certain empty tags (other than turning them in to invalid singleton tags.)
All this brings us to the second concern which is do we always want those features in play? Our use-case says no. We want the user to be able to spit out whatever markup they want, invalid or not. We're not putting the form in an app that needs to protect the user from cross script coding, we're building a tool that lets users edit web pages -- hence we have turned off the clean-up.
But turning off cleanup wholesale? Well it's important that we can do it if that's what our usecase calls for but the implementation we have is all or nothing. It would be nice to be able to define strategies for cleanup. Make that function plug-able. For example:
* In the XML Config of the system define a "map" of config names to class names which implement the a given strategy. In the XForm Def the author would specify the name from the map.
If TagSoup transforms:
Text outside anchor
Into:
Text outside anchor
Wouldn't that be bug in TagSoup? If that was the case, then I'd say that it is better to fix this issue rather than disable TagSoup. But, it isn't a bug in TagSoup; here is what seems to be happening. Say the browsers sends the following to the client:
<a shape="rect"></a>After<br clear="none">
This goes through TagSoup, the result goes through the XSLT clean-up code, and the following is sent to the browser:
<a shape="rect"/>After<br clear="none"/>
The issue is on the browser, which transforms this into:
<a shape="rect">After</a><br clear="none"/>
The problem is that we serialize this as XML with Dom4jUtils.domToString(cleanedDocument), while it would be more prudent to serialize it as HTML. Here we could use the Saxon serializer. It is also used from HTMLSerializer. Maybe you can try changing this code to use it instead of using Dom4jUtils.domToString(). You'll let us know what you find when a get a chance to do that.
Binesh and I agree, if there is a bug it would be a good idea to address the issue closer to the root. But I think the specific issue he is only part of the matter.
We're thinking it would be best to have some kind of name-to-strategy mapping so that RTEs can call in the server-side processing that is right for them or the default if it's not specified.