In the 2.2d6 release in the TransformerFactoryImpl, there is still a check
for the "transletPool" system property. I am now confused on whether this
is in use or not. I am using it to make sure that all my translets end up
in the same directory (so the can be picked up in the classpath, although
this does not seem to work for me). Should the "transletPool" continue to
be used, and if not should one just use the "setDestDirectory()" method to
place the translets in the correct place?
In the response below, you say that the translet object is not written to a
disk, yet that, I thought, was half the point of using translets. Compile
once, use over and over. On a web based applications, keeping multiple
translets in memory is not always practical, and the overhead of reloading
the stylesheets all the time can consume a lot of resources. You also state
that the user need not be concerned with the classnames. Could you expain
how this is so? Is the template supposed to abstract the translet out to
such a degree that you don't even know you are using it?
gordon
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 17, 2001 8:36 AM
To: [EMAIL PROTECTED]
Subject: Re: Setting Package and directory properties in XSLTC
Hi Shane,
With TrAX the user should not have to deal with package names,
translet class names and output directories. With the new TrAX
design we wrap the translet class and auxiliary class definitions
inside the Templates object. The user will not even know what
the translet class name is (nor whould he/she have to), the
translet is not written to a disk (the user can serialize the
Templates object in which the class definitions is stored), and
there is no package name used.
Morten
Shane Curcuru wrote:
>
> Are we planning to provide TrAX-ized ways to set these
> xsltc-specific properties? (Sorry if I missed an
> earlier conversation about this) These sound like
> perfect items to get set through
> TransformerFactory.setAttribute(String attrName,
> Object value) calls. That way, someone's properly
> written code will work on any TrAX processor
> (presuming you catch any IllegalArgumentExceptions
> that denote the particular impl doesn't support that
> property).
>
> This would be good for testing too, since any tests
> written to the TrAX interfaces will (mostly) work on
> either xalan or xsltc. I.e. for a conformance test
> driver, we could have it attempt to always set these
> attributes on the TransformerFactory. If we happen to
> be testing xsltc, these will take effect. If we
> happen to be testing xalan, these'll throw
> IllegalArgumentException, which we'll ignore. In
> either case, the overall result (or the
> conf/output/file.out) file should be the same for
> both.
>
> (i.e. even though this test doesn't specifically
> validate the dir-setting features, there are plenty of
> other bits of functionality that are common between
> the processors, presuming we can address all this
> stuff through TrAX).
>
> OK, I haven't had enough coffee yet: am I making any
> sense?
> - Shane
>
> ---- you Morten Jorgensen <[EMAIL PROTECTED]>
> wrote ----
> No, you can't. Not after the re-design of our TrAX
> support.
> But, the org.apache.xalan.xsltc.compiler.XSLTC class
> has a
> set of public methods that can be used to set the
> package
> name, translet class name, output directory and such:
>
> setClassName(String className);
> setDestDirectory(String absolutePathName);
> setPackageName(String packageName);
> setJarFileName(String archiveName);
>
> Morten
>
> =====
> <eof aka="mailto:[EMAIL PROTECTED]";
> humor="Du sublime au ridicule il n'y a qu'un pas." />
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/
