>", rather than in any
arbitrary namespace as the XSLT recommendation says. The file
ExtensionHandlerImpl.java which Khun Yee Fung mentioned in an earlier
message makes this possible by implementing the function-available
function and the actual function call (using reflection).
I've used this in some experimental FOP tests and it works nicely; no
need to change xt code.
xt also contains 3 built-in extension functions which are handled in the
expr.ExprParser class.
But it looks like this discussion is really about extension ELEMENTS. As
Paul T. correctly points out, xt doesn't implement the general extension
element mechanism. It's also true that support for the xt:document
extension element is hard-coded in 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...
The XSLT standard describes how the general mechanism should work.
Basically any element appearing inside an xsl:template which has a
namespace prefix appearing in an extension-element-prefixes attribute is
considered as an extension element. So it is then treated as an
instruction and not a literal result element.
I don't think it would be too hard to implement recognizing such
elements, but the real issue is how to process them. Extensions written
in java could probably be handled similarly to extension functions,
although I honestly haven't thought much about this.
>
> Again, please tell me if I missed the whole thing again.
>
> Regards,
> Khun Yee
Hardly, and thanks for initiating an interesting discussion.
Regards,
Karen L.
> -----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://jbiztechvalley.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