[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Commands / Handers + Contexts vs API
|
It seems we're on to something here (not exactly sure what it is yet) but just to be clear, we are not talking about a command bus of which there could ever be only one, right?
Boris "Anti-Singleton" Bokowski
![Inactive hide details for David Orme <djo@xxxxxxxxxxxxxxxxxxxxxxxxx>]()
David Orme <djo@xxxxxxxxxxxxxxxxxxxxxxxxx>
David Orme <djo@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sent by: e4-dev-bounces@xxxxxxxxxxx
01/20/2009 07:15 PM
Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx> |
|
|
> 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
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
