Jeff,
Oddly enough, it sounds almost exactly like EObject, only we call them
features rather than properties. And strangely coincidental to your
preference reference, someone was just recently asking how best to use
EMF to better support preferences:
http://www.eclipse.org/newsportal/article.php?id=38544&group=eclipse.tools.emf#38544
It's a small world. Go figure! :-P
Cheers,
Ed
Jeff McAffer wrote:
My heart has been warmed on this cold winter day by the mere mention of
Smalltalk...
That aside, this datastructure here sounds like Properties with
notification. That in turn sounds like our preference mechanism. funny
that.
Jeff
John Arthorne wrote:
"Bag" is just a Smalltalk
term for an unordered collection. Essentially a context is just a map,
with extra logic for tracking dynamic changes, injection, and a notion
of a parent context. If the most local context can't supply a value, it
delegates to the parent. As Kevin suggested this allows modeling of
things
like the widget hierarchy where a tab in a view might be one context,
the
view itself another context, another context for the window, etc, up to
a global application context. You're right that the injection logic can
(and probably should) be separated from the context logic since it's
unlikely
to change.
Oleg,
Comments below.
Oleg Besedin wrote:
“Progress is made by lazy men looking for easier ways to do things”.
I'm exceedingly lazy...
I think this is exactly how the concept of contexts came to life. Our
code
runs in some environment; way too often we need to pass tens of
arguments
from method to method and from class to class just to keep them aware
of
the environment.
To make it easier we are considering adding a concept of "context".
At the conceptual level a "context" is a combination of:
- a bag that could be stuffed with elements that compose environment,
and
Couldn't we just use Map<String, Object>?
What's
the significance of the term "bag"?
- a mechanism to inject elements
from
the bag into your POJO objects
Such a mechanism could be independent of how the
"bag"
itself is implemented.
The contexts are organized in a hierarchy. Child context can add
service
objects that make sense at their level:
IEquinoxContext myContext = ApplicationContext.newChild();
Will we expect people to create context with
specialized
behavior? Which parts will be specialized and why?
myContext.addObject("log",
myLog);
The service objects from the context can be injected into POJO objects
using field and method injection:
myContext.injectInto(object)
resulting in the field object.equinoxLog being set to "myLog".
I could imagine a static
Injector.inject(Map<String,
Object> values, Object target) utility doing all this type of work
with
no additional interfaces or implementations of those interfaces. Of
course then there's be only one implementation of this, which
conceptually
seems less flexible, but that's the question earlier. What parts
of which mechanisms would clients be trying to specialize?
Contexts support dynamic events and multiple service objects per ID.
What are those? :-P
In addition, contexts can be tied
into
creation of objects from the extension registry and help access OSGi
services.
I think I'm missing a lot of the picture even
looking
in the bugzilla. It sounds interesting though...
I'd like to raise this subject at the E4 call to see what people think
about it. The details of this work can be found in the enhancement
request
259423:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=259423
Sincerely,
Oleg Besedin
_______________________________________________
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
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
|