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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: >> >> >> >>> +1. sounds good. >>> >>> - James >>> >>> >>> Garrett Rooney wrote: >>> >>> >>> >>>> On Wed, Nov 12, 2008 at 5:20 AM, David Calavera >>>> <[EMAIL PROTECTED]> 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
