Venkat Reddy wrote:
If no more objections are raised, lets conclude the discussion with
following decisions:
1. Shift Child API from OMElement to OMContainer.
2. OMElement extends OMContainer
3. OMDocument implements OMContainer
implements? OMDocument is not an interface?
alek
4. Resolve Axis2 - 22 after these changes are made.
OM'ers, if this is OK with you, Jaya will go ahead and make the
changes, and close the task of integrating Infoset support.
- venkat
On 6/24/05, Venkat Reddy <[EMAIL PROTECTED]> wrote:
hmm... my assumption is that OMElementImpl will implement both
OMContainer and OMElement, but not OMElement extending OMContainer. If
OMElement extends OMContainer, then it is OK - no problem.
On 6/24/05, Venkat Reddy <[EMAIL PROTECTED]> wrote:
For example, userguide.clients.ClientUtil.getEchoOMElement() uses the
following syntax to build the message.
OMFactory fac = OMAbstractFactory.getOMFactory();
OMNamespace omNs =
fac.createOMNamespace("http://example1.org/example1", "example1");
OMElement method = fac.createOMElement("echo", omNs);
OMElement value = fac.createOMElement("Text", omNs);
value.addChild(fac.createText(value, "Axis2 Echo String "));
method.addChild(value);
If the addChild method is moved from OMElement to OMContainer, this
syntax doesn't work. OMContainer will replace OMElement all over the
client programming. The other not-so-good alternative is to typecast
OMElement to OMElementImpl and then call addChild, because
OMElementImpl implements OMContainer.
- venkat
On 6/24/05, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
On Fri, 2005-06-24 at 13:03 +0530, Venkat Reddy wrote:
Alek,
Like i said in the earlier thread on the same subject, there are
couple of issues if we move the child API from OMElement to a seperate
interface. The excerpt from my old mail:
"The client API currently uses OMElement.addChild() to build the
message. Even if
we try to use setParent() instead of addChild() here, the user has to
typecast the OMElement into OMElementImpl and pass it to setParent,
which is not elegant."
Do have any ideas to resolve this? Until we get new ideas, here is my
+1 for OMDocument extends OMElement.
Maybe I didn't understand it (I didn't follow the previous thread
carefully) but if there's an OmContainer interface containing
addChild(), getChild() etc. etc., then if
interface OmElement extends OmContainer
interface OmDocument extends OmContainer
etc. then I'm not clear why one needs to do a cast. Can you expand
please Venkat?
Sanjiva.
--
The best way to predict the future is to invent it - Alan Kay