Closed GoogleCodeExporter closed 9 years ago
We kept these objects/methods private on purpose. We were not happy with its
API
when we first release GSON, so we did not want to leak it out to the clients of
this
library and then have to support it forever.
Hopefully we can clean up the API that this interface exposes and then we will
definitely consider exposing this interface and method in GsonBuilder.
Original comment by joel.leitch@gmail.com
on 16 Oct 2008 at 5:56
Also, if you have any specific suggestions on how to improve the pretty
printing, we
would be happy to incorporate them. Even better, if you can contribute some
code in
this regard.
We also welcome suggestions on the API design in this respect. What API would
you
prefer? Would the current API (when made public) meet your needs? Can you live
with
it, if we keep the parse tree navigation support private in JsonElement and its
subtypes?
Original comment by inder123
on 16 Oct 2008 at 11:33
I realize I've been a lazy user that has done nothing but complaining till now
:-)
I'll enjoy looking into the code to see if I can come up with a suggestion to
improve
the pretty print. To do some expectation management: No promises though
regarding any
schedule.
Original comment by b.richt...@gmail.com
on 16 Oct 2008 at 2:09
Hi,
I'm sorry I'm late to the game, but ooh-ooh, let it look (literally) like your
schema
definition (issue #17:
http://code.google.com/p/google-gson/issues/detail?id=17&sort=type)! Looking at
the
example in the JSON Schema Proposal, if the user provides a schema string, then
setPrettyPrinting(schema-String) will do exactly what you want. Only the
developer
"really" knows how s/she wants it to look - using the example again, should
"description" and "type" be on one line or two? Likewise with "properties".
Well, if
I know I'm only outputting a handful of rows of data, one per line is great.
However,
I have an example of an organizational tree of employees, which could be in the
hundreds. In my case, I'm not going to be a one-per-line person.
Great stuff.
Steve
Original comment by steven.b...@gmail.com
on 8 Dec 2008 at 2:14
I need a simple human readable formatter for complex objects. Basically a
format of
one key per line, indentation and the usual stuff. Example:
{
"foo": "bar",
"baz": 1,
"list": [
"first",
"second",
"last"
],
"object": {
"nested": "value"
}
}
There's probably as many different opinions on how this is is indented and
nested as
there are different coding styles - but I just want something that is a bit more
readable for nested structures than a one-liner (or a wrapped one-liner, in the
case
of the current "pretty" printer).
Original comment by nuutti.k...@gmail.com
on 26 Mar 2009 at 10:46
As a response to inder123's comment I emailed a proposal for the Pretty Print
to Joel
in October 2008. I thought to share it here as well.
My suggestion is to add a new method called setJsonFormatter to the GsonBuilder,
which takes a JsonFormatter as an argument. First of all: I (re-)use the name
JsonFormatter. As the current interface called JsonFormatter is not part of the
public API, I think it's ok to use this name.
The JsonFormatter takes, as it does now, care of the formatting of a json
object tree
to a string. It is constructed via a builder pattern. A simple example could be:
JsonFormatter formatter = new JsonFormatterBuilder()
.indentUsingSpacesWithSize(4)
.create();
Gson gson = new GsonBuilder()
.setJsonFormatter(formatter)
.create();
The public methods the JsonFormatterBuilder has are:
- indentUsingSpacesWithSize(4) // Undoes a preceding call to indentUsingTabs()
- indentUsingTabs() // Undoes a preceding call to indentUsingSpacesWithSize()
- insertNewLineAfterStartObject()
- insertNewLineBeforeEndObject()
- insertNewLineAfterStartArray()
- insertNewLineBeforeEndArray()
- insertSpaceBeforeComma()
- insertSpaceAfterComma() // Undoes a preceding call to
insertNewLineAfterComma()
- insertNewLineAfterComma() // Undoes a preceding call to
insertSpaceAfterComma()
- insertSpaceBeforeColon()
- insertSpaceAfterColon() // Undoes a preceding call to
insertNewLineAfterColon()
- insertNewLineAfterColon() // Undoes a preceding call to
insertSpaceAfterColon()
- wrapIfPossibleAfter(80)
- doubleIndentWrappedLines()
- setLineSeparator(...)
Not calling the method setJsonFormatter, uses a default formatter which has a
compact
output, just like the current output without pretty print is. The current method
'setPrettyPrinting' of the GsonBuilder will (of course) be preserved as a
convenience
method. It will automatically create a JsonFormatter which, if desired,
imitates the
current behavior as much as possible.
What worries me a bit is the the responsibilities of the objects seem to be
mixed up.
Should the Gson object have knowledge of the way it will be formatted? Maybe
it's
better to do it the other way around. Give a JsonFormatter a Gson object. The
same
Gson object could then be formatted in different ways, which is currently
impossible.
But I see no real solution for this given the current API with setPrettyPrint
and toJson.
Original comment by b.richt...@gmail.com
on 27 Mar 2009 at 8:05
Thanks for the detailed proposal. Even though it is way late in the game for
Gson
1.3, I will try to see if we can put it in.
A somewhat simpler approach will be to leave out the JsonFormatterBuilder from
the
API, and just provide a setFormatter method in GsonBuilder. We will also make
JsonFormatter public. Will that suffice for your needs? Also, does that lock us
out
of any future enhancements? For example, would there ever be a need to chain
these
formatters?
Regarding your comment about taking the responsiblity for formatting out, one
way to
address it would be to add new methods to Gson: toJsonTree() that return a
parse tree
instead of String. The primary difference between that and using JsonParser
directly
is that Gson.toJsonTree applies all the custom serializers. Is that a better
approach?
Original comment by inder123
on 27 Mar 2009 at 3:33
For me, providing setFormatter method in GsonBuilder is quite enough (and making
JsonFormatter public). I can not speak for others, of course. I will also
create and
submit the verbose formatter I described for public inclusion, with tests.
Original comment by nuutti.k...@gmail.com
on 27 Mar 2009 at 4:34
For now, a quick solution (workaround) I use is to provide a
JsonDeserializer<String>
(with GsonBuilder#registerTypeAdapter). Most likely this would be an extra
JsonDeserializer, next to the one you need for the 'real' deserialization.
This extra deserializer outputs a String just the way you want; a pretty one,
for
instance.
Original comment by b.richt...@gmail.com
on 27 Mar 2009 at 5:19
Original comment by inder123
on 27 Mar 2009 at 7:35
I submitted the new formatter as issue 112.
Original comment by nuutti.k...@gmail.com
on 29 Mar 2009 at 2:20
Deferred to a future release. Meanwhile, you can use Gson.toJsonTree and format
the output yourself.
Original comment by inder123
on 29 Sep 2009 at 9:12
Original comment by inder123
on 1 Nov 2010 at 10:29
Original comment by inder123
on 3 Nov 2010 at 12:27
Obsoleted by JsonWriter.
Original comment by limpbizkit
on 29 Dec 2011 at 5:49
Original issue reported on code.google.com by
b.richt...@gmail.com
on 14 Oct 2008 at 7:58