abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Calavera" <david.calav...@gmail.com>
Subject Re: Abdera elements, axiom and the pain. AKA ABDERA-194: FOMXPath selectNodes() accepts a Base argument but requires an Axiom object to work properly
Date Mon, 17 Nov 2008 16:40:27 GMT
Well, the ticket is not solved yet because I don't understand the behavior
of the ElementWrapper class. Basically, it stores an Element object and
passes all the invocations to the internal element, it doesn't have any
additional behavior, why do we maintain this class? why don't the extensions
extend directly the FOMElement class instead of the ElementWrapper class?

Can anyone explain me?

Thank you.

On Wed, Nov 12, 2008 at 5:25 PM, James M Snell <jasnell@gmail.com> wrote:

> +1. sounds good.
> - James
> Garrett Rooney wrote:
>> On Wed, Nov 12, 2008 at 5:20 AM, David Calavera
>> <david.calavera@gmail.com> wrote:
>>> Hi, I'm working in this issue
>>> https://issues.apache.org/jira/browse/ABDERA-194, and I'd like to
>>> discuss my
>>> solution because I'm not sure if it's the best one.
>>> The problem was that the classes that extend ElementWrapper don't extend
>>> the
>>> Axiom methods to enable XPath navigation and json serialization.
>>> My solution. Now ElementWrapper extends OMElementImpl but I had to modify
>>> some methods due to getting conflicts with the Axiom api. So, some
>>> methods
>>> in the media extension called "getType" are now called "getMediaType",
>>> and a
>>> method called "getType" in the openSearch extension is now called
>>> "getUrlType".
>>> If nobody disagrees and proposes a better way to solve the bug I'll
>>> commit
>>> my changes tomorrow morning.
>> Seems reasonable enough to me.  The new method names are more clear
>> anyway.
>> -garrett

David Calavera

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message