Thank you, this is very helpful.
David Bertoni wrote:
>
> Moddy Te'eni wrote:
>> Thank you very much for your patience.
>>
>> I'll try to be more thorough this time.
>>
>> I want to give my users the ability to write XPath expressions that refer
>> to
>> some XML input. There is no XSLT involved, just displaying the results.
>>
>> The user should be abe to use some pre-defined variables: some are
>> global,
>> and some depend on the document meta-data and on other things that i am
>> able
>> to calculate. For example, i want to user to write "/pers...@name ==
>> $USERNAME]/@password".
>>
>> My plan is to use XPathEvaluator::evaluate(), but before calling it I
>> want
>> to change the context node so that $USERNAME will be meaningful. Reading
>> xpath documentaion in w3c, i thought there would be some obvious way to
>> do
>> such things.
> How variables are bound is not specified in the XPath recommendation,
> since it's specific to the environment in which XPath is implemented.
>
>
It was wishful thinking - that a generic xpath library will have an obvious
way to tell it what the variables are.
David Bertoni wrote:
>
>
>> At first I thought I can overcome it by changing the syntax a little and
>> introducing a function, e.g.
>>
>> "/pers...@name == env.getValue("USERNAME")]/@password"
>>
>> But I realized that I can't write this function - my code should be
>> thread-safe, and each thread may have different users, so there is no way
>> I
>> can find the user name, short of using Thread-Local Storage.
> I'm afraid I don't understand this. Each thread of execution will need
> its own instance of XPathEvaluator, so you can extend the classes used
> by XPathEvaluator to define the correct variable bindings.
>
>
You understood very well: If I write an extension function, i need to
implement execute(). The arguments of execute() don't have any way to put
specific information that i need - e.g. in which thread i am. The only way
to pass it is in the XpathExecutionContext, but i can't control it Unless I
change XPathEvaluator.
David Bertoni wrote:
>
>
> You could derive a class from XPathExecutionContextDefault and override
> getVariable() to handle the specific variables you're interested in
> resolving. If you get a request for a variable that you don't know
> about, you can defer to the base class implementation.
>
> Unfortunately, XPathEvaluator is not really meant to be extensible, but
> we would enhance it for the purposes of extending the execution
> environment. My recommendation right now would be for you to simply
> copy the XPathEvaluator code and create your derivative of
> XPathExecutionContextDefault.
>
>
The change in my own version of XPathEvaluator should be as simple as
changing the constractor, isn't it?
David Bertoni wrote:
>
>
> I hope this makes sense, and please reply back if you have more questions.
>
>>
>> Another way is, I think, to add things to the DOM instead of variables.
>> then
>> the user may write
>>
>> "/pers...@name == /envValues/@USERNAME)]/@password"
>>
>> This is ugly, though. So I still hope I can avoid it.
> Yes, that would be ugly, and would require a unique copy of the source
> tree for each user.
>
> Dave
>
>
Thanks again, Moddy.
--
View this message in context:
http://www.nabble.com/creating-variables-for-XPath-tp21823462p22175054.html
Sent from the Xalan - C - Users mailing list archive at Nabble.com.
