You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Knut Wannheden <kn...@gmail.com> on 2005/02/10 09:58:04 UTC
Re: [JXPath] unordered node-sets
Dmitri,
Knut Wannheden <knut.wannheden <at> gmail.com> writes:
>
> Dmitri Plotnikov <dmitri <at> apache.org> writes:
>
> > @name is a reserved attribute name for Java Objects. It in fact checks the
> > name of the property/key rather than the value of the property called
> > "name". I think it is equivalent to "[name() = 'Foo']. This feature should
> > be deprecated, and I will try to do so in a future release.
> >
>
> Yes, I think name() is indeed equivalent and IMO preferable as it's more XPath
> style and doesn't keep users from using @name to access an object's property
> "name" (i.e. getName()).
>
> In the JXPath based EMF search tool I've been working on
> (http://emfsearch.sourceforge.net/) I have now customized the JXPath axes as
> I've previously outlined (child:: and thus also descendant:: only for EMF
> containment references). With this customization it is now very difficult to
> write queries which access the getName() method of an object. Instead of
> "[@name = 'Foo']" I have to use something like "[string(@name) = 'Foo']".
>
If found a reasonable workaround for this which might be useful to others. The
equality check can simply be turned around. I.e. "['Foo' = @name]" works fine.
Now I've just got two more questions on this :-) Have you been able to check if
removing DescendantContext#isChildOrderingRequired() breaks anything? Do you
want me to open a feature request for either of these two changes?
Regards,
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [JXPath] unordered node-sets
Posted by Dmitri Plotnikov <dm...@apache.org>.
Knut,
Thank you for the feedback. There is no need to make an "official" feature request. I'll take care of it.
Regards,
- Dmitri
Knut Wannheden <kn...@gmail.com> wrote:
Dmitri,
Knut Wannheden gmail.com> writes:
>
> Dmitri Plotnikov apache.org> writes:
>
> > @name is a reserved attribute name for Java Objects. It in fact checks the
> > name of the property/key rather than the value of the property called
> > "name". I think it is equivalent to "[name() = 'Foo']. This feature should
> > be deprecated, and I will try to do so in a future release.
> >
>
> Yes, I think name() is indeed equivalent and IMO preferable as it's more XPath
> style and doesn't keep users from using @name to access an object's property
> "name" (i.e. getName()).
>
> In the JXPath based EMF search tool I've been working on
> (http://emfsearch.sourceforge.net/) I have now customized the JXPath axes as
> I've previously outlined (child:: and thus also descendant:: only for EMF
> containment references). With this customization it is now very difficult to
> write queries which access the getName() method of an object. Instead of
> "[@name = 'Foo']" I have to use something like "[string(@name) = 'Foo']".
>
If found a reasonable workaround for this which might be useful to others. The
equality check can simply be turned around. I.e. "['Foo' = @name]" works fine.
Now I've just got two more questions on this :-) Have you been able to check if
removing DescendantContext#isChildOrderingRequired() breaks anything? Do you
want me to open a feature request for either of these two changes?
Regards,
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org