Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: [gef-dev] TEE vs. Velocity vs. DOM

gef
Discussion topic

Back to topic list

Re: [gef-dev] TEE vs. Velocity vs. DOM

Reply

Author Bob Tarling <bob dot tarling at ntlworld dot com>
Full name Bob Tarling <bob dot tarling at ntlworld dot com>
Date 2004-04-17 05:35:55 PDT
Message I presume these files are only used to save and something other mechansim is
used to load. So I need only to mark the get methods of attributes in tee
files.

Bob.

----- Original Message -----
From: "Bob Tarling" <bob.tarling@ntlw​orld.com>
To: <dev at gef dot tigris dot org>
Sent: Saturday, April 17, 2004 1:25 PM
Subject: Re: [gef-dev] TEE vs. Velocity vs. DOM


> Hi Jason
>
> I've gone through all GEF source and added to the javadoc of any method
that
> is referred to from a tee file. This should warn developers not to remove
a
> method unless they modify the tee file also.
>
> It actually now makes sense to me why there are some otherwise bizarre
> methods on some classes.
>
> I'm still not really happy with this mechanism. What I've put in place may
> help prevent developers from removing methods that our own tee files use
but
> projects such as ArgoUML replace ours with their own tee files. I happen
to
> know ArgoUML but for any third party app I still stand a chance of
breaking
> it.
>
> I'd still like to determine the extent of use of this mechanism by dev
users
> other than ArgoUML. I shall email the user base on my return from holiday.
>
> Now if the tee files could generate code instead of being interpretted,
that
> would be another matter. That would still give compile time safety and we
> would also get warnings at deprecation time rather than when the method is
> removed.
>
> Regards
>
> Bob.
>
>
> ----- Original Message -----
> From: "Bob Tarling" <bob.tarling@ntlw​orld.com>
> To: <dev at gef dot tigris dot org>
> Sent: Thursday, March 04, 2004 8:45 PM
> Subject: Re: [gef-dev] TEE vs. Velocity vs. DOM
>
>
> > Hi Jason
> >
> > Before taking this conversation any further I'd like to discover who is
> > actually using this saving method.
> >
> > My assumption is that it is only ArgoUML.
> >
> > I can find no documentation for how this saving method is to be used and
> the
> > only example in GEFDemo uses serialization.
> >
> > As the serialization method won't be stable between different versions
of
> > GEF (which is documented in CmdSave) then I assume that all GEF projects
> > other than ArgoUML simply create there own persistence mechanism (that
has
> > certainly been my choice).
> >
> > If I can confirm this on the user list I'd like to deprecate any of this
> > stuff from GEF and push it out to ArgoUML. That way I can go ahead and
> > modify GEF with less fear of breaking anything else.
> >
> > Regards
> >
> > Bob.
> >
> > ----- Original Message -----
> > From: "Bob Tarling" <bob.tarling@ntlw​orld.com>
> > To: <dev at gef dot tigris dot org>
> > Sent: Saturday, February 21, 2004 2:25 AM
> > Subject: Re: [gef-dev] TEE vs. Velocity vs. DOM
> >
> >
> > > Just thinking on the fly....
> > >
> > > I wonder if XSLT could transform your tee files into java source.
> > >
> > > That way I get my compile time safety.
> > >
> > > Bob.
> > >
> > > ----- Original Message -----
> > > From: "Jason Robbins" <jrobbins at tigris dot org>
> > > To: <dev at gef dot tigris dot org>
> > > Sent: Saturday, February 21, 2004 1:59 AM
> > > Subject: [gef-dev] TEE vs. Velocity vs. DOM
> > >
> > >
> > > > In my previous message, I had listed
> > > > #1. use Velocity
> > > > #2. use DOM
> > > >
> > > > Velocity might be faster since I think that it only parses the
> > > > expressions once. However, TEE seems fast enought, and it could be
> > > > made much faster if the results of getMethod("get" + ...) and
> > > > the associated chain of exception handlers were cached instead of
> > > > being done via reflection each time.
> > > >
> > > > My bigger concern is that I am not sure that Velocity can handle
> > > > recursive templates. I know it can do complex nested loops, and
> nested
> > > > templates via #parse, but I am not sure about actually recursively
> > > > including the same template within itself. That is needed for
> > > > recursively groups of figs.
> > > >
> > > > DOM will use a lot of memory if we have to construct a new Element
for
> > > > for every Fig. Alternatively, we could add DOM element interfaces to
> > > > Figs. Either way it will mean that there will be one hard-coded
> mapping
> > > > from GEF's datastructures to XML. This is in contrast to the
template
> > > > approach that is less hard-coded in java. If that is the case, I
> think
> > > > that we should make a gef.dtd that is not itself tied to any
standard,
> > > > but fits GEF well and that makes it easy to use XLST to generate SVG
> > > > files. I think that is probably the best thing to do.
> > > >
> > > > I am not so familiar with existing SVG libraries like Batik. Maybe
> > > > they have a good SVG parser and writer. I think that SVG is kind of
> > > > a difficult standard to fully support.
> > > >
> > > >
> > > > jason!
> > > >
> > > >
> > > >
> > >
> --------------------​--------------------​--------------------​---------
> > > > To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
> > > > For additional commands, e-mail: dev-help at gef dot tigris dot org
> > > >
> > >
> > > --------------------​--------------------​--------------------​---------
> > > To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
> > > For additional commands, e-mail: dev-help at gef dot tigris dot org
> > >
> > >
> >
> >
> > --------------------​--------------------​--------------------​---------
> > To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
> > For additional commands, e-mail: dev-help at gef dot tigris dot org
> >
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
> For additional commands, e-mail: dev-help at gef dot tigris dot org
>


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
For additional commands, e-mail: dev-help at gef dot tigris dot org

« Previous message in topic | 5 of 5 | Next message in topic »

Messages

Show all messages in topic

[gef-dev] TEE vs. Velocity vs. DOM anoncvs anonymous CVS access 2004-02-20 17:59:51 PST
     Re: [gef-dev] TEE vs. Velocity vs. DOM Bob Tarling <bob dot tarling at ntlworld dot com> Bob Tarling <bob dot tarling at ntlworld dot com> 2004-02-20 18:25:05 PST
         Re: [gef-dev] TEE vs. Velocity vs. DOM Bob Tarling <bob dot tarling at ntlworld dot com> Bob Tarling <bob dot tarling at ntlworld dot com> 2004-03-04 11:45:34 PST
             Re: [gef-dev] TEE vs. Velocity vs. DOM Bob Tarling <bob dot tarling at ntlworld dot com> Bob Tarling <bob dot tarling at ntlworld dot com> 2004-04-17 05:25:58 PDT
                 Re: [gef-dev] TEE vs. Velocity vs. DOM Bob Tarling <bob dot tarling at ntlworld dot com> Bob Tarling <bob dot tarling at ntlworld dot com> 2004-04-17 05:35:55 PDT
Messages per page: