[jdom-interest] Thoughts on...
Gary Bentley
gb at opengroup.org
Fri Mar 16 03:15:36 PST 2001
What a minute...I thought we are writing Java not C or C++ where forcing the
complier to place a value into another context is prevalent...and quite
acceptable...
Adding "" + to the front of all my values is adding a level of obfuscation
that I don't want and that shouldn't be encouraged.
I can't believe that people can't see the usefulness behind this...the
discussions so far seem to be very centered on a visual inspection of the
data.
I would even go as far as saying that Element really should only allow the
operations below and that the XMLOutputter should then convert the value to
a string since it's only then that it's relevant for it to become
"readable". When a document is then read in, it is up to the application to
determine what base types it wants to use, i.e. the reader would read
everything in as a String and the application would perform any conversions.
Consider, a Document is designed to be a Java representation of any
document, not just XML and not just for visual purposes, for JDOM to be
really useful it must also allow Documents to live ONLY in memory, or to be
passed via RMI. In which case having content living as a String would be
cumbersome and painful. Also, having the data conserved in the format that
it was generated in is also important, i.e. the recevier object would not
have to do a best guess conversion...I would advocate that a new object be
created called something like: "Content" which would then wrap the actual
content up and let applications get access to the data the addContent method
of Element would then create a new Content method to hold the actual data.
The API for Content would look something like:
/**
A class to represent any type of content, supports primitive types and
objects.
*/
public class Content
{
Object content = new Object ();
public Content (Object val)
{
content = val;
}
public Content (char val)
{
this.content = new Character (val);
}
public Object getContent ()
{
return this.content;
}
public String getContentAsString ()
throws WrongContentTypeException
{
if (!this.content instanceof String)
{
throw WrongConentTypeException ("Content type is actually: " +
this.content.getClass ());
}
return this.content.toString ();
}
public char getContentAsChar ()
throws WrongContentTypeException
{
if (!this.content instanceof Character)
{
throw WrongConentTypeException ("Content type is actually: " +
this.content.getClass ());
}
return ((Character) this.content).charValue ();
}
/**
A method for the XMLOutputter to use for output...
*/
public String toString ()
{
return this.content.toString ();
}
...and so on...
}
What do you think?
Does Jason have any views on this?
G.
-----Original Message-----
From: jdom-interest-admin at jdom.org
[mailto:jdom-interest-admin at jdom.org]On Behalf Of Jochen Kirn
Sent: Thursday, March 15, 2001 7:06 PM
To: jdom-interest at jdom.org
Subject: Re: [jdom-interest] Thoughts on...
> Element.addContent (Object obj);
> Element.addContent (int val);
> Element.addContent (long val);
> Element.addContent (char val);
> Element.addContent (float val);
> Element.addContent (double val);
> Element.addContent (boolean val);
> Element.addContent (char[] vals);
for primitive types you can write
Element.addContent("" + primitiveValue); // int, double, boolean, ...
> In other words have it similar to how PrintStream works. Currently I have
> to convert all my values myself, which is a pain.
to prepend a empty String ("") isn't much pain i think ;-)
imho your suggestion would unnecessarily boast the JDOM-API.
> All those methods would have to do is generate the string equivalent of
> the value passed in, in other words they would be the same as
sure, but those methods would only fit to a certain String-represtation
eg. the project i'm using jdom in, i need to have control of that
represtation.
> myelement.addContent (System.currentTimeMillis ());
try: myelement.addContent ("" + System.currentTimeMillis ());
and you are done :-)
> Also, a really useful thing would be to have a method for adding
> StringBuffers as well...
StringBuffer.toString() ?!
sers,
Jochen
--
Sent through GMX FreeMail - http://www.gmx.net
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com
More information about the jdom-interest
mailing list