Hello Bob!
I would prefer that we do not have to write and maintain a
diagraminterchange.tee script and a Parser for this. We have had
problems with this as long as I remember (and we still do). I am not
sure of the details of the problems but my guess is that they come from
inconsistencies between the tee script and the Parser.
If we were to go for a solution where the XML-generator and XML-parser
are generated by MDR from a model, then there would no longer be any
inconsistencies.
What we need is
- the model - it can be easily drawn from the Diagram Interchange 2.0
specification, and converted to MOF.
- a glue between GEF and the MDR-generated code that together with
information from the UML model present an editable diagram from the
information in MDR. This would then be the code of the Diagram
Subsystem.
If you say "We will write diagraminterchange.tee and a new parser." I am
thinking years of bugfixing and never getting it quite right.
/Linus
> -----Original Message-----
> From: Bob Tarling [mailto:[EMAIL PROTECTED]
> Sent: den 17 september 2006 21:05
> To: [email protected]
> Subject: Re: [argouml-dev] Keeping zargo file compatible with previous
> versions of ArgoUML
>
> GEF is not aware of MDR and there are no plans that it should be.
>
> GEF is a graph modelling system but it is the responsibility of the
> application to save and restore those models in whatever format is
> required for that application.
>
> For ArgoUML that is the diagram interchange format. GEF does not
> prevent this work being done in ArgoUML.
>
> We can write diagram interchange in a simlar way as we do for pgml by
> writing a diagraminterchange.tee script (or use some more standard
> template library such as velocity, freemarker or jamon). We will have
> to write a parser similar to PGMLStackParser to read the data back.
>
> This would not effect any subsystem dependencies.
>
> Bob.
>
> On 9/13/06, Linus Tolke <[EMAIL PROTECTED]> wrote:
> > Replying to an old mail...
> >
> > A stable and formal API and persistence format sounds very good.
> >
> > On the other hand, I agree with whoever mentioned it (Tom I think)
that
> > we are approaching the point where the next change to the save
format
> > concerning the save format of diagrams should be a move to the UML
2.0
> > Diagram Interchange format.
> >
> > With risk of restarting the very confusing discussion from last
> > summer...
> >
> > If we go for UML 2.0 Diagram Interchange format then it should not
be
> > very far fetched to put the diagram information in MDR and have it
> > parameterized by a Diagram Interchange meta-model. If that is the
case,
> > two groups of questions arise:
> >
> > Is GEF ready for this? Can GEF work while having things like list of
> > figures, color, size, position, and sub-parts accessed from a
> > repository? Can GEF accept events with changes of things in the
> > repository? Can GEF work with sizes and positions in floats?
> >
> > How does this affect the relationship between the involved
subsystems in
> > ArgoUML: Model, Model MDR implementation, Diagrams, and Persistence?
> >
> > Both these questions are for you, Bob, to answer. A clear "Yes" on
the
> > first group of questions is required, otherwise I'd say, GEF is not
> > ready for this.
> >
> > /Linus
> >
> > > -----Original Message-----
> > > From: Bob Tarling [mailto:[EMAIL PROTECTED]
> > > Sent: den 2 september 2006 15:28
> > > To: [email protected]
> > > Subject: [argouml-dev] Keeping zargo file compatible with previous
> > > versions of ArgoUML
> > >
> > > There are various reasons why it is not possible to load a zargo
file
> > > from a current release in a previous version of ArgoUML.
> > >
> > > I think there are 2 major problems that cause regular change.
> > >
> > > 1. Fixing errors in save due to previous ArgoUML bugs
> > >
> > > Some of these fixes must not be repeated. By saving a persistance
> > > version we ensure that a fix is run once and only once when we
know
> > > that it is required.
> > >
> > > 2. Use of PGML and reflection to save and load diagrams
> > >
> > > The current method of saving diagrams as PGML means every time we
> > > adjust the composite make up of a Fig then persistence format
differs.
> > >
> > > The problem comes if we have introduced some new Fig or refactored
the
> > > name or package of an existing Fig. For the current ArgoUML to
read
> > > previous projects we have no problem as the upgrade XSL adjusts
the
> > > project for these changes.
> > >
> > > However when a previous version of ArgoUML is used to load such a
> > > project it will attempt to create each Fig by reflection using the
> > > class names stored in the PGML. Obviously it won't find these and
> > > BANG.
> > >
> > > In the past this tended to mean some random exception being
presented
> > > to the user, the user creates issues in the database which we have
to
> > > investigate and our reply was always upgrade to latest version.
> > >
> > > This is why I introduced the persistence version. A value that
> > > increments each time such a change has taken place. Instead of an
> > > exception the user now sees a message asking them to upgrade.
> > >
> > > I hadn't previously seen this as a problem because ArgoUML is
becoming
> > > more stable and we want to push users towards that more stable
> > > release. I've tried to make changes as gradual as possible saving
any
> > > more major changes until after a stable release of ArgoUML.
> > >
> > > Changes to the Fig structure are certainly likely. Issue 3238 and
> > > issue 4426 spring to mind immeditely.
> > >
> > > We have problems now though of requirements of
> > > http://argoeclipse.tigris.org
> > >
> > > The argoeclipse project is not planning to keep step with ArgoUML
> > > releases. They are keeping to their own schedule. This means that
the
> > > latest version of argoeclipse may not be able to read a save file
from
> > > the latest version of ArgoUML.
> > >
> > > The only solution I see is to move to a more formal fixed format
than
> > > PGML for which we need to make a reader and writer that will be
> > > modified for each version. The logical choice with be the OMG
diagram
> > > interchange format but I was hoping not to do such major change
for a
> > > long time.
> > >
> > > With all of the above commments I'm not so sure if it's worth
spending
> > > time on issue 4431. This will not solve the requirements of
> > > argoeclipse as they will have compatability problems anyway.
> > >
> > > But it seems we have a catch 22. The requirements is to stabalise
the
> > > persistence format but in order to do that we need to change the
> > > persistence format.
> > >
> > > How do we go about this?
> > >
> > > As a slight aside. There has been some talk a couple of months
back
> > > about moving to ArgoUML 1.0.
> > >
> > > To my mind the most important thing for that release is not the
bug
> > > count but a stable and formal API and persistence format. I think
we
> > > have some way to go for that. Is that what we should be
concentrating
> > > on now?
> > >
> > > Bob.
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
