Eclipse Community Forums: Rich Client Platform (RCP)

Home » Eclipse Projects » Rich Client Platform (RCP) » Command Parameters

Wed, 07 October 2009 10:55

Eclipse User

I'm sure this must have been asked a thousand times, but I can't find a definitive answer anywhere.

I want to pass a domain object to a Command handler, but of course Command parameters are String objects. I read that String command parameters are really for view ids or similar, which is fine - it feels wrong and fragile to pass around simplified Strings lookup keys for my own domain objects, and I won't always necessarily get my data from a selection provider, so is there an accepted way to do this?

As I type this, I'm wondering if it is a design flaw on my part to not get my data from a selection provider? Is that the correct way to do it?

Any pointers gratefully received,

Bob Walker

Re: Command Parameters [message #490246 is a reply to message #490153]

Thu, 08 October 2009 01:09

Eclipse User

Bob Walker wrote:
> I want to pass a domain object to a Command handler, but of course
> Command parameters are String objects. I read that String command
> parameters are really for view ids or similar, which is fine - it feels
> wrong and fragile to pass around simplified Strings lookup keys for my
> own domain objects, and I won't always necessarily get my data from a
> selection provider, so is there an accepted way to do this?
>
> As I type this, I'm wondering if it is a design flaw on my part to not
> get my data from a selection provider? Is that the correct way to do it?

I *think* the decision of passing strings as parameter was made to
facilitate the contributions in plugin.xml. It is not necessary to get
the data from the selection provider always. Your handler can get the
values from an ISourceProvider. Like I've done here
( http://blog.eclipse-tips.com/2009/02/commands-part-5-authent ication-in-rcp.html)

- Prakash

Platform UI Team, IBM
http://blog.eclipse-tips.com

Re: Command Parameters [message #490711 is a reply to message #490153]

Fri, 09 October 2009 15:00

Eclipse User

I guess the answer is "it depends" <- less helpful Smile

Really, it depends on the command. For most commands, it is reasonable for it to act on the current selection if that selection is a useful type. i.e. select a "Connection" object in your view and execute the "Connect" command. This is the main pattern facilitated by the JFace viewers and getSite().setSelectionProvider(*).

But there are other cases, where you want to execute a command on an object and specifically want to avoid posting it as the current selection.

Just w.r.t. design:

The parameters in commands are designed to "modify" the behaviour of that particular command execution. Like "move(direction=forward)" or "showView(viewId=outline.view.id)". But command parameters don't serve quite the same purpose as the parameters in a method call. But because the main situation they parameterize are menu items and keybindings, they are pretty static. They can be objects (there are parameter value converters) but they need to support serialization.

The way to pass object state (like a model object) to an executing handler is through the application context. If you are executing your command programmatically through the IHanderService you can update the IEvaluationContext that will be used in the ExecutionEvent and set your object to a known variable.

If you want the correct model object to be available to your command on its own timetable (database is connected, events have come in, connections made, etc) you can use an AbstractSourceProvider to make your model object available to the application context.

PW

Re: Command Parameters [message #491103 is a reply to message #490153]

Tue, 13 October 2009 05:41

Eclipse User

Excellent, thanks guys, most helpful, that gives me just what I need.

All the best,

Bob

Previous Topic:	Wizards
Next Topic:	Command at the wrong view active.

Goto Forum:

-=] Back to Top [=-

Current Time: Fri Jul 25 02:48:52 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter