| Core Expressions Debugging [message #481623] |
Fri, 21 August 2009 23:25  |
 Stephen McCants
Messages: 92
Registered: July 2009 |
Member |
|
|
Hello,
I've started working with Core Expressions, PropertyTesters, SourceProviders, Handlers and Menus
recently. A lot of that work involves connecting the correct extension points in the correct manner
to get the desired results. I just got my Copy/Paste/Cut handlers working correctly for a specific
(complex) part of my editor, so in some sense I'm asking this question too late.
I spent a lot of time on the learning curve of what these different pieces are and how they
interact. However, I found one aspect of learning and implementing this particularly frustrating,
so I'm hoping someone can give me some pointers on how to handle this better in the future. It is
very easy to make small errors in the plugin.xml (even with the help of the Extensions tab) or
simply not know how things work and connect things incorrectly. I found it very frustrating,
because I could find no good way to see what was happening and where things were going off track.
Here is what I tried:
- Setting break points in my code. Didn't help when my code wasn't being called (because of XML errors)
- Turning on tracing. Didn't provide any insight (maybe I picked the wrong tracing options).
- Reading the Error Log. Didn't help because there wasn't anything logged there.
Is there a really good way to find these XML problems (short of staring at the code for hours on
end and reading newsgroups/tutorials/documentation in hopes of understanding my mistake)?
If you are sensing some frustration on my part, then you are sensing correctly. However, I don't
want to turn this into a rant but I'm hoping something positive will come of it. I spoke with one
of my co-workers today and he has had similar frustrations with this XML, so I know I'm not alone in
my frustrations.
If there aren't any good ways to debug this stuff, then I'd like to suggest some brainstorming for
Eclipse 3.6 to alleviate the opaqueness of plugin.xml problems. Better tracing would seem like a
good option to me or even logging warnings in the ErrorLog when extensions don't make sense (e.g.
referencing IDs and classes that aren't there).
Thoughts? Advice? Suggestions?
Thanks!
Sincerely,
Stephen McCants
|
|
|
| Re: Core Expressions Debugging [message #481829 is a reply to message #481623] |
Mon, 24 August 2009 13:37  |
|
I'm both interested in better tracing (tracing that can make sense of what is going on) and brainstorming on debugging strategies.
For tracing, the example we have is most useful for finding out why a specific command is not being called when you expect:
http://wiki.eclipse.org/Platform_Command_Framework#Tracing_O ption
For debugging, I think there are 2 parts. 1), we need to get help from PDE as much as possible. The commands/handlers/menus extension points use reference identifiers for as much as possible. Attributes (like commandId) that are reference identifiers should create warnings in the Problems view if you reference a command that doesn't exist (as they do if you reference a class that doesn't exist). Most declarative attributes are linked by reference identifiers where possible. One useful attribute that is not, unfortunately, is menuContribution/@locationURI but the support for building complex attributes is not available.
2) The second part is "how to tell when and what my core expression is being evaluated to?" The IEvaluationService has a lot of internally moving parts, to support expression changes and notifications based on source provider events and evaluation requests ... if there was a way to target a specific expression maybe it could be traced without spewing out *huge* amounts of stuff ... but it would take careful examination of the code to add that kind of feature.
PW
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
Powered by
FUDForum. Page generated in 0.03298 seconds
] 
Search
Help
Register
Login
Home
