[platform-ui-dev] Component framework proposal version 1.0.4 available

[Stefan Xenos <Stefan_Xenos@xxxxxxxxxx>]

I've updated the proposal to reflect
the latest feedback. In particular:

- Use of the word "service"
has been removed. The things that a component takes in its constructor
are now simply "interfaces", and the concrete classes registered
via the extension point are referred to as the "default implementation
of the interface". This is somewhat more wordy but it removes the
conflict with OSGi and more accurately describes their function. Terminology
still isn't as consistent as it should be.

- Added a lengthy introduction that
tries to describe the problems involved in making a view site more extensible
and allowing it to be instantiated by clients.

- Changed the rules for resolving dependencies.
Services may only be declared for interfaces in the same plugin, and only
one default implementation is permitted per interface. This addresses McQ's
concerns about the complexity of resolving which implementation to use
(there is now only one possible implementation). A side benefit is the
fact that circular dependencies can now only occur between components in
the same plugin, making this type of error much easier to debug.

- Added a scoping system, which addresses
Michael's concern: "What am I allowed to take in my constructor?".
The scoping system adds some invariants which make it easy to scan the
plugin registry to find all interfaces that could be requested or implemented
by a particular type of component. It would now be quite easy to write
a PDE extension that displays this information on demand... or to automatically
generate a web page for each type of component that lists all the interfaces
in the Eclipse SDK that it is allowed to use (ie: one page for views, one
page for editors, and one page for parts that want to work in both contexts).

- Some initial work on how the component
framework will be used within the workbench... but there are still a lot
of interfaces missing.

If I get a chance to work on this over
the weekend, I'll try to attach my proof-of-concept implementation somewhere
so that interested parties can start prodding it. 

  - Stefan

Michael Valenta/Ottawa/IBM@IBMCA
Sent by: platform-ui-dev-admin@xxxxxxxxxxx

11/05/2004 03:04 PM

Please respond to
platform-ui-dev

To	platform-ui-dev@xxxxxxxxxxx
cc
Subject	Re: [platform-ui-dev] Component framework proposal

Stefan, 

In section 2.1, you mention an IComponent when describing adaptablity.
Did you mean IContainer? I think you did because later in the doc you mention
IComponent.dispose(). I suspect that was your original name for the interface.

I don't know if I buy into the need for such a generic framework. I understand
that it is compelling in the sense that you can plug anything into anything
else but in reality, is this really true? If it is not, how does the developer
know what components can be used when. For instance, If I am implementing
a view, how do I know what are valid objects that I may receive in my constructor?
If I have a view that requires a particular service, how do I communicate
that to the parent container to which the view is being added?

Another way to look at it is that Java provides a means for determining
the requirements for creating and using objects by assigning types to objects.
If you are going to bypass this mechanism, you will need some other mechanism
to communicate the API of containers and components so that developers
will know how to hook things together. Minimally, this would need to be
some parsable description of the interrelationships of containers used
in particular contexts. Ideally, this would be supported by tooling. Without
either of these, I fear that Java developers trying to create and use components
would have a hard time figuring out what to do. 

Michael

Stefan Xenos/Ottawa/IBM@IBMCA
Sent by: platform-ui-dev-admin@xxxxxxxxxxx

03/11/2004 08:43 PM

Please respond to
platform-ui-dev

To	platform-ui-dev@xxxxxxxxxxx
cc
Subject	Re: [platform-ui-dev] Component framework proposal

The analogy to view IDs works. There must be a unique class that implements
a service interface just like there must be a unique class that implements
a view. However, you can still have many instances of that service just
like you can have many instances of a view. 

The terminology conflict with OSGi is unfortunate. I've been thinking of
eliminating the word "service" in favor of the word "component",
but even that is a minor conflict. I'm open to suggestions.

AFAIK, OSGi seems intended for a different purpose than the component framework.
The component framework is intended for creating trees of pluggable components
where each node provides some context for its children. OSGi seems intended
for creating applications where functionality can be added or removed on
the fly. In the case of the component framework, a service is a default
implementation of an interface that gets used for components that don't
explicitly implement it. In the case of OSGi, a service is a dynamic bit
of application funcationality. 

