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

Hi all again,

First at all, I want to thanks all the efforts you are doing for help
me. Im sorry for replying to late.

After some work, and adding the classpath in my manifest, now I have a
different exception.

Now the problem with the Diagram doesn't occurs, the problem is
loading a fig. If I unzip my zargo file, my
test2_TraceabilityDiagram1.pgml file begins like follows:

<pgml 
description="org.argouml.uml.diagram.traceability.ui.MACMASTraceabilityDiagram|-64--88-0-35--46d6af98:10f20989c0a:-8000:000000000000077B"
     name="Traceability Diagram 1"
>
 <group name="Fig0"
      description="org.argouml.uml.diagram.traceability.ui.FigLayer[40,
56, 750, 200];pathVisible=false;stereotypeVisible=true;visibilityVisible=false"
      href="-64--88-0-35--46d6af98:10f20989c0a:-8000:000000000000077E"
      fill="1"
      fillcolor="white"
      stroke="1"
      strokecolor="black"
 >

As you can see, and if I'm not wrong, now the parser know what is a
MACMASTraceabilityDiagram. But it fails in the FigLayer parsing.

In my FigLayer I have the following method:

   /**
    * USED BY PGML.tee.
    * @return the class name and bounds together with compartment
    * visibility.
    */
   public String classNameAndBounds() {
       return super.classNameAndBounds()
               + "stereotypeVisible=" + isStereotypeVisible()
               + ";"
               + "visibilityVisible=" + isVisibilityVisible();
   }

If I save and load as a Model zipped, I have no problem in the model loading.

I think we are near to the solution. Thanks again.

p.s. for Tom Morris: I have changed the manifest. Thanks for the suggestion.

On 11/17/06, Bob Tarling <bob.tarling@xxxxxxxxx> wrote:
> Forbidding may be a bit strong. But in general think it better to find
> some pattern to avoid it.
>
> Bob.
>
>
> On 17/11/06, Linus Tolke <linus.tolke@xxxxxxxx> wrote:
> > 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
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx


--
Regards,

Christian López Espínola