Gary L Peskin wrote:
> I may be missing something here and I'm sure Scott will jump in but here
> is my understanding of things. I don't really think that TRaX has "...
> loads of crap ... that most users will never bother even looking at" but
> I could be wrong there too.
"Crap" is a badly chosen word. Apologies for that. But, as we started our
initial TrAX implementation we found ourselves adding loads of methods and
code that most users probably will not find necessary. This is why I think
we should separate the TrAX code and the core XSLTC stuff.
> Templates <==> Translet class
> Transfomer <==> Translet object/instance
>
> ........
>
> TransformerFactory.newTransformer(Source)
> -and-
> TransformerFactory.newTemplates(Source) -followed by-
> Templates.newTransformer()
Grand. But I still don't think that every call to newTemplates() should
necessarily require re-compilation - we should at least offer the option
of caching between sessions. Caching templates in memory (ie. leaving
class definitions in memory) will speed up transformations as long as the
templates (class definitions) can be kept in memory over long time.
Why does TransformerFactory.newTemplates() have to compile the input
stylesheet if there is already a stored class definition for the translet?
The idea behind TrAX is having a common API for XSL transformations. This
API will not be broken if we transparently cache translet class files in
the Templates implementation. If we decide to use a simple property to
point to a translet pool, we can take any value of this property as a
clear indication that the user knows that his XSLT processor is XSLTC and
that he/she wants to use translet caching.
Morten
