You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ovidiu Predescu <ov...@cup.hp.com> on 2002/04/11 19:21:51 UTC

Re: [jxpath] New features, bug fixes and documentation

Very good stuff, Dmitri!

I'm using your excellent JXPath library in my jpath.xsl XSP
logicsheet, in conjunction with the continuations-based control flow
layer.

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.

Best regards,
-- 
Ovidiu Predescu <ov...@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" <iv...@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" <su...@plotnix.com>
> To: <co...@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
> >
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: [jxpath] New features, bug fixes and documentation

Posted by Ivelin Ivanov <iv...@apache.org>.
Ovidiu,

Is it possible that you're looking for JXPath's XPointer?

Pointer pointer = jxcontext_.locateValue( xpath );
// cache the pointer in a hashmap or something
// go do things
// when you come back
pointer.setValue( value );

It's very useful for session scope beans.


----- Original Message -----
From: "Dmitri Plotnikov" <dp...@yahoo.com>
To: "Ovidiu Predescu" <ov...@cup.hp.com>; "Dmitri Plotnikov"
<su...@plotnix.com>
Cc: "Ivelin Ivanov" <iv...@apache.org>; <co...@xml.apache.org>
Sent: Thursday, April 11, 2002 12:49 PM
Subject: Re: [jxpath] New features, bug fixes and documentation


> 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 <ov...@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"
> > <iv...@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"
> > <su...@plotnix.com>
> > > To: <co...@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


Re: [jxpath] New features, bug fixes and documentation

Posted by Dmitri Plotnikov <dp...@yahoo.com>.
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 <ov...@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"
> <iv...@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"
> <su...@plotnix.com>
> > To: <co...@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


Re: [jxpath] New features, bug fixes and documentation

Posted by Torsten Curdt <tc...@dff.st>.
On Thu, 11 Apr 2002, Ovidiu Predescu wrote:

> Very good stuff, Dmitri!

Second that!

> 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);

This would be indeed very cool!

I hope there will be an official site for it soon!!
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org