Hello James,
<snip>
>Yes I think returning the Element when adding text or entities sounds a good
>idea.
>Though the addElement() returns the new Element child rather than the parent
>so care should be taken with nestings.
Ah - this is not what I'd been thinking of. So
foo.addEntity ("bar"); // returns foo
foo.addElement ("bar"); // returns ref to the new bar Element ?? I'd
expected it to return foo.
If you return foo in all cases, you can chain addAttribute, addElement etc.
freely together. As per the example with complexType, you can bracket the
calls to make sure you get the right tree:
For reference, my example again:
<checks mail, finds message was misdirected, tears hair and resends message>
<Aha, that explains the miscommunication - my apologies. >
Element complexType = new DefaultElement ("complexType") . add (new
DefaultAttribute ("mixed", "true"))
.add (new DefaultElement ("sequence")
.add ((new DefaultElement ("element") . add (new
DefaultAttribute ("ref", "xyz")))));
>E.g. if you wished to add mixed content to a <foo> element you could do the
>following, notice the use of the "getParent()" call to continue adding
>content to the "foo" element.
I prefer the above approach to your getParent() stuff, because I don't need
to wrap everything in try {...} catch (NullPointerException(...) {...}
blocks. It also allows the same behaviour for all addXYZ() methods.
What do you think?
>Element foo = ..;
>foo.addText( "some text " ).addElement( "b" ).addText( "this is
>bold" ).getParent().addText( " some text " ).addElement( "i" ).addText(
>"this is italic" ).getParent().addText( " more text ");
>
>This would generate the XML fragment
>
><foo>some text <b>this is bold</b> some text <i>this is italic</i> more text
></foo>
>
>If the getParent() is not used then nesting would occur...
>
><foo>some text <b>this is bold some text <i>this is italic more text
></i></b></foo>
>
>
> > >Element foo = ...;
> > >foo.addText( "hello" ).addCDATA( "< > &" ).addEntity( "amp" );
> > >
> > >What do you think of the idea of setAttributeValue() returning a
>reference
> > >to the element so that they could be nested too?
> > >
> > >Element foo = ...;
> > >foo.setAttributeValue( "amount", "10" ).setAttributeValue( "currency",
> > >"GBP" );
> >
> > Sounds useful, I'd suggest it applies to all setXXX methods? Unless you
>can
> > see a reason for not keeping it consistent?
>
>Agreed. Will do.
>
> >
> > > > Only addEntity() seems non-orthogonal - this takes a String and
>returns
> > > > _Entity_, a reference to the Entity object just created.
> > >
> > >Agreed. I think that addEntity() should return a reference to the
>Element.
> >
> > Great. Could break existing code, but simple enough to fix.
>
>Unless I hear any major complaints I'll go this route shortly, for the 0.5
>release this week.
>
>
> > >Maybe a helper method might help here. Consider the following:-
> > >
> > >String xmlFragment = "<complexType mixed = 'true'> <sequence> <element
> > >ref='xyz' /> </sequence> </complexType>";
> > >Document document = DocumentHelper.parseText( xmlFragment )
> > >
> > >Then if you wanted to use the <complexType> element in some other
>document
> > >the following code could be used...
> > >
> > >String xmlFragment = "<complexType mixed = 'true'> <sequence> <element
> > >ref='xyz' /> </sequence> </complexType>";
> > >Document document = DocumentHelper.parseText( xmlFragment )
> > >Element complexType = document.getRootElement();
> > >complexType.detach();
> > >someOtherElement.add( complexType );
> >
> > Lovely - the getRootElement() of a newly created doc is what I hadn't
> > thought of. Would the fragment be created in NO_NAMESPACE, so that when
>you
> > add it to someOtherElement it inherits someOtherElement's namespace?
>
>It would keep the same namespace thats declared in the XML text. If you
>wanted to inherit the namespace from a different document then you could do
>the following:-
>
>Document document = DocumentHelper.parseText( xmlFragment );
>Element complexType = document.getRootElement();
>
>Element destination = ...;
>QName qname = QName.get( "complexType", destination.getNamespace() );
>Element newElement = someOtherElement.addElement( "complexType" );
>newElement.appendAttributes( complexType );
>newElement.appendContent( complexType );
>
>Which will create a new element "complexType" in the same namespace as the
>parent element.
Splendid.
> > >I've added the DocumentHelper.parseText( xmlText ) helper method to the
> > >current CVS image along with a JUnit test case to ensure it works
> > >(org.dom4j.TestParseText). So you could try using the current CVS image
>or a
> > >daily build and see if this new method helps. (It is a pretty trivial
>helper
> > >method though).
> >
> > Thanks very much. I'm trying to avoid CVS access at present (need to
>either
> > use WinCVS in Unix-mode, or get Linux ISDN and proxy servers working) so
> > I'll grab a snapshot in the next couple of days.
>
>Cool. The daily build has all of these changes now. The 0.5 release should
>be later this week.
>
>James
Thanks again,
Thomas.
_______________________________________________
dom4j-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-dev
