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:20
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://bookthatdoc.com)
(mailto:list4xt-request@4xt.org?Subject=unsubscribe to unsubscribe)
--
Mailing list for the XT users community. (http://onecalbank.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
|