[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Commands / Handers + Contexts vs API
|
> command bus
Yes, you've got the gist of the idea.
-Dave Orme
On Jan 20, 2009 9:21 AM, "Eric Moffatt" <emoffatt@xxxxxxxxxx> wrote:
+1 for having Commands/Handlers for
non-UI consumption. It might also be worth using them as a way to manage
'API' in a more fine-grained manner...
There are a number of API methods that
'do' things (as opposed to simply retruning info) and many could be coded
to run without requireing a UI being present. Now that we have a clean
'Context' story Handlers could become the standard way that we package
all 'atomic' operations (including but not constrained to the GUI-related
ones). This is, I believe, what Dave Orme calls the "Command Bus",
Dave, am I close ?
For example we already have a 'Show
View' command but it currently defers its actual implementation to the
currently active Perspective via the WorkbenchPage. This could be refactored
so that the implementation was actually contained in the Handler and the
API methods would invoke the handler directly (after tweaking the parameters/Context
as necessary). This would effectively flatten the API, rather than having
a variety of methods strewn over various interfaces (and causing API compatibility
issues) it places all of the available operations into a single 'Handlers'
area, allowing the same code pattern (fill the Context, execute the Handler)
to be used in place of the current API mechanisms.
Then we could do the converse; place
all the values that we currently use API to 'query' into the appropriate
Context and have the current API just return the value. We'd then have
a situation where functionality is independent of API altogether; everything
that can be 'done' can be done through executing the appropriate Handler
+ Context pair and everything that can be 'queried' is available through
the appropriate Context. Our current API then becomes syntactic sugar,
packaging some particularly useful pattern of query/execution. Commands
then become the glue necessary to bind a Handler into the Menu/ToolBar/Key
binding UI...
Comments?
Eric
Hi Martin,
> I'm wondering why handlers and operation support are considered a
UI
> concept.
They're in the UI section right now simply because I'm working on them
:-)
> I know that they are today, but does it have to be that way?
> Wouldn't it make sense to allow command handlers be contributed without
UI
> dependency?
> That might eventually help producing headless applications that can
be
> scripted through commands.
I think that's correct, and we'll employ a similar direction that was
used in org.eclipse.core.commands. I think
org.eclipse.e4.core.services should provide all of the interfaces and
infrastructure necessary to execute commands.
When we'll have to give it a lot more thought is the point where it's
time to start gluing things together. For example, the suggested
HandlerService works with the Contexts and model, specifically
Application and Part<?>. Will we have to move some of the structural
workbench model into a ...core.model.application and then put other
bits in ...ui.model.workbench?
We'll have to keep asking ourselves these questions.
--
Paul Webster
Hi floor. Make me a sammich! - GIR
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
