[jdom-interest] Is JDOM dying?

[Malachi de AElfweald]

Hmmm. Interesting... slight modification:


public static void addContent(Element parentElem, Element childElem)
{
	// your code from below
	parentElem.addContent(newChildElem);
}

then, you could:

	addContent(outsideElem, insideElem);

wonder how it would do on timing...

Mal

On Fri, 14 Mar 2003 12:33:33 -0500, Rolf Lear <rlear at algorithmics.com> 
wrote:

> How about the following:
>
>
> element.addContent(changeNamespace(subelement, element.getNamespace());
>
> where changeNamespace is defined as follows:
>
> private static Element changeNamespace(Element emt, Namespace to) {
> return changeNamespace(emt, emt.getNamespace(), to);
> }
>
> private static Element changeNamespace(Element emt, Namespace from,
> Namespace to) {
> Namespace ns = emt.getNamespace();
>
> if (!ns.equals(from)) return emt;
>
> /* Uncomment to change attribute namespaces....
> for (Iterator ait = emt.getAttributes().iterator(); ait.hasNext();)
> {
> Attribute att = (Attribute)ait.next();
> if (att.getNamespace().equals(from) &&
> !att.getNamespace().equals(to)) {
> att.setNamespace(to);
> System.out.println(att.getName());
> }
> }
> */
> if (!ns.equals(to)) {
> emt.setNamespace(to);
> }
> for (Iterator it = emt.getChildren().iterator(); it.hasNext();) {
> changeNamespace((Element)it.next(), from, to);
> }
> return emt
> }
>
>
> This changes the namespace for the supplied element and all it's children
> with the same namespace.
>
> Rolf
>
> -----Original Message-----
> From: Stephan Trebels [mailto:stephan at ncube.de]
> Sent: Friday, March 14, 2003 11:20 AM
> To: Elliotte Rusty Harold
> Cc: Stephan Trebels; JDOM
> Subject: Re: [jdom-interest] Is JDOM dying?
>
>
> Here I am as advocatus diaboli even though I'm nearly sure I'd never use
> it myself ;-/  But alas, this is a technical discussion not a religious
> war - I hope.
>
>
> disclaimer:
> I'm sure, that normally it makes more sense to use an explicit
> namespace in all Elements.  This is definitely true for all my work
> areas where mutable Elements would be a nightmare.  This is not in
> question.
>
>
> But we have to face, that some people want to use Elements differently.
> So I'd ask whether it is possible to make everyone happy without
> sacrificing anything essential.
>
> In my compromise not a single line of code using JDOM anyone had have
> written would be invalidated or behave any different.  The namespace set
> by new Element(String) should not be changed - that should definitely be
> rejected.
>
> The only added feature would be, that you CAN use a special Namespace
> constant for different _output_ behaviour.  The only code changes would
> have to be in the outputters.
>
>
> So I ask you: Why/How would this make the API any uglier?  The API isn't
> changed a bit.  The only way to get the changed behaviour would be to
> use a static constant in the Namespace class, which can be documented
> "for special applications, only". It shouldn't even be documented in a
> user's guide (this would be something for a special addendum in the
> reference).
>
>
> My personal opinion about an API is, that it should be easy to use and
> easy to learn, agreed.  Not all tasks need to be available in the
> entry-level API, but ultimately all possible tasks should be made as
> easy as possible.
>
> Stephan
>
> On Fri, 2003-03-14 at 13:46, Elliotte Rusty Harold wrote:
>> At 8:56 AM +0100 3/14/03, Stephan Trebels wrote:
>> >Would it be a workable compromise  to have a Namespace.INHERIT for an
>> >Element as a possible namespace argument?
>>
>> I wouldn't accept such a compromise. It's ugly. Right now the JDOM 
>> namespace story is clean and consistent. This proposal says it changes 
>> depending on whether or not you set Namespace.INHERIT. Too many options 
>> just create a baroque API that's hard to learn, hard to teach, and hard 
>> to use. Generally when faced with two possible ways of accomplishing 
>> something, it's better to pick one than to pick both.



--