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

[Randy Hudson <hudsonr@xxxxxxxxxx>]

What are the non-UI use cases/requirements
anyway?  The driving factor here is composing UIs.  Let's just
broaden the existing definitions instead of using new terms since 98% of
the use cases are going to be "parts" and "partsites".

Stefan Xenos <Stefan_Xenos@xxxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx

11/10/2004 01:40 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

There's two problems with this. 

1. The words "part" and "site" are currently associated
with 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.