> Jaxen currently takes a lazy approach to resolving namespace prefixes to
> URIs. I see some usability aspects this provides (e.g. being able to use
> the "addNamespace" methods on an already created XPath), but I also see
> that this resolution gets done over and over again with the evaluation
> of each name test or namespace test in an XPath or Pattern. This seems
> rather wasteful, doesn't it? Has there been any discussion of
> refactoring this, or is the team pretty firmly wedded to keeping things
> as they are?
I'm all for optimization and refactoring. If it's major, float the
idea here first. If it's little refactorings here and there, then
just go ahead and do what you think is right. I review the CVS
commits and can always back out changes.
> In particular, I am looking at the pattern classes, right now, which are
> not currently usable. I've been tinkering with the code to see what it
> would take to clean this up and make it genuinely usable (it's not far
> off), and I started thinking about the above-mentioned refactoring. It
> seems like it would be much easier (with much less impact) to introduce
> this change just for the pattern classes and not try to do it for all of
> Jaxen. After all, the Pattern class doesn't currently have the same
> "addNamespace" or "setNamespaceContext" convenience methods. I'm
> thinking, just change it to get its Context from the PatternParser at
> instantiation time.
The pattern stuff is entirely the work of James Strachan ([EMAIL PROTECTED])
and is currently used inside of dom4j, I think. So, if you do manipulate
things in there, please remember to build dom4j also as a test case.
> Thoughts? I'm working with this code right now, so I'd be willing to do
> the work if the team agrees with the proposal.
Let's see what James has to say. I'm ingorant on the pattern package,
to be honest.
-bob
-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
_______________________________________________
Jaxen-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jaxen-interest
