× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: HTML to XML, vice versa
  • From: "Larry Loen" <lwloen@xxxxxxxxxx>
  • Date: Tue, 13 Mar 2001 14:42:49 -0600
  • Importance: Normal


Brad Stone asked:

>That's why I asked if I could extend String() because I'd like to be able
to
>to .toXML() or toHTML() without haveingn to put it into another "object".
>This probably makes no sense.  :)

A static method might work well in simple cases:

public class XMLWrapper  {

    public static String toXML(String tag,String contents) {   return  "<"
+tag+">"+
            contents+"</"+tag+">"; };

};

The static method "toXML" functions like a procedural method for
simple things.

However, especially where XML attributes are involved, the
static method could be foregone in favor of a more robust
O-O approach.  I know you said "I don't want to do this" but it is
a proper O-O method and it has its advantages.  Let's check it out.

Let's take the familiar HTML tag "TD" and render a subset of it as if it
were an XML tag:

public class XMLTDWrapper extends XMLWrapper {

   String align;
   int wide;
   String pcdata;

    public XMLTDWrapper(String alignment, int width, contents) {
         align=alignment;
         wide=width;
         pcdata = contents;
    }

   public String toString() {
         // for performance, you may want to use StringBuffer and
         // strinbuff.append() to build this up rather than all this +
stuff.
        return "<TD align=\""+align+"\" width=\""+wide+"\" >"+
             pcdata + "</TD>";
   }
}

Even for simpler cases, the real O-O version is probably a better approach
than the first (especially as in real XML, attributes might be defined
later
and the real O-O structure allows them to be readily added).

In the true O-O case, you don't even have to declare a
XMLTDWrapper object reference.  A little judicious syntax will enable you
to get the result you want all in one step:

String outputstuff = otherstuff +
   (new XMLTDWrapper(alignment,width,contents)).toString();

This is "syntactic sugar" only, but at least you get around the
necessity of declaring the object reference.

The typing of this sort of thing may be kind of annoying at first, but
it may have much to recommend it in practice.  Of most interest is
that not only is XMLTDWrapper immutable, it is immediately
available for garbage collection.  I don't know if any do, but
a really smart JIT might even recover the storage at once.

Conversely, if creating the XMLTDWrapper object
"bugs" you because you feel like you didn't want to go
to the heap all the time, and you suspect that (contrary to
what I just said) you'll end up with hundreds of
dumb little objects cluttering the machine,
an appropriate "reset the contents" method will avoid
this nicely, which makes the use of an
added object no big deal.

Something like:

    public  void resetMe(String alignment, int width,String contents);

with the identical implementation as the constructor.  In this case,
you'd have to declare a XMLTDWrapper object reference and
stuff it away someplace useful (and threadsafe).  But, you can
make it the target of the "toString" function where you need it.



Larry W. Loen  -   Senior Java and AS/400 Performance Analyst
                          Dept HP4, Rochester MN


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.