Re: [platform-ui-dev] Component framework proposal version 1.0.4 availab

[Stefan Xenos <Stefan_Xenos@xxxxxxxxxx>]

You're right: it would be much easier
to follow the abstractions if I'd started with a concrete case.

I'll focus on getting the workbench
interfaces working and provide some examples nested views/editors before
I make the framework generally available.

  - Stefan

Dirk Baeumer <dirk_baeumer@xxxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx

11/08/2004 01:33 PM

Please respond to
platform-ui-dev

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

Stefan,

here is Andre's and my feedback to the Component Framework Proposal (the
old one. We haven't found
the time yet to read the updated ;-))

>> Robustness / leak proofing

+1 for the idea of accessing the world through a set of local services
and
having explicit
interfaces for the communication between parts and containers

>> Component Framework

We had a hard time of getting a clear architectural picture behind all
those indirections :-)

Wouldn't it be better for this kind of proposal to move from a specific
solution to a generic
one instead of starting with the fully generic solution.

From our understanding there are two problems we want to solve:

- embedding of parts in dialogs
- embedding of parts in parts.

So instead of having a generic component framework you could provide a
set
of interfaces and
local services and show

- how a view part would use these local services and
- how a part container would implement and manage these services.

We haven't look into this in detail but something along the lines of an
IPartContainer interface
and an abstract class part where the management of the local services is
done by the abstract
part class.


Andre & Dirk




                    
                     
                     
          
             Dirk        
                     
                     
     
             Baeumer/Zurich/IB    
                     
                  
             M        
                     
                     
     To 
                    
                  Andre Weinand/Zurich/IBM@IBMCH
     
             08.11.2004 12:30    
                     
                cc 
                    
                     
                     
          
                    
                     
                     
  Subject 
                    
                  Component
framework proposal        
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          



Stefan,

enclosed Andre's and my feedback to the Component Framewrok Proposal.

>> Robustness / leak proofing

+1 for the idea of accessing the world thorugh a set of local services
and
having explicit
interfaces for the communication between parts and containers

>> Component Framwork

We would prefer a path were we move from a specific solution to a generic
one instead of starting
with the fully generic solution. From our understanding there are two
problems we want to solve:

- embedding of parts in dialogs
- embedding of parts in parts.

So instead of having a generic component framework we would provide a set
of interfaces and
services and a view part is still resposible to manage these local
services. We haven't look into
this in detail but something along the lines of an IPartContainer interface
and an abstract class part
where the management of the local services is done by the abstract part
class.





                    
                     
                     
          
             Stefan Xenos      
                     
                     
             <Stefan_Xenos@ca.  
                     
                    
             ibm.com>      
                     
                     
To 
             Sent by:      
           platform-ui-dev@xxxxxxxxxxx  
      
             platform-ui-dev-a    
                     
               cc 
             dmin@xxxxxxxxxxx    
                     
                   
                    
                     
                     
  Subject 
                    
                  [platform-ui-dev]
Component         
             11/06/2004 02:31    
     framework proposal version 1.0.4    
             AM        
               available  
                     
  
                    
                     
                     
          
                    
                     
                     
          
             Please respond to    
                     
                  
             platform-ui-dev@e    
                     
                  
                clipse.org  
                     
                     
  
                    
                     
                     
          
                    
                     
                     
          





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:                  
                     
                     
To 
 platform-ui-dev-admin@eclipse.o           platform-ui-dev@xxxxxxxxxxx
    
 rg                    
                     
                     
    cc 
                    
                     
                     
          
                    
                     
                     
  Subject 
 11/05/2004 03:04 PM                
      Re: [platform-ui-dev] Component 
                    
                     
framework proposal              
                    
                     
                     
          
        Please respond to        
                     
                   
         platform-ui-dev        
                     
                    
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          






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@eclipse.            
                     
         
 org                    
                     
                     
   To 
                    
                     platform-ui-dev@xxxxxxxxxxx
     
                    
                     
                     
       cc 
 03/11/2004 08:43 PM                
                     
                
                    
                     
                     
  Subject 
                    
                     Re:
[platform-ui-dev] Component  
        Please respond to        
        framework proposal        
      
         platform-ui-dev        
                     
                    
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          







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@eclipse.            
                     
         
 org                    
                     
                     
   To 
                    
                     platform-ui-dev@xxxxxxxxxxx
     
                    
                     
                     
       cc 
 11/03/2004 05:10 PM                
                     
                
                    
                     
                     
  Subject 
                    
                     Re:
[platform-ui-dev] Component  
        Please respond to        
        framework proposal        
      
         platform-ui-dev        
                     
                    
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          








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@eclipse.            
                     
         
 org                    
                     
                     
   To 
                    
                     platform-ui-dev@xxxxxxxxxxx
     
                    
                     
                     
       cc 
 11/03/2004 02:34 PM                
                     
                
                    
                     
                     
  Subject 
                    
                     Re:
[platform-ui-dev] Component  
        Please respond to        
        framework proposal        
      
         platform-ui-dev        
                     
                    
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          








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@eclipse.            
                     
         
 org                    
                     
                     
   To 
                    
                     platform-ui-dev@xxxxxxxxxxx
     
                    
                     
                     
       cc 
 11/03/2004 09:34 AM                
                     
                
                    
                     
                     
  Subject 
                    
                     Re:
[platform-ui-dev] Component  
        Please respond to        
        framework proposal        
      
         platform-ui-dev        
                     
                    
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          








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


_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev