What is the use of .# in groovy? Can anyone explain me with a code snippet?
Have you seen the official documentation? It contains nice code samples.
Essentially, when you use normal . operator, you access fields indirectly, using implicitly generated getters/setters. However, .# allows you to access the field directly, skipping getter/setter.
This can be useful when you want to avoid some additional logic implemented in getter/setter and change the field directly. Violates tons of OOP principles, but the authors of Groovy found this construct to be useful.
That's the Java Field operator (according to the documentation)
There are examples in the documentation.
It is also used for accessing attributes when you are parsing XML (again, there's an example if you follow that link).
Related
I have been playing with ANTLR Lab (really nice by the way) and was wondering how it is able to label the matching parser rule and alternative number. For example, below content:1, x_tag:2 and x_tag:3 are all rule names and the number after the colon is the alternative within that rule.
I have built a recognizer from my grammar but cannot see from looking at the runtime API how to access them from within a custom listener.
AFAIK, ANTLR Lab and the ANTLR IntelliJ plugin both use the RuleContextWithAltNum to set and get the alternative.
Note that it is only implemented in Java. From the documentation:
A handy class for use with options {contextSuperClass=org.antlr.v4.runtime.RuleContextWithAltNum;} that provides a backing field / impl for the outer alternative number matched for an internal parse tree node. I'm only putting into Java runtime as I'm certain I'm the only one that will really every use this.
Also see the related stackoverflow Q&A: Is there a way to know which alternative rule ANTLR parser is currently in?
For a Groovy or Java class or method, I would generally include any API-level documentation in a doc comment (aka Javadoc comment), rather than a regular comment. What is the analogous way of adding such comments about a Groovy script?
I personally don't care so much about whether the Javadoc tool picks up the documentation. However, documentation about the purpose of a Groovy script seems conceptually analogous to a doc comment on a class; therefore, I would intuitively expect them to be in a doc comment. If my intuition is wrong and doc tags are not the standard way of commenting the intent of a Groovy script, what is the preferred method to document the purpose of a script?
The syntax section of the Groovy language specification defines the elements that a Groovydoc comment can be associated with:
[Groovydoc] comments are associated with:
type definitions (classes, interfaces, enums, annotations),
fields and properties definitions
methods definitions
Although the compiler will not complain about Groovydoc comments not being associated with the above language elements, you should prepend those constructs with the comment right before it.
A script has no class type definition to put the Groovydoc comment before.
There is an open issue requesting this functionality in the Groovy issue tracker at GROOVY-8877:
Groovydoc doesn't offer any direct way to document Groovy scripts. It will process comments on classes in a Groovy script, but not any sort of file-level or top-level comment.
In summary, script-level Groovydoc comments are not currently supported in a Groovy script file.
I'm new to MediaWiki skin design. I have found these two functions being used heavily.
QuickTemplate::html($str)
QuickTemplate::text($str)
These are used in execute() function in the custom Template class, as $this->html($str) and $this->text($str)
I'm pretty ok with their functionality. But, so far, I haven't found a reference for the list of string arguments fed through the $str parameter. I've seen them being used in templates with various arguments like, $this->html( 'headelement' ), or $this->text( 'pageLanguage' ). My question is how do we exactly know the the argument is 'headelement' ? Is there a complete list of such arguments? Not sure whether I'm missing some part of the documentation.
Well, did you try the QuickTemplate Class Reference and Using QuickTemplate in extensions?
The functions html() and text() don't really do anything, they seem just a way to supposedly "abstract" the handling of HTML strings vs. all other strings: text() escapes the HTML a bit. Mostly a historical thing.
As the manual says, please don't use QuickTemplate :), follow the skinning template.
In JaxB, we need to move from one schema form to another and we would love to be able to deprecated stuff in the xsd with some simple note in the xsd:documentation element or something. Is there a way to get JAXB to mark these generated classes and methods with #Deprecated so developers can easily see which cold still needs to change?
thanks,
Dean
I would recommend the Annotate plugin: Annotate plugin(edit: the original link is no longer valid).
You'll see a couple of examples, including deprecation, warning suppression, etc.
It is usually recommended to do this stuff using special markup under appinfo as opposed to documentation.
I finally got all of mine working quite nicely...thanks!!!! The complete code is found here
JAXB External Custom Binding XJC Issue - Parsing results in empty node
Is there a quick way to find out all the mandatory field in a xsd file?
I need to quickly see all the mandatory fields in the schema
thanks
Not sure if you're looking to do this through code. If not, Altova XMLSpy, for example, provides an option to "Generate Sample XML File" - with options to generate only mandatory fields.
Otherwise, if you're working with Java, for example, you can use something like the Eclipse XSD project for programmatic access to the XSD. (It even works without Eclipse.) Some additional details at Are there any other frameworks that parse XSD other than XSOM? .
Take a look at this post; instead of exporting all fields, there's also an option to get only the mandatory ones... One significant difference compared with the answer you accepted is in that you can also generate an Excel or CSV file, in addition to the XML file; not to mention that the sample XML approach is deficient by definition... I would pay attention to the way mandatory choices, abstract typed elements or abstract elements with substitution groups play in your case.