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 david.calavera@gmail.com
 designates 209.85.132.250 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=RtHoOYroKSsYz7pURbOCktwkSMT6exA/f33vrdj2KDfo43ibz4/hHVTUGw7CRdde04
         o0+f6Q/PIkzzY9RPR4215B5aYgefZBsSIdfbp1MwHuGMP0+LG6wSKXKWZsrfw9a0OVrl
         z1pRN5lZV5ul2/9uAPk+pJ0JOeWat637wyG3o=
Message-ID: <baf7e05c0811181442y3ca2a4a0oafc818e06f424ccd@mail.gmail.com>
Date: Tue, 18 Nov 2008 23:42:22 +0100
From: "David Calavera" <david.calavera@gmail.com>
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
In-Reply-To: <4922DC34.6090801@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_74342_19297186.1227048142801"
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>
	 <4922DC34.6090801@gmail.com>

------=_Part_74342_19297186.1227048142801
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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


-- 
David Calavera
http://www.thinkincode.net

------=_Part_74342_19297186.1227048142801--