cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitri Plotnikov <dplot...@yahoo.com>
Subject Re: [jxpath] New features, bug fixes and documentation
Date Thu, 11 Apr 2002 17:49:23 GMT
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 <ovidiu@cup.hp.com>
> http://www.geocities.com/SiliconValley/Monitor/7464/
> (GNU, Emacs, other stuff)
> 
> On Wed, 10 Apr 2002 21:18:47 -0500, "Ivelin Ivanov"
> <ivelin@apache.org> 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"
> <subscriptions@plotnix.com>
> > To: <commons-dev@jakarta.apache.org>
> > 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message