[Home]  [List]  [News]  [Docs]  [FAQ]  [Downloads]  [Resources]  [About]
Search :
/Home /List

list4xt : Mailing list for the XT users community.

[list4xt] Re: Extensions to XT

Subject: [list4xt] Re: Extensions to XT

User: Website

From: Paul Tchistopolskii (pault12@pacbell.net)
Date: 23/06/2000 - 11:01

> # 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://powhatantravel.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