Hi Bob,
The content of the above mentioned function should be a case statement
that
determines if the given object is e.g. a Fig, or a UML element, or
something
else.
That has a bad smell to me. At the very least we'd be introducing
something there that we don't know what we need now.
You are right.
If it wasn't for that then the solution would be to overload method
names to take different types or to make classes that we want to test
for editable by having them implement some interface that defines
isEditable()
The latter I think would be better as I'd like to reduce knowledge of
Fig through ArgoUML (with eclipse GEF/GMF in mind)
Why would we not want Fig.isEditable()?
OK. But how does a Fig know if it is editable or not?
It will need to ask the Project's permission (i.e. if the loaded file was
read-only or not). The knowledge about read-only files resides in the
Project. It becomes abstract for the Fig.
Anyhow, what you propose is indeed a better architecture.
BTW: As long as we do not support opening read-only projects, Figs will
always be editable, even the ones representing uneditable profile elements.
In this case you can e.g. resize a class, but not add a attribute to it.
BTW2: Figs do already have a "_locked" attribute, and FigNodeModelElements
have an "editable" attribute.
Regards,
Michiel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
