You are viewing a plain text version of this content. The canonical link for it is here.
Posted to woden-dev@ws.apache.org by Oshani Seneviratne <os...@gmail.com> on 2006/08/13 17:17:32 UTC
ElementSource and DOM/OMUtils (WAS Re: WODEN-44, ElementSource)
Hi John and all,
I started work on the ElementSource again, and this time there's no
ElementUtils (i.e. the class with static methods to access element
info)!
Instead, I introduced several methods to the ElementSource interface,
and implemented them in DOM/OMElementSource classes to access element
specific info, as was in the original proposal.
These are those methods:
getQName(String prefixedValue)
getAttribute(String attributeName)
getAttributes()
getFirstChildElement()
As far as I can see, these are the only requirements for the moment.
But please advice should there be more.
However I also have several concerns over the role of DOM/OMUtils with
the introduction of ElementSource:
1. From what I understand, the intent of DOM /OMUtils classes is also
to access the element info items to a certain degree. So, should the
DOM/OMElementSource act as a replacement for those classes?
2. There are some methods which do much more than accessing element
info in DOMUtils. For example, the method
DOMUtils.getQName(String,Element,DescriptionElement) which is used in
some of the *Deserializer classes, registers the ns prefix in the
DescriptionElement if it's not found in the Namespaces map. IMO, it is
not right to introduce such a method to the ElementSource interface,
as it would seem to do more than what is required by an element
wrapper.
So, would it be okay to forget about registering the namespace and use
something like elementSource.getQName(prefix) instead?
If the answers to the above questions are yes & yes, and if nobody
else has worked on this, I guess I can commit the code that I've been
working on :).
Thanks and Regards,
Oshani.
On 8/1/06, Oshani Seneviratne <os...@gmail.com> wrote:
> Hi John,
>
> The patch for ElementSource implementation is attached at
>
> http://issues.apache.org/jira/secure/attachment/12337885/woden-44.patch
>
> This patch includes the implementation of the ElementSource and it's
> related classes in the WODEN-44 branch. With this, I have removed all
> the DOM dependencies in XMLAttr, ExtensionDeserializer, etc, etc..,
> In those classes, the relevant method signatures are changed to take
> in Objects instead of org.w3c.dom.Elements. If a particular attribute
> in this DOM/OM element wrapped in ElementSource is required, the
> static methods in the 'ElementUtils' is used.
>
> The class ElementUtils, acts as a switch for DOM/OMUtils. However
> there is no inheritance mechanism here. It is used as an alternative
> to DOMUtils which was there to get any attribute specific information
> from the elements. There is a possiblity to remove these static method
> references, and have the two util classes extend from ElementUtils
> later.
>
> Also QNameUtils is refactored to avoid possible confusion with the
> same class name in the two o.a.w.i.util.dom/om packages.
>
>
> Regards,
> Oshani
>
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: ElementSource and DOM/OMUtils (WAS Re: WODEN-44, ElementSource)
Posted by Jeremy Hughes <hu...@apache.org>.
That's weird. I didn't see a commit email
On 8/17/06, Oshani Seneviratne <os...@gmail.com> wrote:
> Hi John,
>
> >
> > I will give this more thought when I look at your code. I assume it's in
> > the WODEN-44 branch?
> >
>
> I just committed the code. You'll be able to find it in the WODEN-44 branch now.
>
> Thanks,
> Oshani
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: ElementSource and DOM/OMUtils (WAS Re: WODEN-44, ElementSource)
Posted by Oshani Seneviratne <os...@gmail.com>.
Hi John,
>
> I will give this more thought when I look at your code. I assume it's in
> the WODEN-44 branch?
>
I just committed the code. You'll be able to find it in the WODEN-44 branch now.
Thanks,
Oshani
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: ElementSource and DOM/OMUtils (WAS Re: WODEN-44, ElementSource)
Posted by John Kaputin <KA...@uk.ibm.com>.
Hi Oshani,
I'm just back from leave today so will look at your code over the next day
or two, but your additions to ElementSource sound good. Thanks.
ElementSource is a wrapper for an element object from some underlying XML
model - currently DOM or Axiom. Per my initial proposal it should have a
method that returns this wrapped element object as a java.lang.Object which
the caller can then cast to a DOM Element or Axiom OMElement. To make
ElementSource more useful (i.e. to minimize the need to cast an Object) you
have added methods which reflect common element behaviour that can be
easily delegated by DOMElementSource to the wrapped org.w3c.dom.Element
object or by OMElementSource to the wrapped OMElement.
I'm not sure about completely refactoring DOMUtils into DOMElementSource
(likewise for OMUtils and OMElementSource). Previously we used the
org.w3c.dom.Element API to get information from a DOM element and we used
DOMUtils to do other things with the DOM API, like navigating the DOM tree
to dereference a prefix to a namespace. I assume now we will simply use the
ElementSource API to get information from the underlying DOM element and
still use DOMUtils for other DOM based tasks. I guess the requirement
driving your suggestion is the refactoring of the parsing behaviour into
BaseWSDLReader (i.e. eliminating the dependencies in the the parseXXX
methods on DOMUtils and OMUtils).
I will give this more thought when I look at your code. I assume it's in
the WODEN-44 branch?
regards,
John Kaputin
"Oshani
Seneviratne"
<oshanis@gmail.co To
m> woden-dev@ws.apache.org
cc
13/08/2006 16:17
Subject
ElementSource and DOM/OMUtils (WAS
Please respond to Re: WODEN-44, ElementSource)
woden-dev@ws.apac
he.org
Hi John and all,
I started work on the ElementSource again, and this time there's no
ElementUtils (i.e. the class with static methods to access element
info)!
Instead, I introduced several methods to the ElementSource interface,
and implemented them in DOM/OMElementSource classes to access element
specific info, as was in the original proposal.
These are those methods:
getQName(String prefixedValue)
getAttribute(String attributeName)
getAttributes()
getFirstChildElement()
As far as I can see, these are the only requirements for the moment.
But please advice should there be more.
However I also have several concerns over the role of DOM/OMUtils with
the introduction of ElementSource:
1. From what I understand, the intent of DOM /OMUtils classes is also
to access the element info items to a certain degree. So, should the
DOM/OMElementSource act as a replacement for those classes?
2. There are some methods which do much more than accessing element
info in DOMUtils. For example, the method
DOMUtils.getQName(String,Element,DescriptionElement) which is used in
some of the *Deserializer classes, registers the ns prefix in the
DescriptionElement if it's not found in the Namespaces map. IMO, it is
not right to introduce such a method to the ElementSource interface,
as it would seem to do more than what is required by an element
wrapper.
So, would it be okay to forget about registering the namespace and use
something like elementSource.getQName(prefix) instead?
If the answers to the above questions are yes & yes, and if nobody
else has worked on this, I guess I can commit the code that I've been
working on :).
Thanks and Regards,
Oshani.
On 8/1/06, Oshani Seneviratne <os...@gmail.com> wrote:
> Hi John,
>
> The patch for ElementSource implementation is attached at
>
> http://issues.apache.org/jira/secure/attachment/12337885/woden-44.patch
>
> This patch includes the implementation of the ElementSource and it's
> related classes in the WODEN-44 branch. With this, I have removed all
> the DOM dependencies in XMLAttr, ExtensionDeserializer, etc, etc..,
> In those classes, the relevant method signatures are changed to take
> in Objects instead of org.w3c.dom.Elements. If a particular attribute
> in this DOM/OM element wrapped in ElementSource is required, the
> static methods in the 'ElementUtils' is used.
>
> The class ElementUtils, acts as a switch for DOM/OMUtils. However
> there is no inheritance mechanism here. It is used as an alternative
> to DOMUtils which was there to get any attribute specific information
> from the elements. There is a possiblity to remove these static method
> references, and have the two util classes extend from ElementUtils
> later.
>
> Also QNameUtils is refactored to avoid possible confusion with the
> same class name in the two o.a.w.i.util.dom/om packages.
>
>
> Regards,
> Oshani
>
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org