[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] A missing framework piece: contexts?
|
Hi,
In ORM mappers (e.g. Hibernate) the bag concept is very well know
because when you model something as an List you must ensure at the
database level that the order is consistent (e.g. by adding a sorter
column) and cause a lot of overhead when you e.g. insert a value at the
beginning of a list.
Tom
Chris Recoskie schrieb:
> Actually the bag concept is general to computer science, and at least
> used to be covered in computer science courses back in my day. You can
> put things in the bag, but when you pull something out of the bag you
> don't know what you're going to get out in what order.
>
> Of course bags didn't get a lot of air time, because lists, sets,
> stacks, and queues were all sexier.
>
> You wizened old Smalltalk dudes don't get to claim ownership over
> everything ya know ;-)
>
> ===========================
> Chris Recoskie
> Team Lead, IBM CDT and RDT
> IBM Toronto
> Inactive hide details for John Arthorne/Ottawa/IBM@IBMCAJohn
> Arthorne/Ottawa/IBM@IBMCA
>
>
> *John Arthorne/Ottawa/IBM@IBMCA*
> Sent by: e4-dev-bounces@xxxxxxxxxxx
>
> 01/08/2009 09:58 AM
> Please respond to
> E4 Project developer mailing list
> <e4-dev@xxxxxxxxxxx>
>
>
>
> To
>
> E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
>
> cc
>
>
> Subject
>
> Re: [e4-dev] A missing framework piece: contexts?
>
>
>
>
>
> "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.
>
>
>
> *Ed Merks <ed.merks@xxxxxxxxx>*
> Sent by: e4-dev-bounces@xxxxxxxxxxx
>
> 01/07/2009 04:41 PM
>
> Please respond to
> E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
>
>
> To
> E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
> cc
>
> Subject
> Re: [e4-dev] A missing framework piece: contexts?
>
>
>
>
>
>
>
> 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@eclipse.org_ <mailto: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
--
B e s t S o l u t i o n . a t EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl leiter softwareentwicklung/CSO
------------------------------------------------------------------------
eduard-bodem-gasse 8/3 A-6020 innsbruck phone ++43 512 935834
