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

[Stefan Xenos <Stefan_Xenos@xxxxxxxxxx>]

Sorry, everyone... I shouldn't have
gotten involved in a terminology debate.

The component framework is a solution
for creating executable extensions with dependancies. This is one requirement
for creating nested parts, not the whole story.

Since terminology debates (and the corresponding
rewriting of the proposal and code refactoring) is now taking up more time
than actual development work, I don't want to participate anymore. If someone
can think of a propsal that makes everyone happy and doesn't require me
to continue writing emails about terminology, I'll go with it. 

I do insist, however, that the same
word is not used within the framework to mean two different things at the
same time. 

Otherwise, I'll simply use the terminology
from www.picocontainer.org wherever they have a similar concept, no matter
how counterintuitive it may seem.

  - Stefan

Bob Foster <bob@xxxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx

11/10/2004 02:30 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 Xenos wrote:

> 
> There's two problems with this.
> 
> 1. The words "part" and "site" are currently associated
with UI 
> concepts, 

What UI concepts?
which would make the component framework seem to be tied to UI
> extensions. Although I'm not fond of the UI connotations, changing
> "container" to "site" could be done without conflict.
IContainer 
> replaces the IWorkbenchPartSite, and there is no difference between
an 
> IContainer that contains some UI and a any other container.
> 
> 2. In the case of renaming /component/ -> /part/  there would
be a 
> serious conflict. With the current terminology, a /part/ is a pluggable
> bit of UI, and /component /is an executable extension with dependencies
> and lifecycle. A view or editor is a part and a part is a component,
but 
> not all components are parts. For example, a default interface 
> implementation is a component but not a part. In fact, the objects
> created by any extension point that takes a "class" attribute
would be 
> components but would rarely be parts. Calling all components parts
would 
> leave us with no word to describe a pluggable bit of UI... and any
> existing documentation that says something like "PartStack contains
a 
> tabbed folder of parts" would leave people with the confusing
impression 
> that they could insert some arbitrary class that implements 
> IErrorContext that was created through an extension point.
> 
>   - Stefan
> 
> 
> 
> *John Arthorne/Ottawa/IBM@IBMCA*
> Sent by: platform-ui-dev-admin@xxxxxxxxxxx
> 
> 11/10/2004 10:25 AM
> 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
> 
> 
>                  
> 
> 
> 
> 
> 
> 
> I have to agree with Randy's comment that the proposed terminology
isn't 
> ideal.  "component" and "container" are two
heavily used words with lots 
> of existing meanings.  We have similar problems with words like
> "property" and "setting" - the definitions of
the words are just so 
> general that they can mean just about anything. There are bound to
be 
> vocabulary "collisions" with uses of those words in other
components 
> (IContainer for example is already used in platform core). I think
> Randy's suggestion of reusing the existing words "part"
and "site" would 
> be better. These words are already well known to have that particular
> meaning, so throwing away those words in favour of new ones just creates
> confusion and requires the poor plug-in writers to learn yet another
new 
> term for an existing concept.


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