Oleg Besedin wrote:
=> Single context object <=
> I don't like that clients cannot provide more
than just one single
> "context" object.
Good point. I did this for simplicity as having
only
one argument eliminates the need to match constructor arguments. If we
were to support multiple arguments we'd have to add a new construct to
the extension point schema - something like
<constructor>
<argument position
= "1" name = "name_of the_attribute_from_plugin_xml"/>
<argument position
= "2" name = "name_of the_attribute_from_plugin_xml"/>
...
</constructor>
This is probably worth supporting as an option.
I didn't follow the context object discussion it seems like this is a
better way to do the initData stuff. correct? That is cool. I wonder
as well if dynamic context is on the table? That is supplying objects
in the call the createExecutableExtension call.
=> Annotations and VM support <=
Annotations would be really nice to use. As an
example
take be the topic above ("single context object"): annotations
could have been used to tie constructor arguments to the XML
attributes.
However, Eclipse SDK runs on 1.4 and the position
of the extension registry in the Eclipse stack does not give us much
freedom.
We'll have to support pre-1.5 VMs at least in the 3.x stream, there is
no choice. As such any functionality based on annotations would have to
be optional.
Is there [easy] some way we can support annotations if they are there
(and we are on an appropriate VM) but otherwise allow people to work
without htem?
- the extension registry: while it
might not look
like a conventional DI framework, in spirit it is very similar. The
functionality
gets obscured by registry artifacts as pieces that gets injected are
IConfigurationElements
/ IExtensions. With this enhancement the actual Java typed objects will
be injected using method/field injection; and an optional "context"
elements will be injected via constructors.
I entered a bug today to talk about linking the extension lifecycle
with that of services (DS) and more of the bundle lifecycle. This
would go a long way IMHO towards making extensions and services
intereact better. That and making it easeier to lookup and inject
services into createExecutableExtension and to contribute extensions
that are in fact services (e.g., make it easy to use an
IExecutableExtensionFactory)
Jeff
|
