Ovidiu,
> Very good stuff, Dmitri!
Thank you.
> I'm using your excellent JXPath library in my
> jpath.xsl XSP
> logicsheet, in conjunction with the
> continuations-based control flow
> layer.
Wonderful. Have you had any problems with JXPath?
Please let me know - I'd like to weed out as many
issues as possible before the release.
> I've got a small suggestion for an optimization, if
> you don't mind. In
> the implementation I have, 0.1-dev from Jakarta's
> CVS, I noticed
> there's no way to compile an XPath, before using it.
> Having a way to
> compile the XPaths to be used later, would
> considerably improve the
> performance in repeated operations.
>
> E.g. right now you have something like this:
>
> Object bean = ...;
> JPathContext context =
> JPathContext.newContext(bean);
> context.getValue("some XPath");
>
> I'd like to also have the ability to do:
>
> Object bean = ...;
> JPathContext context =
> JPathContext.newContext(bean);
> XPathObject xpath = new XPathObject("some XPath");
> context.getValue(xpath);
>
> With this approach, I can setup a dictionary of
> already compiled XPath
> expressions, and use compiled XPaths, instead of
> having Xalan
> interpret the XPath all the time.
>
> Last time I checked, Xalan did have the ability to
> precompile XPaths
> in its internal format, so maybe this is easy to
> achieve.
Actually JXPath is already doing something like that
transparently to you. It maintains a static soft cache
of parse trees (which are that internal representation
you are talking about). The reason I am using soft
cache as opposed to a regular map is that some
applications will generate XPaths dynamically, in
which case the size of the cache has a chance of going
through the roof. The soft cache is cleared by
garbage collector, which removes the possibility of
running out of memory.
I have been thinking about improving that mechanism a
little bit. I now want to have a regular map of a
limited size in addition to the soft cache.
Everything that spills over the hard cache will still
be stored in the soft cache. I think that will cover
the 90% case.
Thank you very much for the suggestion.
Regards,
- Dmitri
>
> Best regards,
> --
> Ovidiu Predescu <[EMAIL PROTECTED]>
> http://www.geocities.com/SiliconValley/Monitor/7464/
> (GNU, Emacs, other stuff)
>
> On Wed, 10 Apr 2002 21:18:47 -0500, "Ivelin Ivanov"
> <[EMAIL PROTECTED]> wrote:
>
> >
> > "Ask and you shall receive"
> >
> > Dmitri makes us another great present with the new
> JXPath.
> > Some of the features are just what I needed to
> make form handling more
> > transparent.
> >
> > Enjoy,
> >
> > Ivelin
> >
> >
> > ----- Original Message -----
> > From: "Dmitri Plotnikov"
> <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, April 10, 2002 8:06 AM
> > Subject: [jxpath] New features, bug fixes and
> documentation
> >
> >
> > > In preparation for its first release, JXPath is
> undergoing some clean-up.
> > >
> > > There is now documentation: a tutorial, which is
> included with the binary
> > > distribution. It is in the CVS repository, but
> not yet accessible via the
> > > Jakarta website - read it at
> > >
> > >
> http://www.plotnix.com/jxpath/docs/users-guide.html
> > >
> > >
> > > I have committed several bug fixes and added
> some new features.
> > >
> > > JXPath can now create objects! You just provide
> an implementation of the
> > > AbstractFactory interface and call
> createPath(path, value) on
> > JXPathContext.
> > > It will behave the same way as setValue, except
> it will call the factory
> > as
> > > needed. An interesting idea would be to write
> one of those factories that
> > > would take Struts mapping configuration and
> create form beans as needed.
> > >
> > > Support for diversity object models is now
> complete with the introduction
> > of
> > > NodePointerFactory. We can now have modules
> that support DynaBeans, JDOM
> > > etc. In fact, I plan to write some of them in
> the near future. JDOM
> > sounds
> > > like the most interesting alternative to DOM to
> work with.
> > >
> > > There is a minor type conversion change: JXPath
> will now cast a
> > > single-element array or collection to its first
> element. This feature can
> > > be used for instance with HttpRequest
> parameters. How do you know if a
> > > parameter is a singular or a collection? Now
> you don't need to - extract
> > it
> > > as a collection, give the collection to JXPath,
> it will convert the type
> > if
> > > needed.
> > >
> > > There are two incompatible changes, both having
> to do with extension
> > > functions. First of all, the API of Function
> changed (there is now an
> > > additional argument, ExpressionContext).
> Second, the behavior of
> > > ExpressionContext has changed. It now behaves
> properly. I hope these
> > > changes don't break anybody's builds. If they
> do, I apologize in advance.
> > >
> > > One of the fixes improves an optimization, which
> up until now was just
> > > there, not actually optimizing anything.
> > >
> > > Behavior of getContextNodePointer has been fixed
> - it used to be
> > destructive
> > > in some cases.
> > >
> > > There are many other minor fixes.
> > >
> > > JXPath is getting ready for its first official
> release!
> > >
> > >
> > > - Dmitri Plotnikov
> > > PLOTNIX, Inc
> > >
> > >
> > >
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
