The following replaces any current css class names. It appears to call setStyleName.
<g:DecoratorPanel styleName="{style.myCssClass}">
What I really want to do is add a class name, like calling addStyleName.
Is it possible to do what I'm attempting?
Use addStyleNames in such situations, like this:
<g:DecoratorPanel addStyleNames="{style.myCssClass}">
It's a little trick I picked up on the GWT's Google Group - too bad it's not (?) mentioned in the official documentation.
PS: I'm actually missing a really comprehensive documentation for UiBinder. I grepped the GWT sources for addStyleNames and found this file: WidgetBasedUi.ui.xml - it seems to contain some interesting use cases for UiBinder, including the one with addStyleNames.
If someone knows any other good/secret references for UiBinder, please share :)
Yes addStyleNames is the solution. And it is actually mentioned in the documentation: UiObject. See section "Use in UiBinder Templates".
Related
I tried googling this question a lot but could not find the answer to exact question. I also read this question: Does the javadoc tool recognize comments inside methods?
So my question is kind-of a follow-up to this. I know that default JavaDoc tool would simple ignore any javadoc comments inside methods, but can we somehow make it read those comments too and may be try handling them on our customer doclets/ taglets? I tried writing my own doclet and taglet as well but since JavaDoc would completely ignore the comments inside methods, I could not succeed.
For example, suppose I have the following code:
public void methodX() {
/**
* #MyTag This is a sample javadoc comment with custom tag
*/
}
Is there a way to make JavaDoc not ignore the comment inside methodX? I could handle the response in a custom doclet if javadoc could parse and provide the comment text.
Reason to try this:
I guess it would be helpful to know why I'm looking for such a requirement. Basically we have a lot of configuration driven coding where these configurations are stored in DB (So that we could simply change the configuration at runtime without having to go through the BRD process again). So we are planning to document those configurations at a central place. And instead of keeping the code and document separate, we also think it would be wise to keep the documentation closer to code itself so that any code updations could also possibly update the documentation. Publishing to central place can be taken care of via doclets/ taglets but only if JavaDoc could read those comments inside methods.
So is there a possibility of making JavaDoc tool read through comments inside methods as well? Or else we would have to try and write our own comments parser similar to JavaDoc for this.
So I did a little digging around and seeing that no-one has answered the question, it seems people are (maybe) not sure about the possibility.
Based on what I found, it doesn't seem feasible to have the JavaDoc tool parse the comments inside methods. The reason being, JavaDoc doesn't even get those comment texts to parse. Now, what I mean here is, JavaDoc relies on the JDK compiler (the API of-course) to have the Java code converted into tokens and trees and then gets all the comments from there. So unless you are okay modifying the JDK compiler itself to make it "Do Not Ignore" the comments inside methods, you can't make JavaDoc to read comments inside method.
Oh! And for the part of solving our problem, we're, for now, restricting to define JavaDocs with custom Tags for the constants we used and have the comments processed via a Custom Taglet to handle the new Tags.
Is there a way to add to a description in a methods quick documentation? I have some methods I created that I plan to use later down on the line and want to add to its quick documentation to remind myself what the method is for in case I forget, without having to go into the method itself to read comments describing what the method does.
Is there a way to add to a description in a methods quick documentation?
The best way to document your methods is giving them (and their parameters) meaningful names.
Comments should not repeat what the code expresses itself. But no generator will ever look into your head to extract your intention from there. It rather will analyze the code and build the comment based on what's already written.
Therefore (meaningful) comments cannot be generated.
There are two valid reasons why you should write comments (yourself):
Interfaces
Interfaces need (JavaDoc) comments to explain the contract behind the method, to express the callers expectation as a help for the implementer.
odd ball solutions
Is there something in your code done in an unusual way?
Then add a comment why you did it so.
There might also be comments for legal reasons e.g. copyright marks, license texts and alike. But there should not be any other comment then this, especially nothing generated.
If you want to put comments in a single place for an entire project, or keep comments co-located with a set of files, try using a README. These are usually written in Markdown for easy conversion to beautifully formatted HTML for easier reading. Try an online markdown editor.
I have always had problems reading documentation for example
I was just researching about file paths for java and I so this :
"
Usage Example:
Path file = ...
BasicFileAttributes attrs = Files.readAttributes(file, BasicFileAttributes.class);
"
//http://docs.oracle.com/javase/7/docs/api/java/nio/file/attribute/BasicFileAttributes.html
What is ..... ??? :|
I know im not a expert but example code that is full coded would be nice, Or Is is it becouse im not at that
level yet...
I tried testing it..did not even run :(
Please Help
API documentation is meant to give you details about a particular class and serve as a reference to come back to. It's purpose is not to provide you with an explanation how concepts fit together. So ... stands as a placeholder for any code that might make sense in a particular use case. For a general overview Oracle hosts an excellent set of tutorials.
And if you want to see even a bigger picture, I can recommend an excellent book Thinking in Java.
The ... is called an ellipsis, and means that something has been left out there. On this case, it's a call to the Path constructor, putting a path in place ready for the rest of the code.
They do that because they don't want to clutter the example with extraneous stuff.
If you want fully coded examples, the Java Almanac has good ones, albeit a little dated.
http://www.amazon.com/The-Java%C2%BF-Developers-Almanac-Volume/dp/0201752808
I've noticed that Eclipse automatically adds an #author tag with my name at the top of a new Java class. I also noticed that there are other tags available like #version, #link, #code, #value, #see...
Is it just another 'convention' that has formed so that code remains well-documented? Or is there some other purpose?
I tried finding a website that would give better descriptions of the tags and their usage, but I didn't have any luck.
These are Javadoc tags related to the Javadoc mechanism. When you'll generate the Javadoc (there's an option in the Eclipse menu for that), those link will be interpreted appropriately and the Javadoc will be better detailed. See the link in the comment for the list of all available tags.
Underestimate the power of documentation you will not.
I couldn't really find anythingon this anywhere: i'd like to use custom annotations with doxygen. To be more exact, I have an #android before every method thats supported on android, and would like doxygen to recognize, support and link his, similar to what it does with xrefitem. Is that possible?
The ultimate awesomeness would be to be able to do some light inference on this. For example, i'd like to infer he supportion level of a class from the percentage of it's method that are annotated wih android. I knowhat i can do somthing like that with java and inspectors, i'm just not sure if i could do this with doxygen.
Thanks a lot!
If you start with reading the documentation for \xrefitem here:
http://www.doxygen.org/commands.html#cmdxrefitem
you'll find that you can define custom commands via ALIASES, which are documented in more detail here
http://www.doxygen.org/custcmd.html
The computation of a 'coverage level' is not directly supported. You could check if you can use doxygen's XML output for that (see config option GENERATE_XML).