Except in the case where components are used as singletons, there is not
a lot of duplication. There would be benefits in exposing OSGi services
to these proposed components.... for example, if it were possible to make
the OSGi BundleContext or ComponentContext to the constructor of a component,
then views and editors could have convenient access to OSGi services.

I haven't seen any code or JavaDoc for the declarative service specification,
but the high-level proposal I read did not seem to lift the OSGi restriction
of one-instance-of-a-service-per-Bundle. 

 - Stefan

Jeff McAffer/Ottawa/IBM@IBMCA
Sent by: platform-ui-dev-admin@xxxxxxxxxxx

11/03/2004 05:10 PM

Please respond to
platform-ui-dev

To	platform-ui-dev@xxxxxxxxxxx
cc
Subject	Re: [platform-ui-dev] Component framework proposal

Some thoughts 

- use of "service" will be confusing now that Eclipse is based
on OSGi which contains a strong notion of service. (that is the 'S' in
OSGi!) 

- is there any value in a relationship between OSGi services and these
services?  In particular, the declarative services work. 

- you mention that there should only be one implementation per interface
and draw an analog with view ids.  But in 3.0 don't we allow multiple
view instances?  In any event, my gut tells me that this will be a
problem. 

- more later 

Jeff

Stefan Xenos/Ottawa/IBM@IBMCA
Sent by: platform-ui-dev-admin@xxxxxxxxxxx

11/03/2004 02:34 PM

Please respond to
platform-ui-dev

To	platform-ui-dev@xxxxxxxxxxx
cc
Subject	Re: [platform-ui-dev] Component framework proposal

Mike, 

Thanks for taking the time to look at this. Yikes: I can't believe so many
typos slipped through! 

I'd like to respond to a few comments here, though:



1. Selecting the "right" IErrorContext. There would only ever
be one "right" instance of IErrorContext -- that would be the
ErrorContext instance created specifically for the view that is associated
with that view's plugin bundle. However, you are correct in that there
could possibly be more than one implementation of IErrorContext. As the
spec stands now, there is the possibility for more than one global service
to exist on the same interface. 

Currently, the "first" implementation is selected in plugin activation
order, but this could be considered a programming error and could be enforced
more rigidly. Really, a service interface is intended as a unique identifier
for the service and declaring two services on the same interface should
be an error (much like creating two views with the same ID). Unless anyone
has a better suggestion, I will add the one-implementation-per-interface
rule to the spec. 

I suppose it would be possible to add "scopes" for services.
The XML markup could specify whether the service is intended for global
use, one particular extension point, parent-to-child communication, child-to-parent
communication, etc... but I wasn't sure if this was any better than JavaDoc
on the service interface. 


2. You mention that a view might not be able to function in the context
of a Composite + IWorkbenchPage. Doing crazy stuff like creating views
inside dialogs is one of the motivations for this code change, so I'm rather
hoping that it will be possible in all cases... but obviously I
haven't written all the code yet. If you are aware of another dependency
I haven't encountered yet, we should chat. 


3. I think I should rewrite the "optional interfaces" section
to make the alternatives more obvious. Instead of having the component
ask "does this service exist", the service provider can simply
provide an empty implementation of the service that exists in all contexts.
In both cases the component is just as reusable but in the latter case
the special-case code is written once inside the service implementation
rather than many times inside of each component that uses it. 


- Stefan

Mike Wilson/Ottawa/IBM@IBMCA
Sent by: platform-ui-dev-admin@xxxxxxxxxxx

11/03/2004 09:34 AM

Please respond to
platform-ui-dev

To	platform-ui-dev@xxxxxxxxxxx
cc
Subject	Re: [platform-ui-dev] Component framework proposal

See markup in red. Come chat if anything isn't clear.



McQ.




Stefan Xenos/Ottawa/IBM@IBMCA 
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
11/02/04 18:03
Please respond to
platform-ui-dev


To
platform-ui-dev@xxxxxxxxxxx
cc

Subject
[platform-ui-dev] Component framework proposal







The component framework proposal is now available online. 

This is part of the spec for the workbench part API in Eclipse 3.1, 
intended to support easier nesting and reuse of UI components. 

http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/components-proposal/ComponentFrameworkProposal.html


- Stefan