Okay, for the pedants out there, the *real* equivalent of Object's toString
method is:
public static String objectToString(Object obj) {
if (obj == null) {
return "null";
} else {
return obj.getClass().getName() + "@" +
Integer.toHexString(System.identityHashCode(obj));
}
}
Quoting Kris Schneider <[EMAIL PROTECTED]>:
> This should always give you the equivalent of Object's toString method:
>
> Integer.toHexString(System.identityHashCode(obj)).
>
> If anything gets added, I'd rather see something like what's used in
> java.awt.Component. The toString method is implemented like:
>
> public String toString() {
> return getClass().getName() + "[" + paramString() + "]";
> }
>
> Then Component has its own implementation of the paramString method:
>
> protected String paramString() {
> ...
> return str;
> }
>
> Finally, subclasses invoke super.paramString and add their own information:
>
> protected String paramString() {
> return super.paramString() + ...;
> }
>
> The implementation of paramString for ActionForm should probably just look
> like:
>
> protected String paramString() {
> return "";
> }
>
> ;-) About the only thing worth adding might be the ActionServlet reference.
> In
> the end, all this is doing is providing a convenient hook for subclasses.
> The
> decision about what information to include is still the responsibility of
> the
> subclasses (as it should be).
>
> Note that DynaActionForm already provides its own implementation of
> toString,
> which is inherited by DynaValidatorForm and DynaValidatorActionForm. So,
> DynaActionForm could then be changed to remove its toString method and
> provide
> a paramString method instead:
>
> protected String paramString() {
> StringBuffer buff = new StringBuffer();
> if (!this.dynaValues.isEmpty()) {
> buff.append(", ");
> for (Iterator iter = this.dynaValues().entrySet().iterator();
> iter.hasNext();) {
> Map.Entry entry = (Map.Entry)iter.next();
> buff.append(entry.getKey()).append("=");
> Object propValue = entry.getValue();
> if (propValue == null) {
> buff.append("<NULL>");
> } else if (propValue.getClass().isArray()) {
> buff.append("[");
> int length = Array.getLength(propValue);
> for (int i = 0; i < length; i++) {
> buff.append(Array.get(propValue, i));
> if (i < (length - 1)) {
> buff.append(", ");
> }
> }
> buff.append("]");
> } else {
> buff.append(propValue);
> }
> if (iter.hasNext()) {
> buff.append(", ");
> }
> }
> }
> return super.paramString() +
> ", dynaClass=" + getDynaClass().getName() +
> buff.toString();
> }
>
>
> Quoting [EMAIL PROTECTED]:
>
> > Frank,
> >
> > I also had to go a long way until I found this approach. It actually came
> to
> > me when I saw in my project many data objects (= java beans) were
> generated
> > using UML tools that did not care about the toString() method my way. Next
> I
> > saw Castor XML/JAXB and JDO code generation, and finally had to decide that
> a
> > common base class or implementing each and every toString method is not
> the
> > solution.
> >
> > With the static method I can apply my toString implementation to any
> object
> > that comes along - just what you need for debugging. I just wonder why the
> > Apache commons-beanutils does not provide such a method, and someone
> > mentioned it might be in commons-lang, but I could not find that either.
> >
> > Hiran
> >
> > -----------------------------------------
> > Hiran Chaudhuri
> > SAG Systemhaus GmbH
> > Elsenheimer Straße 11
> > 80867 München
> > Phone +49-89-54 74 21 34
> > Fax +49-89-54 74 21 99
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > Sent: Donnerstag, 7. Oktober 2004 14:22
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: Proposed Action base class change
> > >
> > > Another fair point. :)
> > >
> > > Well, that's the reason I put the idea out there... I can't
> > > think of every possible angle to look at it from... If I
> > > thought I could, I wouldn't need to solicit opinions in the
> > > first place.
> > >
> > > Kind of depressing though... I'm trying to contribute, but so
> > > far all my ideas have been shot down (but for good reasons,
> > > so I'm not bitter about it). Just have to keep trying I suppose. :)
> > >
> > > --
> > > Frank W. Zammetti
> > > Founder and Chief Software Architect
> > > Omnytex Technologies
> > > http://www.omnytex.com
> > >
> > > On Thu, October 7, 2004 8:56 am, [EMAIL PROTECTED] said:
> > > > Hi, Frank.
> > > >
> > > > I do not agree. While in most cases it is desireable to see
> > > inside a
> > > > bean (hence I created my
> > > > public static String toString(Object bean) method),
> > > there are times
> > > > when I just have to make sure a bean is not just equal but the same
> > > > instance.
> > > > The java.lang.Object.toString() methods allows me to that quite
> > > > quickly as the memory address is printed.
> > > >
> > > > Unless you have another way to provide that information, I'd rather
> > > > stick with the default toString() plus some utility
> > > toString(Object)
> > > > method. The impact for you is not too much. What you code so far is:
> > > > log.debug("mybean="+mybean);
> > > > and you'd have to change that to
> > > > log.debug("mybean="+BeanUtil.toString(mybean));
> > > > which will allow you to either see the memory address or
> > > the contents,
> > > > whatever you prefer.
> > > >
> > > > Hiran
> > > >
> > > > -----------------------------------------
> > > > Hiran Chaudhuri
> > > > SAG Systemhaus GmbH
> > > > Elsenheimer Stra?e 11
> > > > 80867 M?nchen
> > > > Phone +49-89-54 74 21 34
> > > > Fax +49-89-54 74 21 99
> > > >
> > > >
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
> > > >> Sent: Donnerstag, 7. Oktober 2004 13:43
> > > >> To: Struts Developers List
> > > >> Subject: Re: Proposed Action base class change
> > > >>
> > > >> Hi Niall,
> > > >>
> > > >> I certainly agree it would not be possible to satisfy
> > > everyone, but
> > > >> seeing as the intrinsic toString() is all but useless (and
> > > people do
> > > >> generally expect that to be the case with many classes),
> > > why not give
> > > >> an implementation that is of at least some use to some people?
> > > >> Surely it would be better than what you get now? Obviously it's
> > > >> something many people will override, and that's of course
> > > the whole
> > > >> point of inheritance. But providing even a slightly more useful
> > > >> default implementation (and maybe telling people it's a
> > > basic default
> > > >> implementation so as to try and keep the flood of bugzilla
> > > requests
> > > >> to a
> > > >> minimum) seems to me like a good idea.
> > > >>
> > > >> I can't address your point about dynabeans because I haven't used
> > > >> them enough to be able to intelligently comment (which is to say I
> > > >> haven't used them at all! :) )... I wouodn't imagine some basic
> > > >> implementation would be too tough for them as well.
> > > >>
> > > >> In any case, I will look at the toString builders you mentioned...
> > > >> I've come to really like using the commons packages and I try to
> > > >> whenever I can. This would be a good case I think, if it
> > > doesn't get
> > > >> added as I proposed. I already have an ActionHelpers class with a
> > > >> bunch of similarly-themed static methods for use from Actions, so
> > > >> maybe it's time to do so for forms as well.
> > > >>
> > > >> --
> > > >> Frank W. Zammetti
> > > >> Founder and Chief Software Architect
> > > >> Omnytex Technologies
> > > >> http://www.omnytex.com
> > > >>
> > > >> Niall Pemberton wrote:
> > > >> > Frank,
> > > >> >
> > > >> > For me it wouldn't be any use unless it also handled
> > > >> DynaBeans. Even
> > > >> > then I'd end up overriding it because I have some
> > > formatting utils
> > > >> > which do dates, arrays and collections. Seems to me if
> > > we put it in
> > > >> > then we would end up with a monster trying to satisy
> > > >> everyones needs
> > > >> > and forever dealing with bugzilla requests for
> > > enhacements (someone
> > > >> > would want an i18n version!) - all just for debugging.
> > > >> >
> > > >> > The easiest thing is to just put all that code into a
> > > >> utility method -
> > > >> > that way its only a one liner in the toString() - even
> > > >> better if you
> > > >> > have your own "base" ActionForm that all you others derive
> > > >> from, then
> > > >> > its only in one place.
> > > >> >
> > > >> > Also, there are a set of "toString" builders in commons
> > > >> lang which you
> > > >> > might like to use - including a reflection one like yours:
> > > >> >
> > > >> >
> > > >>
> > > http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bu
> > > >> i
> > > >> > lder/package-summary.html
> > > >> >
> > > >>
> > > http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bu
> > > >> i
> > > >> > lder/ReflectionToStringBuilder.html
> > > >> >
> > > >> > Niall
> > > >> >
> > > >> > ----- Original Message -----
> > > >> > From: "Frank W. Zammetti" <[EMAIL PROTECTED]>
> > > >> > To: "Struts Developer" <[EMAIL PROTECTED]>
> > > >> > Sent: Thursday, October 07, 2004 4:29 AM
> > > >> > Subject: Re: Proposed Action base class change
> > > >> >
> > > >> >
> > > >> >
> > > >> >>Obviously I made a typo in the subject... this applies to the
> > > >> >>ActionForm base class.
> > > >> >>
> > > >> >>Did anyone have any comment on this? I've noticed a lack
> > > >> of activity
> > > >> >>on the list lately...
> > > >> >>
> > > >> >>
> > > >> >>>Hello all...
> > > >> >>>
> > > >> >>>I find myself all the time overloading toString() of my
> > > >> ActionForms
> > > >> >>>for
> > > >> >
> > > >> > debugging
> > > >> >
> > > >> >>>purposes, so I can easily dump the current state of the
> > > object. I
> > > >> >>>had
> > > >> >
> > > >> > been doing
> > > >> >
> > > >> >>>this for each ActionForm class, specifically for it, but
> > > >> it ocurrs to
> > > >> >>>me
> > > >> >
> > > >> > that a
> > > >> >
> > > >> >>>general-purpose reflection-based approach would be better.
> > > >> >>>
> > > >> >>>I'd like to propose adding this functionality to the
> > > >> ActionForm base
> > > >> >
> > > >> > class. Here's
> > > >> >
> > > >> >>>the code I propose adding:
> > > >> >>>
> > > >> >>>import java.lang.reflect.Field;
> > > >> >>>public static final AVERAGE_FIELD_SIZE = 25; public String
> > > >> toString()
> > > >> >>>{
> > > >> >>> String str = "";
> > > >> >>> StringBuffer sb = null;
> > > >> >>> try {
> > > >> >>> Field[] fields = this.getClass().getDeclaredFields();
> > > >> >>> sb = new StringBuffer(fields.length * AVERAGE_FIELD_SIZE);
> > > >> >>> for (int i = 0; i < fields.length; i++) {
> > > >> >>> if (sb.length() > 0) { sb.append(", "); }
> > > >> >>> sb.append(fields[i].getName() + "=" +
> > > fields[i].get(this));
> > > >> >>> }
> > > >> >>> str = sb.toString().trim();
> > > >> >>> } catch (Exception e) {
> > > >> >>> str = "Exception in ActionForm.toString() : " + e;
> > > >> >>> }
> > > >> >>> return str;
> > > >> >>>}
> > > >> >>>
> > > >> >>>The value of AVERAGE_FIELD_SIZE is a matter of debate,
> > > and it's of
> > > >> >
> > > >> > course impossible
> > > >> >
> > > >> >>>to come up with a real value, so something reasonable is
> > > >> the answer.
> > > >> >>>25
> > > >> >
> > > >> > struck me
> > > >> >
> > > >> >>>as a decent starting point.
> > > >> >>>
> > > >> >>>What does everyone think? I find this functionality to be very
> > > >> >>>useful
> > > >> >
> > > >> > in my work,
> > > >> >
> > > >> >>>and I suspect others may as well. The code doesn't add any
> > > >> >>>dependencies
> > > >> >
> > > >> > outside
> > > >> >
> > > >> >>>J2SE, and it's certainly simple enough as to not be
> > > >> particularly risky.
> > > >> >>>
> > > >> >>>Thanks all!
> > > >> >>>
> > > >> >>>Frank W. Zammetti
> > > >> >>>Founder and Chief Software Architect Omnytex Technologies
> > > >> >>>http://www.omnytex.com
>
> --
> Kris Schneider <mailto:[EMAIL PROTECTED]>
> D.O.Tech <http://www.dotech.com/>
--
Kris Schneider <mailto:[EMAIL PROTECTED]>
D.O.Tech <http://www.dotech.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
