[jxpath] Commit notes

[Dmitri Plotnikov <dm...@apache.org>]

JXPath code is becoming more flexible, more readable, more maintainable and
generally more usable.  I believe it is ready for a beta release.  Opinions?


Folks, any help with JXPath will be greatly appreciated: if you are
interested in contributing to the project, please don't hesitate to mention
that.  There's plenty to do.

Great thanks to Ivelin Ivanov who has provided code patches and very useful
advice on how to improve JXPath.


My apologies if the recent changes adversely affected you.

Please note that a few files in JXPath have been moved or renamed:

"functions/Types" became "util/TypeUtils"
"pointers/PropertyAccessHelper" became "util/ValueUtils"
"pointers" became "model" and now has three new subpackages: "beans", "dom"
and "container"

The AbstractFactory interface has been simplified: the "expandCollection"
method is gone.  Expanding a collection is now a job that may need to be
done by the main "createObject" method.

The AbstractFactory can now be used to create DOM nodes (up until now it
only worked on JavaBeans and maps-like objects).  It still cannot be used to
create new attributes - that functionality is coming.

The setValue() method can now be used to change textual contents of DOM
elements and attributes.

NodePointer used to have this method:  "siblingIterator(...)".  That method
is gone.  The "childIterator()" method now has an additional argument:
"NodePointer startWith".  If you need to iterate through siblings of a node,
you will need to get the node's parent, then the parent's childIterator()
and pass to it the child node whose siblings you need.  The reason for this
change is that I originally overlooked the fact that siblings of a
NodePointer may belong to different object models and therefore the pointer
won't know how to handle them. A parent however must know how to handle all
of its children.  A good example of this situation is a map that contains
DOM nodes, JavaBeans etc.  We don't want a DOMNodePointer to know how to
handle siblings that are BeanPointers or vice versa.


Thanks,

- Dmitri Plotnikov
dmitri@apache.org


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [jxpath] Commit notes

[Ivelin Ivanov <iv...@apache.org>]

I've tested JXPath for some untrivial scenarious and believe it's ready for
beta.

JXPath made my job a brieze when I was doing XMLForm - a new Form handling
solution for Cocoon 2, based on XForms.


Keep the good stuff coming.


Ivelin


----- Original Message -----
From: "Dmitri Plotnikov" <dm...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, April 21, 2002 9:42 PM
Subject: [jxpath] Commit notes


> JXPath code is becoming more flexible, more readable, more maintainable
and
> generally more usable.  I believe it is ready for a beta release.
Opinions?
>
>
> Folks, any help with JXPath will be greatly appreciated: if you are
> interested in contributing to the project, please don't hesitate to
mention
> that.  There's plenty to do.
>
> Great thanks to Ivelin Ivanov who has provided code patches and very
useful
> advice on how to improve JXPath.
>
>
> My apologies if the recent changes adversely affected you.
>
> Please note that a few files in JXPath have been moved or renamed:
>
> "functions/Types" became "util/TypeUtils"
> "pointers/PropertyAccessHelper" became "util/ValueUtils"
> "pointers" became "model" and now has three new subpackages: "beans",
"dom"
> and "container"
>
> The AbstractFactory interface has been simplified: the "expandCollection"
> method is gone.  Expanding a collection is now a job that may need to be
> done by the main "createObject" method.
>
> The AbstractFactory can now be used to create DOM nodes (up until now it
> only worked on JavaBeans and maps-like objects).  It still cannot be used
to
> create new attributes - that functionality is coming.
>
> The setValue() method can now be used to change textual contents of DOM
> elements and attributes.
>
> NodePointer used to have this method:  "siblingIterator(...)".  That
method
> is gone.  The "childIterator()" method now has an additional argument:
> "NodePointer startWith".  If you need to iterate through siblings of a
node,
> you will need to get the node's parent, then the parent's childIterator()
> and pass to it the child node whose siblings you need.  The reason for
this
> change is that I originally overlooked the fact that siblings of a
> NodePointer may belong to different object models and therefore the
pointer
> won't know how to handle them. A parent however must know how to handle
all
> of its children.  A good example of this situation is a map that contains
> DOM nodes, JavaBeans etc.  We don't want a DOMNodePointer to know how to
> handle siblings that are BeanPointers or vice versa.
>
>
> Thanks,
>
> - Dmitri Plotnikov
> dmitri@apache.org
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>