list4xt : Mailing list for the XT users community.
[list4xt] Re: Extensions to XT
Subject: [list4xt] Re: Extensions to XT
User: Website From: Khun Yee Fung (KFung@extend.com)
Date: 23/06/2000 - 19:32
Well, it looks like
1. I was looking at the wrong place. I missed the whole thing.
2. And the extension functions (how to get to them) are hardcoded in
com/jclark/xsl/tr/SheetImpl.java
Hmmm... Do you think it is worth the effort to parameterize this file first?
Like putting the strings, etc. into an XML file (class names, so that
inflextion can be used (of course efficiency will suffer...)), or
something...
Again, please tell me if I missed the whole thing again.
Regards,
Khun Yee
-----Original Message-----
From: Khun Yee Fung [mailto:KFung@extend.com]
Sent: Friday, June 23, 2000 1:21 PM
To: 'list4xt@4xt.org'
Subject: [list4xt] Re: Extensions to XT
Well, my effort so far (about 30 mins. I spent quite a bit of time getting
the thing into a package yesterday). And it is quite different from what you
said. I wonder why. I will investigate more.
com/jclark/xsl/sax/ExtensionHandlerImpl.java: this is where the JAVA
namespace is defined and handled. I am reading this file to ensure I know
what it is doing and how it works.
com/jclark/xsl/dom/XSLTransformEngine.java: this is where the implementation
is instantiated. Again, I am reading to find out how it works.
I will see whether I can accmplish what I want to do without modification to
the whole thing at all. Failing that, I will see how to parameterized the
changes so that other people can add extensions to XT without any further
modifications.
Tell me if I missed the whole thing...
Regards,
Khun Yee
-----Original Message-----
From: Paul Tchistopolskii [mailto:pault12@pacbell.net]
Sent: Friday, June 23, 2000 5:02 AM
To: list4xt@4xt.org
Subject: [list4xt] Re: Extensions to XT
> # Working on next version of UX I have to re-engeneer detailes of how
> # xt:document works.
First about my problem.
UX work is a sandbox, so "/tmp/file.xml" should be actually mapped
to /virtual_root/tmp/file.xml, UX internal permissions of that file
should be checked, because it could be a destructive attempt
to override /etc/passwd.xml, for example. e t.c.
So I wanted to capture the moment when <xt:document
( I'm wondering why it is not in the standard!!! Soo handy... )
tries to create the output file and at that point I need to
do something about adding virtual root, for example.
But first I found that when invoking <xt:document in servlet
it does not create a file at all ( the same stylesheet when
running not in servlet mode - works ).
The solution was just to provide HackedServledDestination:
XSLProcessorImpl xsl ....
OutputMethodHandlerImpl outputMethodHandler = new
OutputMethodHandlerImpl(xsl);
xsl.setOutputMethodHandler(outputMethodHandler);
outputMethodHandler.setDestination ( new HackedServletDestination(response)
);
public class HackedServletDestination extends
com.jclark.xsl.sax.GenericDestination {
public Destination resolve(String uri) {
// System.err.println( "resolve: " + uri );
String file = FS.getUxRoot() + uri;
return new FileDestination(file);
}
}
So, actually I have not spend too much time with xt:document itself, but
when I was looking at the code I got a feeling that it should be
relatively easy to add your own extension elements, because XT
APIs look clean.
Basic XT dataflow appears to be ( talking about OM ):
1. Create 'Result'
2. Load stylesheet. ( 'compile templates into 'actions' ).
3. Process stylesheet ( start from root and 'execute actions' , fill the
'result' )
4. result.start() and then result.end() -> dump the result out.
If making a breakpoint at DocumentAction.invoke() - the execution stack is
clear.
DocumentAction is responsible for processing <xt:document . Even the
processing
of this action is in fact very simple, I think analyzing <xt:document could
be a good
starting point for implementation of any extension element.
To add the new extension element, steps could be:
1. Create Parser for your element. ( see
class SheetImpl implements SheetDetails, LoadContext {
private
class DocumentParser implements ActionParser {
.......
}
The purpose of this Parser will be to 'translate' the
'context' into appropriate 'action'(s).
Actually, I think that because there are many other
'translations' for all the xsl elements - 'do the same'
with your extension elements could work pretty well...
2. Attach Parser to the particular element : see
SheetImpl constructor does it.
actionTable.put(xt("document"), new DocumentParser());
3. Implement your own action for new element:
class DocumentAction implements Action {
}
I think that implementing 'invoke' is the only thing needed
in most cases. And again - there are a lot of examples
for other elements, so the same 'do the same' could work
pretty well.
I'm sorry if what I say above is trivial or misleading. Unfortunately,
at the moment I don't need to write my own elements, so it is
the best I can say after 2 hours of digging.
Rgds.Paul.
--
Mailing list for the XT users community. (http://texascountrybank.com)
(mailto:list4xt-request@4xt.org?Subject=unsubscribe to unsubscribe)
--
Mailing list for the XT users community. (http://vitessefinancial.com)
(mailto:list4xt-request@4xt.org?Subject=unsubscribe to unsubscribe)
--
Mailing list for the XT users community. (http://comicmediaexpo.com)
(mailto:list4xt-request@4xt.org?Subject=unsubscribe to unsubscribe)
Archive générée par hypermail 2b28 le 06/11/2001 - 11:46 CET
webmaster@4xt.org
|