You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by "Voytenko, Dimitry" <DV...@SECTORBASE.COM> on 2000/11/05 22:28:28 UTC
RE: Extension mechanism propositions
Hi Gary,
Is this mechanism we talked about already presented in the Xalan J2? If yes,
where I can read about it.
And I have one more question about using extensions. I got the next
situation:
You made possible to use xpath without XSLT transformater. This feature is
very suitable and usefull. I already replaced all code that searched on the
DOM with XPathAPI. Also I had couple extension functions that I implemented
as built-in functions because they were used almost in each template. Then I
reimplemented them to standard extension mechanism because I was sure you
will change this API in Xalan J2 (at least a little bit) and found out that
several XPath expressions stopped working because they used these built-in
functions.
So right now I'm going to return these functions to built-in implementation
because I realize that there's no way to specify extension in the XPath
expression, but it's easier for me to return built-in functions than rewrite
all xpath expressions.
So do you think it is still bad from your prospective to use built-in
mechanism? If so can you suggest me some way to avoid this? If no why don't
you remove limit of 30 available built-in extension functions from XPath?
Thank you
Dmytro E. Voytenko
Software Engineer
Sectorbase.COM
-----Original Message-----
From: Gary L Peskin [mailto:garyp@firstech.com]
Sent: Thursday, October 19, 2000 16:52
To: xalan-dev@xml.apache.org
Subject: Re: Extension mechanism propositions
"Voytenko, Dimitry" wrote:
> Right now Xalan has special extension mechanism for Java methods. But also
> it has mechanism for built-in functions (sort of internal mechanism,
that's
> not recommended for using). But it's still very sutable because of:
> 1. It allows to easily manipulate with arguments types and number and type
> of return value
> 2. It allows access to some Stylesheet information. If built-in function
> format-number has access to list of decimal formats in stylesheet why
can't
> my function has it?
>
> Is it possible that you support Function class (or some interface) as a
part
> of extension mechanism and than you will just check if extension class is
> instance of it and process it differently. Or may be you have other
> solutions for these issues.
Dimitry --
I am working on adding exactly this functionality to XalanJ2 right now.
Your function will need to be a subclass of
org.apache.xpath.functions.Function and it will be accessed exactly like
the XSLT built-in functions. You'll use a special namespace for it.
Right now, it looks like the namespace URI will be:
xxx="xalannative://packagename"
and you'll access it like:
xxx:myfunc(arg, ....)
which will invoke the class packagename.FuncMyfunc.
By the way, in XalanJ2, you can specify an optional first argument to
your java extension functions of type
org.apache.xalan.extensions.ExpressionContext. This will pass an
ExpressionContext to your function which will contain lots of functions
to give you access to various parts of the stylesheet. Although not
many methods are currently defined for the ExpressionContext interface,
we actually pass a
org.apache.xpath.XPathContext
which has methods to get to a lot of things. Then, you can do
public static NodeIterator myExtFunc(ExpressionContext xctxt, ...) {
if (xctxt instanceof XPathContext) {
XPathContext myxctxt = (XPathContext) xctxt;
myxctxt.xxx
}
}
Of course, this code may not work if we decide in the future to pass
some other type of ExpressionContext.
Within limits, we can add some methods to the ExpressionContext
interface which we hope to have standardized eventually by W3C.
HTH,
Gary
Re: Extension mechanism propositions
Posted by Gary L Peskin <ga...@firstech.com>.
"Voytenko, Dimitry" wrote:
> Is this mechanism we talked about already presented in the Xalan J2? If yes,
> where I can read about it.
Hi, Dimitry. Actually, I'm in the middle of implementing the
non-reflection extension function mechanism. I'm working on doing some
conformance testing with some of my other changes before I upload this
implementation to CVS.
> And I have one more question about using extensions. I got the next
> situation:
>
> So right now I'm going to return these functions to built-in implementation
> because I realize that there's no way to specify extension in the XPath
> expression, but it's easier for me to return built-in functions than rewrite
> all xpath expressions.
I'm not sure what you mean here. Do you mean that you can't specify
extension functions because there's nowhere for you to declare your
namespace? I believe that when you construct a new XPath and also when
you execute it, that you specify a PrefixResolver which maps prefixes to
namespace URIs. Is this what you mean? I'm confused here and I think
an example would help me understand.
I'm very eager to adapt Xalan to meet your extension needs so if you can
provide some examples that we can work through, we can arrive at a
solution that will make everyone happy, I hope.
> So do you think it is still bad from your prospective to use built-in
> mechanism? If so can you suggest me some way to avoid this? If no why don't
> you remove limit of 30 available built-in extension functions from XPath?
I'm slowly coming around on Costin's suggestion regarding non-reflection
extensions. Of course, this mechanism is subject to being changed from
release to release but that is a tradeoff of speed versus maintenance
that each person will need to factor in. Since Xalan is open source,
you're free to expand the tables to whatever you like. In my changes,
the extension table will not be used so we won't be consuming any
entries in it. Extensions are triggered by a non-null namespace
prefix. Whether this will be a non-reflection extension or a
traditional extension is determined by the URI scheme (the part before
the colon).
Gary
Re: Extension mechanism propositions
Posted by Gary L Peskin <ga...@firstech.com>.
> "Mark A. Richman" wrote:
>
> Ok...here we go. This is the output when passing in "mark" :
>
>
> XPath: //users/user[@username='mark'] <users>
>
> <user email="mark@markrichman.com" password="mypassword"
> rootfolder="c:/users/mark/" username="mark"></user>
>
> </users>//users/user[@username='mark']
>
> root = [users: null]
>
> usernode= [user: null]
>
> node name: user mark mypassword mypassword Process Exit...
>
> You can see it works fine. Now here we are when I pass in "mark2":
>
> XPath: //users/user[@username='mark2'] <users>
>
> <user email="mark@markrichman.com" password="mypassword"
> rootfolder="c:/users/mark/" username="mark"></user>
>
> </users>//users/user[@username='mark2']
>
> root = [users: null]
>
> usernode= null
>
> java.lang.NullPointerException at
> XRFIUsers.getPassword(XRFIUsers.java:61) at
> XRFIUsers.main(XRFIUsers.java:132) Exception in thread "main" Process
> Exit...
>
> I'm at a complete loss here. I hope you can help.
Mark --
It looks like your "root" element contains the users element, which is
fine. But your users element contains only one user element, the one
for mark. Look at the printout of the <users> element. Why does it
contain juse the one child, instead of the four children as in your
original example?
Where is <users> coming from. The xmlfile you're parsing must contain
just the one element. Check its contents again and make sure your
xmlfile name is the one you're thinking it is.
Gary
Re: Extension mechanism propositions
Posted by "Mark A. Richman" <mr...@ispchannel.com>.
Ok...here we go. This is the output when passing in "mark" :
XPath: //users/user[@username='mark'] <users>
<user email="mark@markrichman.com" password="mypassword" rootfolder="c:/users/mark/" username="mark"></user>
</users>//users/user[@username='mark']
root = [users: null]
usernode= [user: null]
node name: user mark mypassword mypassword Process Exit...
You can see it works fine. Now here we are when I pass in "mark2":
XPath: //users/user[@username='mark2'] <users>
<user email="mark@markrichman.com" password="mypassword" rootfolder="c:/users/mark/" username="mark"></user>
</users>//users/user[@username='mark2']
root = [users: null]
usernode= null
java.lang.NullPointerException at XRFIUsers.getPassword(XRFIUsers.java:61) at XRFIUsers.main(XRFIUsers.java:132) Exception in thread "main" Process Exit...
I'm at a complete loss here. I hope you can help.
- Mark
----- Original Message -----
From: "Gary L Peskin" <ga...@firstech.com>
To: <xa...@xml.apache.org>
Sent: Sunday, November 05, 2000 9:19 PM
Subject: Re: Extension mechanism propositions
> Gary L Peskin wrote:
> >
> > new dom.DOMWriter(false).print(root);
>
> You'll need to be sure to have xercesSamples.jar in your classpath.
>
> Gary
>
Re: Extension mechanism propositions
Posted by Benoit Cerrina <be...@writeme.com>.
Hi, Mark,
also I suggest you try to write the node you retrieve using the same
DOMWriter.
I myself had trouble with xerces nodes when trying to print them out for
debugging purpose they always came out like [node: null] or some
such then when I used a debugger I saw that they weren't null so I used a
serializer and behold, my null nodes where actually what I expected.
Benoit
----- Original Message -----
From: "Gary L Peskin" <ga...@firstech.com>
To: <xa...@xml.apache.org>
Sent: Monday, November 06, 2000 3:19 AM
Subject: Re: Extension mechanism propositions
> Gary L Peskin wrote:
> >
> > new dom.DOMWriter(false).print(root);
>
> You'll need to be sure to have xercesSamples.jar in your classpath.
>
> Gary
Re: Extension mechanism propositions
Posted by Gary L Peskin <ga...@firstech.com>.
Gary L Peskin wrote:
>
> new dom.DOMWriter(false).print(root);
You'll need to be sure to have xercesSamples.jar in your classpath.
Gary
Re: Extension mechanism propositions
Posted by Gary L Peskin <ga...@firstech.com>.
"Mark A. Richman" wrote:
>
> Here is my output after the XPathAPI.selectSingleNode() call:
> root = [users: null]
>
> usernode= null
>
> java.lang.NullPointerException at XRFIUsers.getPassword(XRFIUsers.java:58)
> at XRFIUsers.main(XRFIUsers.java:129) Exception in thread "main" Process
> Exit...
And what does the print out of the XPath look like from earlier in the
program.
There is something going wrong here, obviously, and it can only be from
a few places. Either (a) your XPath expression isn't what you think it
is (this could be from extra whitespace for example -- where is your
username coming from?) or (b) the tree off of the root node isn't what
you think it is.
Printing out the XPath expression will take care of (a). For (b),
you'll either need to examine the tree in a debugger or insert
new dom.DOMWriter(false).print(root);
just before the XPathAPI call in the try clause.
This has to be something simple that we're just not seeing.
Gary
Re: Extension mechanism propositions
Posted by "Mark A. Richman" <mr...@ispchannel.com>.
Here is my output after the XPathAPI.selectSingleNode() call:
root = [users: null]
usernode= null
java.lang.NullPointerException at XRFIUsers.getPassword(XRFIUsers.java:58)
at XRFIUsers.main(XRFIUsers.java:129) Exception in thread "main" Process
Exit...
Thanks Gary....
-Mark
----- Original Message -----
From: "Gary L Peskin" <ga...@firstech.com>
To: <xa...@xml.apache.org>
Sent: Sunday, November 05, 2000 7:23 PM
Subject: Re: Extension mechanism propositions
> "Mark A. Richman" wrote:
> > What gives? Here is my code:
>
> I'm baffled here. I copied your code exactly and it ran with mark and
> mark2 with no problems.
>
> Try inserting
>
> System.out.println("root = " + root + "\nusernode= " + usernode);
>
> after the usernode = XPathAPI ... statement and let's see what gives.
>
> Gary
>
Re: Extension mechanism propositions
Posted by Gary L Peskin <ga...@firstech.com>.
"Mark A. Richman" wrote:
> What gives? Here is my code:
I'm baffled here. I copied your code exactly and it ran with mark and
mark2 with no problems.
Try inserting
System.out.println("root = " + root + "\nusernode= " + usernode);
after the usernode = XPathAPI ... statement and let's see what gives.
Gary
Re: Extension mechanism propositions
Posted by "Mark A. Richman" <mr...@ispchannel.com>.
I am using Xalan-J 1.2 (10/13/2000) to evaluate the following expression on
this XML file:
<?xml version="1.0"?>
<users>
<user username="mark" password="mypassword" email="mark@markrichman.com"
rootfolder="c:/users/mark/"/>
<user username="mark2" password="mypassword2" email="mark2@markrichman.com"
rootfolder="c:/users/mark2/"/>
<user username="mark3" password="mypassword3" email="mark3@markrichman.com"
rootfolder="c:/users/mark3/"/>
<user username="mark4" password="mypassword4" email="mark4@markrichman.com"
rootfolder="c:/users/mark4/"/>
</users>
When I apply the following XPath expression, I retrieve a Node:
//users/user[@username='mark']
But when I substitute @username='mark2', I get a null Node object back.
What gives? Here is my code:
try
{
parser.parse(xmlFile);
}
catch (Exception e)
{
e.printStackTrace();
}
document = parser.getDocument();
Node root = parser.getDocument().getDocumentElement();
Node usernode = null;
//XPath looks like: "/users/user[@username='mark']"
String xpath = "//users/user[@username='" + username +"']";
System.out.println("XPath: " + xpath);
try
{
usernode = XPathAPI.selectSingleNode(root, xpath); // getting null
usernode with 'mark2' here!!!!
}
catch(Exception ex)
{
System.out.println(ex);
}
Thanks,
Mark
----- Original Message -----
From: "Gary L Peskin" <ga...@firstech.com>
To: <xa...@xml.apache.org>
Sent: Sunday, November 05, 2000 6:48 PM
Subject: Re: Extension mechanism propositions
> "Mark A. Richman" wrote:
> >
> > How do you replace XPathAPI.java? I am having trouble parsing some
> > expressions, and I'd like to get rid of it altogether. Thanks, Mark.
>
> I'm not sure what you're asking. Can you give us an example of where
> you're having trouble? You're free to look at the XPathAPI source to
> see how it calls the lower-level XPath routines and to call those
> yourself.
>
> Gary
>
Re: Extension mechanism propositions
Posted by Gary L Peskin <ga...@firstech.com>.
"Mark A. Richman" wrote:
>
> How do you replace XPathAPI.java? I am having trouble parsing some
> expressions, and I'd like to get rid of it altogether. Thanks, Mark.
I'm not sure what you're asking. Can you give us an example of where
you're having trouble? You're free to look at the XPathAPI source to
see how it calls the lower-level XPath routines and to call those
yourself.
Gary
Re: Extension mechanism propositions
Posted by "Mark A. Richman" <mr...@ispchannel.com>.
How do you replace XPathAPI.java? I am having trouble parsing some
expressions, and I'd like to get rid of it altogether. Thanks, Mark.
----- Original Message -----
From: "Voytenko, Dimitry" <DV...@SECTORBASE.COM>
To: <xa...@xml.apache.org>
Sent: Sunday, November 05, 2000 4:28 PM
Subject: RE: Extension mechanism propositions
> Hi Gary,
>
> Is this mechanism we talked about already presented in the Xalan J2? If
yes,
> where I can read about it.
> And I have one more question about using extensions. I got the next
> situation:
>
> You made possible to use xpath without XSLT transformater. This feature is
> very suitable and usefull. I already replaced all code that searched on
the
> DOM with XPathAPI. Also I had couple extension functions that I
implemented
> as built-in functions because they were used almost in each template. Then
I
> reimplemented them to standard extension mechanism because I was sure you
> will change this API in Xalan J2 (at least a little bit) and found out
that
> several XPath expressions stopped working because they used these built-in
> functions.
> So right now I'm going to return these functions to built-in
implementation
> because I realize that there's no way to specify extension in the XPath
> expression, but it's easier for me to return built-in functions than
rewrite
> all xpath expressions.
> So do you think it is still bad from your prospective to use built-in
> mechanism? If so can you suggest me some way to avoid this? If no why
don't
> you remove limit of 30 available built-in extension functions from XPath?
>
> Thank you
>
> Dmytro E. Voytenko
> Software Engineer
> Sectorbase.COM
>
> -----Original Message-----
> From: Gary L Peskin [mailto:garyp@firstech.com]
> Sent: Thursday, October 19, 2000 16:52
> To: xalan-dev@xml.apache.org
> Subject: Re: Extension mechanism propositions
>
>
> "Voytenko, Dimitry" wrote:
> > Right now Xalan has special extension mechanism for Java methods. But
also
> > it has mechanism for built-in functions (sort of internal mechanism,
> that's
> > not recommended for using). But it's still very sutable because of:
> > 1. It allows to easily manipulate with arguments types and number and
type
> > of return value
> > 2. It allows access to some Stylesheet information. If built-in function
> > format-number has access to list of decimal formats in stylesheet why
> can't
> > my function has it?
> >
> > Is it possible that you support Function class (or some interface) as a
> part
> > of extension mechanism and than you will just check if extension class
is
> > instance of it and process it differently. Or may be you have other
> > solutions for these issues.
>
> Dimitry --
>
> I am working on adding exactly this functionality to XalanJ2 right now.
> Your function will need to be a subclass of
> org.apache.xpath.functions.Function and it will be accessed exactly like
> the XSLT built-in functions. You'll use a special namespace for it.
> Right now, it looks like the namespace URI will be:
>
> xxx="xalannative://packagename"
>
> and you'll access it like:
>
> xxx:myfunc(arg, ....)
>
> which will invoke the class packagename.FuncMyfunc.
>
> By the way, in XalanJ2, you can specify an optional first argument to
> your java extension functions of type
> org.apache.xalan.extensions.ExpressionContext. This will pass an
> ExpressionContext to your function which will contain lots of functions
> to give you access to various parts of the stylesheet. Although not
> many methods are currently defined for the ExpressionContext interface,
> we actually pass a
>
> org.apache.xpath.XPathContext
>
> which has methods to get to a lot of things. Then, you can do
>
> public static NodeIterator myExtFunc(ExpressionContext xctxt, ...) {
> if (xctxt instanceof XPathContext) {
> XPathContext myxctxt = (XPathContext) xctxt;
> myxctxt.xxx
> }
> }
>
> Of course, this code may not work if we decide in the future to pass
> some other type of ExpressionContext.
>
> Within limits, we can add some methods to the ExpressionContext
> interface which we hope to have standardized eventually by W3C.
>
> HTH,
> Gary