|
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 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.