On 14/11/06, Tom Morris <[EMAIL PROTECTED]> wrote:
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:
For GEF in general I think this is useful so I'll go ahead there anyway.
I've done some work this evening. I'd hope to make an alpha build next
week so that Christian can take a look and see if it works for him.
> 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.
Personally I'd prefer we only supported the UML diagram types. However
historically with the API of ArgoUML being undefined and any visible
class considered up for grabs module writers have done as they choose.
For things like this I think support should be limited. It's outside
the bounds of UML and so in my opinion outside the bounds of ArgoUML.
However where a user has a need then I'll give some help where I can.
My understaning is that this is some private module and not a public
project that could effect other users.
Maybe Christian can confirm that and describe this new diagram type.
Possibly we can find a way of allowing an existing diagram type to be
extendable for his needs.
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?
It would certainly fail in an ungainly way at the moment (with the
same error the user has reported).
Most modules would not insist they are installed for reloading a
project so this is somewhat different.
We need some method to query in the module API to determine if it is
required on reload. If so then we could record this in the .argo file
on save. When later reading the .argo file we could fail far more
gracefully if we can't find that module installed.
How are they informed what module they need and where they get it?
If the module API had a method that described where to download it
then we could also store that data in the .argo and display that as
part of the error message if the module can't be found on project
load.
Personally, I think they should be able to see and print the diagram even if
they don't have the module installed.
Probably possible with a custom Diagram but not with a custom Fig. But
then I don't think we should support custom Figs. Instead existing
Figs should be stereotyped.
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)
We can certainly provide some API of our own for this that would
delegate to GEF.
Bob.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
