Hi Tom, et al.,
Tom Morris wrote:
... the idiom
ProjectManager.getManager().getCurrentProject().getActiveDiagram().
Yes, it is bad.
Since we usually want the Diagram associated with the active window
and we can use GEF to follow
Globals.curEditor().getLayerManager().getActiveLayer().getDiagram() to
get this we can break the dependency on the ProjectManager.
So, the ArgoUML application has a singleton ("Globals") that keeps track
of the current editor and hence the current diagram. Hmmm... We can as
well ask the current diagram what the current project is then...
Before I
deprecate Project.getActiveDiagram() entirely though, I want to make
sure that no one has a need for it. Say we've got projects A, B, and
C open with windows for diagrams A1, B3, and B4. If diagram A1 is
active, do we ever need to know that B3 was the last diagram in
project B that was touched? I don't think so and I'd like to get rid
of Project.getActiveDiagram so people aren't tempted to use it.
Anyone have a good reason to keep it?
One reason may be when you close the application (I.E. all projects at
once) and select "save all". Then we would need to know the last
selected diagram per project. BTW: We now do save the last selected
diagram. Project B will need to be saved with diagram B3 selected.
And:
Suppose we have a multi-user & multi-project version of ArgoUML, so that
one user is working on the current diagram in project A, and the other
user is working on the current diagram of project B - so we may need a
current diagram per project per user.
We may need to keep the Project.getActiveDiagram(), but should get rid
of ProjectManager.getManager().getCurrentProject() . Should we not
deprecate this now?
The idiom Globals.curEditor().getLayerManager().getActiveLayer() is not
so bad, since the curEditor() represents the application or user sitting
behind his computer.
On a related note, the constructors for four FigEdges are using this
idiom to set their owning GEF Layer which seems hugely backwards to
me. Anyone know why this is being done in the constructor instead of
by the PGML parser? (The comments seem to imply that it's only
required because of some special condition during load). The four
Figs are FigAssociation, FigAssociationEnd, FigDependency, and
FigGeneralization.
See issue 3494 - unfinished because of architecture uncertainty.
BTW, if you ever find yourself tempted to type
ProjectManager.getManager().getCurrentProject(), please don't! You
should be able to figure out the right project from some other piece
of context that you have.
Fully agreed!
In general, I think we need more ownership, and less dependency on a
singleton that keeps track on a "current" something.
Michiel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
