Browse through key-value pairs in a txt vcard

[GoogleCodeExporter]

This is a feature request.

I’d like to be able to create a string showing the content of a vcard as 
key-value pairs.

The closest I get is as follows. I get an iterator with vCard.iterator() then 
for each VCardType I can ask the type name (using getTypeName()), and the 
class. Then, with a switch depending on the class, I can get the value, using 
the appropriate method combinations depending on the type.

It would be nice if this use case was better supported, e.g. with a general 
method "getStringValue" on the VCardType class which would give the string 
content of the value associated to the type. What I’m doing now instead feels 
a bit stupid, as I’m basically doing work to retrieve stuff which is known by 
the internal parser already.

I’m sorry I don’t use the wording from the specs (which I don’t know), I 
hope my issue is understandable.

If the feature actually exists, please consider this issue as a request for 
indicating it in the documentation (unless I have missed it!). I haven’t been 
able to find this on this site.

Original issue reported on code.google.com by olivier.cailloux on 7 Sep 2013 at 9:27

[GoogleCodeExporter]

You can use the `marshalText()` method to convert each property to its 
over-the-wire representation:

{{{
VCard vcard = ...
VCardVersion version = ...
CompatibilityMode compat = CompatibilityMode.RFC;

for (VCardType property : vcard){
  System.out.print(property.getTypeName());
  System.out.print("=");
  System.out.println(property.marshalText(version, compat));
}
}}}

Let me know if that helps.

Original comment by mike.angstadt on 8 Sep 2013 at 12:57

[GoogleCodeExporter]

You might also be interested in the `VCardRawReader` class.  This class parses 
a vCard file without unmarshalling the properties into Java classes:

{{{

StringReader reader = new StringReader(
"BEGIN:VCARD\r\n" +
"VERSION:4.0\r\n" +
"FN:John Doe\r\n" +
"END:VCARD\r\n"
);

VCardRawReader rawReader = new VCardRawReader(reader);
rawReader.start(new VCardDataStreamListener() {
  public void beginComponent(String name) {
    System.out.println("BEGIN=" + name);
  }

  public void readVersion(VCardVersion version) {
    System.out.println("Version is: " + version);
  }

  public void invalidVersion(String version) {
    System.out.println("Version string is invalid: " + version);
  }

  public void readProperty(String group, String name, VCardSubTypes parameters, String value) {
    System.out.println(name + "=" + value);
  }

  public void invalidLine(String line) {
    System.out.println("Invalid line: " + line);
  }

  public void endComponent(String name) {
    System.out.println("END=" + name);
  }

});

}}}

Original comment by mike.angstadt on 8 Sep 2013 at 1:10

[GoogleCodeExporter]

Thanks, it does provide useful workarounds. However, I don’t think these two 
proposals really provide a clean solution for this use case.

The first one feels conceptually strange, as I would like to read what has been 
parsed already.

The second one would mean I have to read twice the vcard file, using two 
different techniques. I need also the classical (normal) parsing method because 
I also want to be able to use the higher level structure e.g. to access contact 
structured names.

I still think a generic getValue, or getStringValue would be great.

That said, in my situation, I am only writing a small program for my personal 
usage, so I don’t need anything really clean or simple. So the provided 
workaround works fine for me. Thanks again.

Original comment by olivier.cailloux on 8 Sep 2013 at 1:16

[GoogleCodeExporter]

Thanks for your feedback.  I'm glad one of the solutions works for you.  Are 
you looking for a way to display each property value as a string for debugging 
purposes?  Perhaps adding "toString()" methods to each property class would be 
beneficial.

ez-vcard treats the vCard file format as just one of the many ways a vCard can 
be serialized.  It aims to separate the serialization code from the data model. 
 Having a common, format-agnostic data model makes it possible to support all 
these formats, as well as any additional formats that may arise in the future.  
It makes switching between formats a trivial operation.  For example, 
converting a plain-text vCard file to an XML document requires just a few lines 
of code.

I plan on making this separation more complete by introducing "marshaller" 
classes, whose sole responsibility it is to handle the serialization 
functionality.  This means that methods like "marshalText" will go away and the 
VCardType classes will know nothing about how they are represented 
over-the-wire (basically, they will contain only getters and setters).  The 
first solution that I posted above will still work, with a few small 
modifications.

Original comment by mike.angstadt on 8 Sep 2013 at 5:33

[GoogleCodeExporter]

I only wanted to compare two vcf files I have (representing my own contacts) 
from different sources. My program shows two panes, with on each pane the vcf 
content from each source. I thus needed a way to simply show all content (to 
make sure I don’t miss any property). I also used the higher level 
functionality of ez- to search for matching entries in both sources, e.g.

I don’t think this specific use case would be very common. However, I do 
think it is a common requirement to want to access key - value pairs without 
having to switch for separate cases according to the type.

A tostring method would be fine, I think. One possible drawback: the 
requirement is about being able to list all content of a vcard using key-value 
pairs. The toString() method, as a convenient debug string, is sometimes 
understood as supposedly being short (though it seems to me this varies a lot 
depending on the library). These two req can conflict.

Anyway, you are the developer ;-).

Original comment by olivier.cailloux on 8 Sep 2013 at 8:05

[GoogleCodeExporter]

Original comment by mike.angstadt on 13 Oct 2014 at 10:44

• Changed state: WontFix