Mailing-List: contact abdera-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: abdera-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jasnell@gmail.com designates
 209.85.200.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=muS3+oLLBS+QWJennopn+vH9DuI7Ct36J/TJ24NI2T3Q1Q9GJP0PB7YU0eztAm+Jh0
         a4M7qTh0kczYVejjCpiuR5L4VXhOHwXFCAfzw0+HnFb4MVVtn1AcfKZVDkn1VbohiHf+
         sE78SfC+xEDTvEu6DPu4fKwxP0wUEvopNSkFY=
Message-ID: <4922DC34.6090801@gmail.com>
Date: Tue, 18 Nov 2008 07:16:04 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.17 (X11/20080925)
MIME-Version: 1.0
To: abdera-dev@incubator.apache.org
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
References: <baf7e05c0811120220r766e3643yf18b9f749ea65b0e@mail.gmail.com>
	 <4585c4a60811120710w7ad19a03j53791bf303e33e35@mail.gmail.com>
	 <491B035D.7060005@gmail.com>
	 <baf7e05c0811170840o14104ce9n1e44e1cf8a4f5e52@mail.gmail.com>
	 <4921A08A.2040800@gmail.com>
 <baf7e05c0811180139qb5c800brc4c35a2e1282716b@mail.gmail.com>
In-Reply-To: <baf7e05c0811180139qb5c800brc4c35a2e1282716b@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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