Re: EOAttribute.validateValue question
Re: EOAttribute.validateValue question
- Subject: Re: EOAttribute.validateValue question
- From: Kieran Kelleher <email@hidden>
- Date: Thu, 12 Jul 2007 08:15:21 -0400
Actually I have been using org.apache.commons.lang.text.StrTokenizer
for parsing and it works beautifully with both "Excel CSV" and
"Normal CSV" formats without having to differentiate. Lightweight and
easy and convenient since I already have org.apache.commons.lang in
my Foundation framework. Hey try it on your badly formatted client
file, it might handle it!
import org.apache.commons.lang.text.StrTokenizer;
StrTokenizer.getCSVInstance();
For writing CSV files, I have used ostermiller utils CSV
http://ostermiller.org/utils/CSV.html
On Jul 12, 2007, at 1:13 AM, Sam Barnum wrote:
And if you're considering rolling your own CSV parser, I'd
recommend using this instead:
http://opencsv.sourceforge.net/
It handles the escaping of quotes correctly, and commas inside
quoted values. I've had good luck with it, except from a client
who can't seem to reliably generate a correctly formatted csv file...
On Jul 11, 2007, at 8:07 PM, Chuck Hill wrote:
On Jul 11, 2007, at 7:50 PM, Kieran Kelleher wrote:
Chuck/Francis,
This is one approach I had been considering, so since you are
both right, I'll now definitely choose that approach! .... I just
needed to make sure I was not missing some more generic elegant
way in eof.
I already have a DataMapping helper class that maps between
target eo attribute keys and the csv field names. I'll upgrade
that class to have a dictionary of optional ValueConverter
classes for each destination key/keypath.
What I did was to create a NullFormatter so that I did not have to
worry about optionality:
import java.text.*;
/**
* A null object formatter that just returns its input. Useful
for when the API needs a formatter
* but there is no formatting to do.
*/
public class NullFormatter extends Format
{
/** Convenience instance. **/
public static final NullFormatter Formatter = new NullFormatter
();
public NullFormatter()
{
super();
}
public StringBuffer format(Object object, StringBuffer
stringBuffer, FieldPosition fieldPosition)
{
stringBuffer.append(object);
return stringBuffer;
}
public Object parseObject(String string, ParsePosition position)
{
position.setIndex(string.length());
return string;
}
}
As always, thanks for the listening hears and constructive input,
As always, you are most welcome.
Chuck
On Jul 11, 2007, at 8:57 PM, Chuck Hill wrote:
A more generic and reusable solution would be to write
CSVReader that takes a file reference, an array of key paths
and an array of formatters to read CSV column strings, convert
them if needed (with formatter) and set it (with key path and
Key Value Coding). I've done this kind of thing in the past,
and it's very handy. You can even create custom formatters to
convert strings to special data (i.e. BooleanFormat,
InetAddressFormat, etc.).
Interesting, that is precisely what I was about to suggest. I
do the exact same thing. We must therefor be correct. Grin.
It is definitely a more flexible solution and a better design
for the problem at hand.
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve
specific problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40360works.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mac.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden