Re: [e4-dev] Having multiple IContextFunction

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

Am 20.05.10 17:47, schrieb Oleg Besedin:
> 
> Hi Tom,
> This is the expected behavior. Having multiple services can be a valid
> scenario. For example, imagine that we ship e4 SDK with a "generic"
> implementation of a, say, weather service. A developer downloads the SDK
> and says, "hey, this weather service... hmm... does not provide
> long-term forecasts within expected tolerances". With multiple services
> allowed, in theory, the developer then can make his own weather service
> and register it with OSGi with a higher ranking.
> 

So you say in principle it makes sense but ...

> (Unfortunately iterating services to find the "best" answer won't work
> as at the dependency injector level we don't know what "best" means;
> "null" can be a valid answer too.)

Well to some extend DI knows it because if it:
a) Knows that there are multiple IContextFunctions
b) It knows that the Component requires a none NULL-Value (because it
   is marked not as optional)

If DI detects such a situation it could try harder to find a none NULL
value the worst thing that can happen is that it finds out the value is
NULL in all cases and failing like it does currently.

So probably we should ask the question in a different way:

At which point is NULL a valid value from the IContextFunction in
conjunction with an *none* optional DI-Value?

> 
> This is simplicity vs. extensibility in action :-). I am not claiming
> that we have found the best balance, so if the reasons above don't sound
> convincing please open a bug/enhancement request and we'll follow up there.
> 

I understand that and at the moment this is not a real requirement for
me but think about the following scenario:

===============================================================

Say I have a Component:
-------------8<-------------
public class Editor {
  @Inject
  public Editor(IEditorInput input) {
  }
}
-------------8<-------------

Now I have an IContextFunction which works with an MInput and constructs
an IEditorInput from it when the URI in MInput can be accessed through
the EFS (e.g. myproject/test.html).

-------------8<-------------
public class FileInputFunction {
  public Object compute(IEclipseContext context) {
     final MInputPart inputPart = context.get(MInputPart.class);
     String uri = inputPart.getInputURI();
     // Check if uri is able to be reflected as IFile
     // else return null
  }
}
-------------8<-------------

Now the editor itself doesn't really care about if the file can be
represented as a IFile but uses the IEditorInput to interface with it.

So now some other developer wants to use the editor but the resource
constructing the IEditorInput can't be represented as an file (e.g. the
URI is http://www.bla.com/test.html).

Now all he has to do is to provide an IContextFunction which knows how
to represent this as an IEditorInput and magically now the Editor works
with a completely different type of source.

===============================================================

I don't really need this at moment (if I'm in need what I'll probably do
is to define a service which allows to contribute to the
FileInputFunction).

The only thing I'd like to see is that some warning is logged at the
moment DI detects that there are more than one IContextFunction
registered for one key (I guess the average developer who doesn't has
any knowledge about DI and all this stuff would never have found out why
something stopped working :-)

Tom


-- 
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                                        geschaeftsfuehrer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5/1    A-6020 innsbruck      phone    ++43 512 935834