Login | Register
My pages Projects Community openCollabNet

gef
Reply to message

* = Required fields
* Subject
* Body
Attachments
Send reply to
Topic
Author (directly in email)
Please type the letters in the image above.

Original message

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