Re: [platform-ui-dev] Passing Objects in Commands & Testing them

["Paul Webster" <pwebster@xxxxxxxxxxxxxxxxxxx>]

On Tue, Jul 22, 2008 at 7:26 PM, gommo <colin.goudie@xxxxxxxxx> wrote:
>
> This is a deliberate repost from the swt newsgroup as I was told this is the
> best place to put it, so sorry for those subscribed to both.

Actually, they probably meant for you to re-post to the newsgroup
eclipse.platform, as platform-ui-dev is a forum for developing eclipse
itself and eclipse.platform is for these types of questions.  You
should ask questions like this there in the future, but I won't send
you away empty handed :-)

> We're using eclipse RCP 3.3 and are making heavy use of the newer
> command/handlers. I have 2 questions
>
> 1. It appears that everything you pass around in eclipse is String based?
> What is the reasoning behind that? Is there any way I can pass Java objects
> to my handlers instead apart from passing strings to use for lookups using a
> 3rd party object?

Do you mean w.r.t. command parameters?  Command parameters are static
in nature, and because they need to be provided by keybindings and
menu contributions must have a string representation.  They can be
objects (like an IResource, for example), but those will have a
parameter converter, usually a subclass of
AbstractParameterValueConverter, that can convert the parameter object
to a String and back.  A handler can use
org.eclipse.core.commands.ExecutionEvent.getObjectParameterForExecution(String)
to get the object instead of the String representation for a
parameter.

The other way to pass your parameter objects to a command is to add
them to the application context, an IEvaluationContext also retrieved
from the ExecutionEvent.  The IHandlerService can create retrieve the
current IEvaluationContext and new variables can be added.  An
ISourceProvider can also provide variables to the global application
context.

> 2. The more we develop the more things end up in our plugin's plugin.xml
> file? What strategies are people using to test that this file is wired up
> correctly? It seems awfully easy to break things in this file and without
> tests we don't catch it. I'm looking for any pointers here to push me in the
> right direction.

AFAIK, that's still the case for the declarative definitions.  In 3.4
PDE upgraded to 1) allow many cross-linked fields to offer the user a
choice from the Target Platform (i.e. a commandId field will let you
browse the list of defined commands) and 2) report warnings when an ID
cannot be matched.


> Also, for testing, we have our handlers etc.. broken out into separate
> classes for testability purposes. However, we find they are still using
> certain Singleton classes such as PlatformUI and HandlerUtil. Do people tend
> to mock these out using a custom object to ensure their handlers are
> testable?

PlatformUI should be avoided as much as possible, for the reasons you
mentioned.  It's used to retrieve a global starting point, one that
can often be retrieved from either the ExecutionEvent or the part or
window visible to the handler (depending on how the handler was
created).  However, sometimes it is necessary.  In 3.4, many more of
the workbench services were made available through the service locator
(i.e. getSite().getService(ISelectionService.class);).

HandlerUtil isn't a singleton (per se) but simply a collection of
helper methods that extract data out of your ExecutionEvent.  It
contains no state.  You can do it yourself (and have to for any
variables that you contribute) but for the common ones provided by the
workbench, why not use the workbench helper.

As mentioned, please direct any followup and new questions to eclipse.platform.

Later,
PW


-- 
Paul Webster
Hi floor. Make me a sammich! - GIR