list4xt : Mailing list for the XT users community.

[list4xt] Re: Extensions to XT

New Message
• Reply
• Next message: Paul Tchistopolskii: "[list4xt] xt:document. I hit the wall."
• Previous message: Paul T: "[list4xt] Re: Extensions to XT"
• Maybe reply: Khun Yee Fung: "[list4xt] Re: Extensions to XT"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Thank you very much for you message.

Byte-code is really the only way to go, if you ask me... A bit like doing
Perl, right? If we can compile XSLT document in Java byte code, that would
be even more interesting, don't you think? Assuming that it can be done.

I will try doing an extension like the xt:document element. A simple one in
any case. After that, I will see whether it is worth parameterizing XT. If
not, that is fine.

My view on extension? Why, I never use extension elements and functions.

After all, I am doing it because I think it can be done. The fun factor.
That is all.

Khun Yee

-----Original Message-----
From: Paul T [mailto:pault12345@yahoo.com]
Sent: Friday, June 23, 2000 4:33 PM
To: list4xt@4xt.org
Subject: [list4xt] Re: Extensions to XT

  Khun Yee Fung <KFung@extend.com> wrote:

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...

# You'l have to parametrize all of 3 layers. ( 1 and 2 located in SheepImpl,
but the Actions are kind of byte-code ... ) Parametrizing all of those
layers looks doable, but you should be very brave person to try that without
experimenting with 2-3 complex custom extension elements first. Anyway the
task of 'plug&play' extension elements looks hard. By the way , after (if)
you invent the automata for 'plug&play' elements then you could rewrite the
standard XSLT elements to use the same automata ;-). Current behaviour of XT
is that extension elements are 'the same' with XSLT elements. That means,
because for XSLT elements the syntax / semantics is hardcoded - the same is
with extension elements)

<quote>

The following features of the XSLT PR are not yet implemented:

   the element extension mechanism (the extension-element-prefixes and
xsl:extension-element-prefixes attributes, the xsl:fallback element, and the
element-available function)

</quote>

I think implementing the automata for plug&play extension elements could be
very cool thing, but because I can ( and I try to) live without extension
elements at all, I have very messy feelings on extension elements. BTW - I
still don't understand why you need to base something on extension elements
? For example, I would say for self-documentation : just use comments and
place XML inside of comments ;-)

# Conclusion.

1. Create Parser for your element. ( see

     class DocumentParser implements ActionParser {
        .......
     }

     The purpose of this Parser will be to 'translate' the
     'context' into appropriate 'action'(s).

     
 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 {
    }

---------------------------------
Do You Yahoo!?
Get Yahoo! Mail - Free email you can access from anywhere!

--
Mailing list for the XT users community.     (http://northernmarianashumanities.org)
(mailto:list4xt-request@4xt.org?Subject=unsubscribe to unsubscribe)
--
Mailing list for the XT users community.     (http://merchantaccountsreview.com)
(mailto:list4xt-request@4xt.org?Subject=unsubscribe to unsubscribe)

• Next message: Paul Tchistopolskii: "[list4xt] xt:document. I hit the wall."
• Previous message: Paul T: "[list4xt] Re: Extensions to XT"
• Maybe reply: Khun Yee Fung: "[list4xt] Re: Extensions to XT"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]