Login | Register
My pages Projects Community openCollabNet

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

gef
Discussion topic

Hide all messages in topic

All messages in topic

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

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:25:58 PDT
Message 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

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-03-04 11:45:34 PST
Message 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

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-02-20 18:25:05 PST
Message 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

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

Reply

Author anoncvs
Full name anonymous CVS access
Date 2004-02-20 17:59:51 PST
Message 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
Messages per page: