Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-Id: <200204111721.g3BHLqn09962@orion.rgv.hp.com>
From: Ovidiu Predescu <ovidiu@cup.hp.com>
To: Dmitri Plotnikov <subscriptions@plotnix.com>
Cc: "Ivelin Ivanov" <ivelin@apache.org>, cocoon-dev@xml.apache.org
Subject: Re: [jxpath] New features, bug fixes and documentation 
In-Reply-To: Your message of "Wed, 10 Apr 2002 21:18:47 CDT."
             <00cf01c1e0ff$3708f220$0c91fea9@galina>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 11 Apr 2002 10:21:51 -0700
Sender: ovidiu@orion.rgv.hp.com

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

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