[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[udig-devel] Re: fun on trunk: socket plugin does what? and draw2drenderer update
|
I also thought about using the handler. It is not bad but it has no
"can handle" method. So you basically have to try it and check if it
handled the message... I guess that is ok. I can move the iteration
through all handlers into the SafeRunnable and keep trying until I get
one.
The problem now is that IHandlers have state (listeners at minimum)
and some subclasses actually make it explicit and therefore is not
good for multi-threaded programming. We would be tempting
implementers to create stateful Handlers which is a terrible idea for
this application. Also as a parameter you get a ExecutionEvent as the
parameter which has a Map as the parameters so the developer cannot
use code completion easily to see what the parameter will be.
None of these issues kill the idea it just is not a nice API to learn.
Addressing the point we are making developers learn 2 APIs. That is
absolutely true... However the counter argument to that is that they
may not need to learn commands for a long long time. I still haven't
for example and commands have been around as long as I have (4 years
now). So having to learn commands is not a forgone conclusion.
Jesse
On 11-Aug-08, at 9:50 AM, Jody Garnett wrote:
Jesse Eichar wrote:
Good grief. And this doesn't do anything because you still need
the handler in order to make the command do anything.
I am not sure I am talking about the same thing as you? I was just
looking mostly at the extension points and noticed that "new
commands" can take parameters etc...
Command showView =
commandService.getCommand("org.eclipse.ui.views.showView");
IParameter viewIdParm =
showView.getParameter("org.eclipse.ui.views.showView.viewId");
Parameterization parm = new Parameterization(viewIdParm,
"net.refractions.udig.catalog.ui.catalogView");
ParameterizedCommand parmCommand = new
ParameterizedCommand( showView, new Parameterization[] { parm });
handlerService.executeCommand(parmCommand, null);
That said I have not worked with API yet so it may be a pain to set
up? The examples in the eclipse wiki do not seem so bad - it looks
to me like we need to go this way anyways to advertise functionality
to RCP programmers?
You have the experience here - a handler is still needed over and
above a command - can we cut to the chase and dispatch these
incoming requests to the same handlers the command framework targets?
I agree that commands could be used for this and it would have the
benefits of being able to do just about anything. But that is also
the problem. I have defined a very small API that makes it very
easy to add new protocols.
I personally think using commands is too heavy weight and is a very
large barrier to entry when considering using the API.
Conversly if we roll our own we need to document - and people need
to learn two things rather than just one.
I'm willing to be shown wrong since I like being able to reuse API.
Jesse
Have a look at the above code example; and see if it could be used -
right now I am looking at the Command stuff and liking it over the
IProcess api we just made up for GeoTools and the WPS client.
Jody
