RE: ToStringBuilder.reflectionToString() problem

[Gary Gregory <gg...@seagullsw.com>]

Hello,

Currently, we do not allow:

new ToStringBuilder(null)

We throw an IllegalArgumentException("The object to create a toString for
must not be null");

I am refactoring the reflection toString() code into a ToStringBuilder
subclass in order for people to customize some features themselves. The
reflection toString() does allow null values. Of course, now that I subclass
ToStringBuilder, I get the IllegalArgumentException for null values, a step
backwards.

Therefore, I would like to change the behavior of ToStringBuilder such that:

new ToStringBuilder(null).toString()

returns "null".

Are there any objections to this?

Thanks,
Gary

-----Original Message-----
From: Gary Gregory [mailto:ggregory@seagullsw.com] 
Sent: Tuesday, May 27, 2003 16:12
To: 'Jakarta Commons Users List'
Subject: RE: ToStringBuilder.reflectionToString() problem

Right, this is a good idea that I have considered in the past. The way we
specify whether or not to output transients is a bit bogus IMHO, there is
room in all of this for an object that would let you tweak all of this
behavior. I'll think about this tonight and propose something if I can come
up with something not too nasty.

Gary

-----Original Message-----
From: Tolley Shorn [mailto:Shorn.Tolley@nrm.qld.gov.au] 
Sent: Tuesday, May 27, 2003 16:07
To: Jakarta Commons Users List
Subject: RE: ToStringBuilder.reflectionToString() problem


It's workable, I did it last night in order to keep going.  It just means I
don't get (almost) free toString()s anymore.

What about making the worker methods non-static and overridable instead?
Then I could subclass ToStringBuilder to build in the knowledge.
Or factoring out a worker class that can be plugged in similarly to
ToStringStyle?
Or some kind of extension of the mechanism that specifies whether or not to
use transients?

Cheers,
Shorn.

> -----Original Message-----
> From: Gary Gregory [mailto:ggregory@seagullsw.com]
> Sent: Wednesday, 28 May 2003 2:37 AM
> To: 'Jakarta Commons Users List'
> Subject: RE: ToStringBuilder.reflectionToString() problem
> 
> 
> Hello,
> 
> The quick answer to your question (without adding features to
> ToStringBuilder) is to use the non-reflection APIs. For example:
> 
>    public String toString() {
>      return new ToStringBuilder(this).
>        append("name", name).
>        append("age", age).
>        append("smoker", smoker).
>        toString();
>    }
> 
> If this is not acceptable, we can discuss how to make your 
> feature request
> fit in the ToStringBuilder framework. I am not sure the 
> proposed solution
> fits: (1) It breaks the model-view type of separation b/w the 
> builder and
> the style class and (2) it requires the access to be set on a 
> per field
> basis, which, the current impl is not factored to do.
> 
> So, in a nutshell, is the above example workable for you (or not)?
> Obviously, using the reflection method is less code.
> 
> Gary
> 
> -----Original Message-----
> From: Tolley Shorn [mailto:Shorn.Tolley@nrm.qld.gov.au] 
> Sent: Tuesday, May 27, 2003 02:51
> To: commons-user@jakarta.apache.org
> Subject: ToStringBuilder.reflectionToString() problem
> 
> Hi folks,
> 
> I've got a bit of a problem with the ToStringBuilder's 
> reflectionToString
> method.
> I'd like to suggest a very small improvement (I think) to the
> ToStringBuilder interface.
> 
> We're using Hibernate to provide the persistence of our domain model.
> I would like to use ToStringBuilder to provide accurate 
> toString() methods
> for the classes in our domain model.
> Unfortunately, in some circumstances Hibernate uses an OS library call
> CgLib.
> CgLib is a pretty nifty little library that dynamically constructs JVM
> bytecode.
> Hibernate uses CgLib to provide transparent proxies.
> 
> Unfortunately, becuase of the structure of our app (not 
> really Hibernate or
> CgLib's fault), the reflectionToString() method will cause an 
> exception
> because it will try to access the CgLib class outside of an 
> appropriate
> scope (becuase we call toString() outside of the appropriate scope).
> 
> Basically, I would like to be able to customize the ToStringBuilder to
> decide on a per-attribute basis whether or not to access a 
> given field using
> reflection.
> 
> What I'd like the reflectionToString method to do is to implement the
> template design pattern by delegating the actual access and 
> formatting of
> the individual attribute to a method on the ToStringStyle.
> 
> The basic ToStringStyle could just delegate this decision 
> straight back to
> the ordinary ToStringBuiler, so for ordinary use the 
> interface wouldn't
> change at all.
> With this functionality you could have all kinds of fun with 
> doing special
> things for certain attribute names or types.
> 
> What this change would allow me to do is something like this:
> 
> class BaseEntity{
> 	public toString(){
> 		return ToStringBuilder.reflectionToString(this, new
> CgLibAwareToStringStyle());
> 	}
> }
> 
> CgLibAwareToStringStyle extends StandardToStringStyle {
> 	public String appendField(ToStringBuilder builder, Field f){
> 		if( 
> f.getType().isAssignableFrom(CgLibMarkerInterface.class)
> ){
> 			// do a special CgLib appropriate thing 
> that won't
> make my app barf :)
> 		}
> 		else {
> 			builder.append(f);
> 		}
> 	}
> }
> 
> Maybe I'm missing a better way of doing this with the current
> ToStringBuilder interface?
> At the moment it appears I'll have to duplicate the 
> ToStringBuilder in our
> app and extend it so I can keep going (or forfeit 
> ToStringBuiler's labour
> saving functionality).
> 
> What do you folks think?
> 
> Cheers,
> Shorn.
> 
> 
> **************************************************************
> **********
> The information in this e-mail together with any attachments is
> intended only for the person or entity to which it is addressed
> and may contain confidential and/or privileged material.
> 
> Any form of review, disclosure, modification, distribution
> and/or publication of this e-mail message is prohibited.  
> 
> If you have received this message in error, you are asked to
> inform the sender as quickly as possible and delete this message
> and any copies of this message from your computer and/or your
> computer system network.  
> **************************************************************
> **********
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 


************************************************************************
The information in this e-mail together with any attachments is
intended only for the person or entity to which it is addressed
and may contain confidential and/or privileged material.

Any form of review, disclosure, modification, distribution
and/or publication of this e-mail message is prohibited.  

If you have received this message in error, you are asked to
inform the sender as quickly as possible and delete this message
and any copies of this message from your computer and/or your
computer system network.  
************************************************************************


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org