Re: [morph-developer] TextConverter using null as destinationClass

[Matt S. <Mat...@wh...>]

I think it makes sense for TextConverter to be able to convert a null or 
an empty String, char[], StringBuffer, etc. to null.  If something like 
"hello world" is the source and the destinationClass is null I think we 
need to throw a TransformationException.  I think this keeps the convert 
implementation relatively clear while maintaining the truth that null is 
an allowed destinationClass.

I think convert(String.class, null) should return null rather than the 
text "null".  Here's one reason (I could probably think of others if 
needed): if you use the MorphFilter in your web application then you can 
use expressions like <c:out 
value="${morph['some.expression.using.the.simple.language']}"/>.  I 
would really hate to see the text "null" printed out by any such expression.

I don't know if this answers your question or muddies the waters further 
;)  I think what I'm proposing is option 3 with the caveat that if the 
source is not null or some type of "empty" object we blowup with a 
TransformationException (similar to if you try to convert "Hello World" 
to an Integer)

BTW, I saw on Jakarta General that Henri Yandall is still interested in 
Morph.  It was a good call on your part to have some patience!  Henri 
has accepted some of my patches to Jakarta projects before and was very 
friendly (which is nice, since I often get screamed at when I try to 
contribute to open source projects).  I'm excited at the prospect of us 
moving Morph (or parts of it) to Apache :)

Matt S

Matt Benson wrote:
> I have noticed that TextConverter declares it is able
> to use null as a source and destination class, but it
> is actually not able to use null for a destination. 
> And since lots of converters use a TextConverter to
> provide for free multiple destination types with the
> implementor only having to provide a String
> conversion, these TextConverter consumers inherit the
> problem.  This leaves a few options:
>
> 1. Agree that in the common paradigm converters allow
> null sources but not destinations.  Because of the
> NullConverter the majority of existing functionality
> would be preserved.  The most unfortunate drawback of
> this approach is that converters which declare a
> single set of source-AND-destination types including
> null (e.g. TextConverter) would have to be adjusted to
> differ their listing of provided source/dest types.
>
> 2.  Alter the default isTransformableImpl behavior in
> BaseTransformer (either here or in TransformerUtils)
> to disallow null destinationClass.  Not sure I like
> this either.
>
> 3.  Rework classes that declare null as a destination
> type to actually be able to return null.  Most likely
> here it would make sense to check for null
> destinationType in BaseTransformer.convert()--I think
> we can agree that there is only one possible return
> value from a null conversion.  I would probably choose
> this alternative, personally.
>
> In any event, we also need to determine what the
> expected behavior is of TextConverter when converting
> null to a text type.  Is it empty, or is it "null"? 
> Which is more likely to serve 99% of what users would
> want OOTB?
>
> WDYT?
>
> -Matt B
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> morph-developer mailing list
> mor...@li...
> https://lists.sourceforge.net/lists/listinfo/morph-developer
>
>