You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by David Calavera <da...@gmail.com> on 2008/11/12 11:20:47 UTC
Abdera elements, axiom and the pain. AKA ABDERA-194: FOMXPath selectNodes() accepts a Base argument but requires an Axiom object to work properly
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.
Cheers
Re: Abdera elements, axiom and the pain. AKA ABDERA-194: FOMXPath selectNodes() accepts a Base argument but requires an Axiom object to work properly
Posted by David Calavera <da...@gmail.com>.
forget it, I think I just needed to understand a little bit more the
architecture. I've found a better solution modifying the FOMXPath
implementation without change the core architecture.
On Tue, Nov 18, 2008 at 4:16 PM, James M Snell <ja...@gmail.com> wrote:
> Ah.... in that case yeah... however, the decision to keep Axiom out of the
> core can be revisited if the current design is impacting functionality. I'd
> rather avoid it tho... keeping things separated like they are provides us
> with significant flexibility in the architecture.
>
> - James
>
>
> David Calavera wrote:
>
>> Sooo, my solution is not valid since I've imported axiom into the core and
>> now ElementWrapper extends OMElement to solve the bug. :S
>>
>> On Mon, Nov 17, 2008 at 5:49 PM, James M Snell <ja...@gmail.com> wrote:
>>
>>
>>
>>> The purpose of ElementWrapper was to decouple extension implementations
>>> from the underlying Axiom-based FOM implementation. If we ever decided
>>> to
>>> move away from Axiom, extensions would not, in theory, have to be
>>> reimplemented..... that was the idea anyway.
>>>
>>> - James
>>>
>>>
>>> David Calavera wrote:
>>>
>>>
>>>
>>>> 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 <ja...@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> +1. sounds good.
>>>>>
>>>>> - James
>>>>>
>>>>>
>>>>> Garrett Rooney wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Wed, Nov 12, 2008 at 5:20 AM, David Calavera
>>>>>> <da...@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
http://www.thinkincode.net
Re: Abdera elements, axiom and the pain. AKA ABDERA-194: FOMXPath
selectNodes() accepts a Base argument but requires an Axiom object to work
properly
Posted by James M Snell <ja...@gmail.com>.
Ah.... in that case yeah... however, the decision to keep Axiom out of
the core can be revisited if the current design is impacting
functionality. I'd rather avoid it tho... keeping things separated like
they are provides us with significant flexibility in the architecture.
- James
David Calavera wrote:
> Sooo, my solution is not valid since I've imported axiom into the core and
> now ElementWrapper extends OMElement to solve the bug. :S
>
> On Mon, Nov 17, 2008 at 5:49 PM, James M Snell <ja...@gmail.com> wrote:
>
>
>> The purpose of ElementWrapper was to decouple extension implementations
>> from the underlying Axiom-based FOM implementation. If we ever decided to
>> move away from Axiom, extensions would not, in theory, have to be
>> reimplemented..... that was the idea anyway.
>>
>> - James
>>
>>
>> David Calavera wrote:
>>
>>
>>> 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 <ja...@gmail.com> wrote:
>>>
>>>
>>>
>>>
>>>> +1. sounds good.
>>>>
>>>> - James
>>>>
>>>>
>>>> Garrett Rooney wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> On Wed, Nov 12, 2008 at 5:20 AM, David Calavera
>>>>> <da...@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
>
Re: Abdera elements, axiom and the pain. AKA ABDERA-194: FOMXPath selectNodes() accepts a Base argument but requires an Axiom object to work properly
Posted by David Calavera <da...@gmail.com>.
Sooo, my solution is not valid since I've imported axiom into the core and
now ElementWrapper extends OMElement to solve the bug. :S
On Mon, Nov 17, 2008 at 5:49 PM, James M Snell <ja...@gmail.com> wrote:
> The purpose of ElementWrapper was to decouple extension implementations
> from the underlying Axiom-based FOM implementation. If we ever decided to
> move away from Axiom, extensions would not, in theory, have to be
> reimplemented..... that was the idea anyway.
>
> - James
>
>
> David Calavera wrote:
>
>> 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 <ja...@gmail.com> wrote:
>>
>>
>>
>>> +1. sounds good.
>>>
>>> - James
>>>
>>>
>>> Garrett Rooney wrote:
>>>
>>>
>>>
>>>> On Wed, Nov 12, 2008 at 5:20 AM, David Calavera
>>>> <da...@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
http://www.thinkincode.net
Re: Abdera elements, axiom and the pain. AKA ABDERA-194: FOMXPath
selectNodes() accepts a Base argument but requires an Axiom object to work
properly
Posted by James M Snell <ja...@gmail.com>.
The purpose of ElementWrapper was to decouple extension implementations
from the underlying Axiom-based FOM implementation. If we ever decided
to move away from Axiom, extensions would not, in theory, have to be
reimplemented..... that was the idea anyway.
- James
David Calavera wrote:
> 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 <ja...@gmail.com> wrote:
>
>
>> +1. sounds good.
>>
>> - James
>>
>>
>> Garrett Rooney wrote:
>>
>>
>>> On Wed, Nov 12, 2008 at 5:20 AM, David Calavera
>>> <da...@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
>>>
>>>
>>>
>>>
>
>
>
Re: Abdera elements, axiom and the pain. AKA ABDERA-194: FOMXPath selectNodes() accepts a Base argument but requires an Axiom object to work properly
Posted by David Calavera <da...@gmail.com>.
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 <ja...@gmail.com> wrote:
> +1. sounds good.
>
> - James
>
>
> Garrett Rooney wrote:
>
>> On Wed, Nov 12, 2008 at 5:20 AM, David Calavera
>> <da...@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
http://www.thinkincode.net
Re: Abdera elements, axiom and the pain. AKA ABDERA-194: FOMXPath
selectNodes() accepts a Base argument but requires an Axiom object to work
properly
Posted by James M Snell <ja...@gmail.com>.
+1. sounds good.
- James
Garrett Rooney wrote:
> On Wed, Nov 12, 2008 at 5:20 AM, David Calavera
> <da...@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
>
>
Re: Abdera elements, axiom and the pain. AKA ABDERA-194: FOMXPath selectNodes() accepts a Base argument but requires an Axiom object to work properly
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Nov 12, 2008 at 5:20 AM, David Calavera
<da...@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