RE: [argouml-dev] Problem with the persistence/load of diagrams.

Well said!

I had started a mail to say part of this but I was not this clear in the
problem analysis.

Isn't there a design rule forbidding reflection already? Shall we add
one?

        /Linus

> -----Original Message-----
> From: Tom Morris [mailto:tfmorris@xxxxxxxxx]
> Sent: den 14 november 2006 23:18
> To: dev@xxxxxxxxxxxxxxxxxx
> Subject: RE: [argouml-dev] Problem with the persistence/load of
diagrams.
> 
> I think that the the classloader problem, while perhaps tricky, is
> definitely solvable.
> 
> I don't think Bob's workaround is necessary, but as a general comment
on
> the
> topic he raised:
> 
> > It seems that you can call the constructors of your own Figs
> > but creating by reflection has problems.
> >
> > So what I can do is provide an API in GEF where an
> > application can register a factory object to create diagrams.
> 
> I think moving away from using reflection is a good idea.  Having the
> diagram parser depend on an implied interface based on our internal
class
> structure has proven to be quite fragile and I think a more formal
> interface
> is needed.  Using reflection removes that formality.  For something
like a
> file format, having a stable, formally reviewed, slowly changing (or
> non-changing) interface is a good thing.
> 
> Having said that if we're going to support pluggable diagram types, I
> think
> we should think through how this is done.  What happens if I send my
> project
> to someone that doesn't have the module installed?  Can they see the
shape
> of the diagram, but not act on it?  Does the whole project fail to
load?
> How are they informed what module they need and where they get it?
> Personally, I think they should be able to see and print the diagram
even
> if
> they don't have the module installed.
> 
> Also, since GEF is nominally separate from ArgoUML, we shouldn't be
> directly
> exposing any of its internal APIs since this makes it impossible to
> change/replace in the future. (cf LeakyAbstraction)
> 
> Tom
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx