AbstractAnalysisElement.setLabel() bug? [message #85742] |
Mon, 23 October 2006 11:33  |
Eclipse User |
|
|
|
Originally posted by: matthew.gregory.us.michelin.com
I'm using AbstractAnalysisElement.setLabel() to add a tiny bit of
information to make the analysis output more useful for a custom rule I've
written. It works like I expect for the tooltips which appear when I
hover over the marked-up source (my additional information is relevant to
the specific line of code). However in the output in the Analysis Results
view, all of the items display the text of the last time setLabel() was
called, meaning all of the messages are the same. Is this a bug or am I
doing something wrong? Bugzilla reported Zarro Boogs when I searched, so
at least I don't think it's identified if it is one.
Thanks,
matt.
|
|
|
|
|
Re: AbstractAnalysisElement.setLabel() bug? [message #85856 is a reply to message #85843] |
Tue, 24 October 2006 11:08  |
Eclipse User |
|
|
|
OK I understand what you want to do now, but there a couple of problems with
what you are trying. First you are trying to set the label on the rule.
Your analysis code is run for every resource you are trying to analyze, so
all you would would be doing with your sample code is set the rule label
each time the result is run.
What you really want to do instead is set the label on the result that you
generate , and this opens an bigger can of worms. The current code review
(4.2.1) generates this label when the CodeReviewResult.getLabel() is called
so even if you do set it it won't appear in the user interface - note that I
would like to change this (probably in TPTP 4.4) to allow result label
modifications. In the meantime you can try subclassing CodeReviewResult and
implement your own handlers for get/setLabel() and instead of using the
resource.generateResultsForASTNode() to generate your results, create them
yourself by cloning that method in your rule class and make the correct
adjustments to reference your own result class.
This "should" work. Let me know if does and we can plan for this
enhancement in a future TPTP release. It's always nice to see how people
want to distort our framework - this is great feedback that will make the
tool better. Keep pounding on it. :-)
Steve
"Matt Gregory" <matthew.gregory@us.michelin.com> wrote in message
news:fae5ed01051ad85d9e6091970dd3753a$1@www.eclipse.org...
> Didn't expect it to be something altogether unexpected ... from javadoc:
>
> AbstractAnalysisElement
> setLabel(java.lang.String newLabel) "Allows an analysis element to
> configure it own display label"
>
> Here's what I'm doing:
>
> ----------
> public void analyze(AnalysisHistory history) {
> // Extract the resource being analyzed
> CodeReviewResource resource =
> (CodeReviewResource)getProvider().getProperty( history.getHistoryId(),
> CodeReviewProvider.RESOURCE_PROPERTY );
> ..
> List fieldNodeList = resource.getTypedNodeList(
> resource.getResourceCompUnit(), ASTNode.FIELD_DECLARATION );
>
> // For each field found, determine if it is from an approved API
> for ( Iterator iter = fieldNodeList.iterator(); iter.hasNext(); ) {
> FieldDeclaration field = (FieldDeclaration)iter.next();
> String fieldPkg = RuleUtils.findPackage( field );
> if ( !RuleUtils.isSubpackageOf(fieldPkg, approvedApis) ) {
> this.setLabel( "Only use authorized APIs: " + fieldPkg + " is not
> allowed" );
> resource.generateResultsForASTNode( this, history.getHistoryId(),
> field );
> }
> }
> ----------
>
> A couple of utility methods you won't recognize findPackage() and
> isSubpackageOf(), but I don't think they're pertinent. The rule's label
> in the plugin.xml is "Only use authorized APIs". The information I want
> to add to the tooltips and other output is the offending API.
>
> Another interesting behavior I noted while testing this is using something
> like setLabel( getLabel() + ": whatever" ) resulted in output like:
>
> Only use authorized APIs: whatever
> Only use authorized APIs: whatever: whatever
> Only use authorized APIs: whatever: whatever: whatever
> etc.
>
> Thanks for the help!
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03047 seconds