Dennis,
Now, I get your point.
The question is if we really have to add additional functionality
to PCV (or CCV)? We can take a different approach if the reason for doing it,
is that we’d like to give community opportunity to define their own
“open” functionality like, open specific view for their implementation
(other than CCV) or use their own open CC method (like openForTeamMember in
ProjectContainer).
I would suggest using Eclipse
actions for adding functionality to CCX, and make them responsible for opening
correct view and using correct open CC method (more less as it’s done
now). Actions have this nice override feature, which allows plugins to override
other actions.
Here is how I see it:
We can split current UI
plugin for two separate plugins, generic ContextContainer UI, and exemplary
implementation for ProjectContainer UI.
The generic Context
Container UI, would have:
·
“Context
Container Explorer” view (which is able to display any ContextContainer
objects) with following actions.
o
“Open”
action; that Opens CCV and uses ContextContainerProxy.open() method, for
opening the CC.
o
“Close”
action; which closes CCV
o
“Show
view” action; which displays proper CCV;
The specific Project
Container UI implementation, could than:
o
Override
standard CCX “Open” action (ONLY for ProjectContainer objects);
which could open CCV but could use ProjectContainer specific openForTeamMember
method.
If some other specific
container UI implementation would like to use other view than CCV, it would
have to override all of the standard actions, and write them by they own.
So the idea of actions is more less the same to the approach you’ve shown
in the diagram, the difference is that, it is eclipse action engine which is
looking for proper action for the container and it is the action which is doing
all the job with opening container.
Cheers,
Piotr
Ps. I’ve made some tests with
actions overriding, and it’s really flexible.
From:
corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of O'Flynn, Dennis
Sent: Tuesday, March 13, 2007 2:26
PM
To: Corona
development
Subject: RE: [corona-dev] FW: CCX
and PCV (or CCV)
Piotr,
The following (draft) sequence diagram is
what I had in mind.
- The
major difference is that the “viewer” (i.e. PCV) is now
responsible for actually opening the correct type of container. In
this scenario, it will invoke the ProjectContainerManagerProxy to open a
PC on behalf of the user.
- This
is just a draft sequence diagram to illustrate the concept. Actual
method names may be different.
From: corona-dev-bounces@xxxxxxxxxxx
[mailto:corona-dev-bounces@xxxxxxxxxxx] On
Behalf Of Jaworowski, Piotr
Sent: Tuesday, March 13, 2007 6:58
AM
To: Corona
development
Subject: RE: [corona-dev] FW: CCX
and PCV (or CCV)
Dennis,
To sum up; please read comments below.
Cheers,
Piotr
From:
corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of O'Flynn, Dennis
Sent: Monday, March 12, 2007 8:28
PM
To: Corona
development
Subject: [corona-dev] FW: CCX and
PCV (or CCV)
Piotr,
The following is about bugz item 173623
The objective of was to provide an “explorer” view that
would show all of the defined ContextContainers, regardless of their type.
This would allow the “SystemContainer”,
“ProjectContainers”, as well as any other container type to be
listed in the same “explorer” view.
[Jaworowski, Piotr]
Explorer is now capable of displaying any kind of ContextContainer element; (so
this item is met.)
When the user selects a ContextContainer to be opened, the
“explorer” needs to launch the appropriate “viewer”.
For our exemplary implementation of a “ProjectContainer”, this
would be our current “ProjectContainerViewer” (PCV).
The specific “viewer” to be launched will be defined by using
a new extension point (org.eclipse.corona.viewer?), similar to how the current
PCV finds the specific PCV-page to use for a REPOSITORY-DESCRIPTOR.
The goal of this enhancement is to allow any collaboration solution to easily
register the specific “viewer” for its type of ContextContainer
through the use of an extension point. The “explorer” is used
to match the ContextContainer type to the specific “viewer”.
[Jaworowski, Piotr]
As I understand, you'd like to have a *generic* "open context
container" action which will be capable of opening any kind of context
container and displaying proper "view" for it; Right this is not
done;
Current implementation of open container action
(OpenPCXActionDelegate) is capable of opening the ProjectContextContainer
object ONLY. This action is using ProjectContainer specific open method
(openProjectContainerForMember) which is not available for other
ContextContainers. Moreover, all actions now are using ProjectContainerProxy
class to “communicate” with server; ProjectContainerProxy (as the
name says ;-)) is ProjectContextContainer specific. Please note that this proxy
class implements “generic” ContextContainerProxy class which is
empty (there is also ContextContainerManagerProxy class which is not used at
all, I guess we’ve got some mess there).
So actually to achieve such generic result
of opening ContextContainers (and for some other generic actions), we need to
have some refactoring and source clean up.
Below is the class diagram how we could
implement it, (current implementation does not fit it, at least on client side,
as all methods (even generic one) are implemented in ProjectContainerProxy
class)
Two additional things:
1) IMHO
ContextContainerManagerProxy and ProjectContainerManagerProxy are better names
for proxy classes on client side.
2) We should think of fixing up
some classes names, like ProjectContextContainer and ProjectContainerManager (we should go in one
direction; either ProjectContextContainer and ProjectContextContainerManager or
ProjectContainer and ProjectContainerManager)
The contents of this e-mail are intended for the named addressee only. It contains
information that may be confidential. Unless you are the named addressee or an
authorized designee, you may not copy or use it, or disclose it to anyone else.
If you received it in error please notify us immediately and then destroy it.
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it.