[cl-json-devel] proposed: improvements to decoder customization
Henrik Hjelte
henrik at evahjelte.com
Mon Aug 4 10:47:36 UTC 2008
On Mon, Aug 4, 2008 at 1:58 AM, Hans Hübner <hans at huebner.org> wrote:
> I don't quite like the serialization mechanism that cl-json provides.
> The attempt to map from a Lisp datatype to a certain json structure is
> necessarily imperfect because no 1:1 relationship exists, and the
> requirement to first make up a data structure and then call
> encode-json to convert it to a json string is wasteful.
In principle yes. But to defend the current way, it make a clear division of
concerns, separating the code for formating output from the code for logic.
>
> A streaming serialization API is more useful, as one has more control
> over the json format that is being generated and the need to make up a
> data structure that can uniquely be mapped to json structures is
> removed.
I agree to a large degree, but in many situations it is nice to
have a simple to use format and API. What is simple is of course up
to debate. But in the sample below, I think cl-jsons current encoder
could save some code lines. But, why not have both, I am sure
there are lots of situations were your idea will be better?
In a way this is the reverse situation of the decoder issue that Boris
has.
> It is inspired by CXML's streaming serialization which I
> find very easy and straightforward to use.
It is the SAX thing that is used for serailization that is the inspiration?
CXML also has a klacks parser which is inspired from the Java
Streaming XML API, and I know there is a project jettison that
implements JSON for this API.
A cool feature would be if a json parser/serializer could be used as a
simple drop in replacement for an existing xml parser/geneneratior,
there are a few to choose from.
> This could certainly be improved, yet it works for me
I haven't looked much at the internals, but the API seems
very good from the example below.
> and I'd be glad
> to see this or a similar mechanism be integrated into cl-json.
>
I agree, I think we should do something along your lines in cl-json.
But I also want to preserve the current simple interface.
/Henrik
This is a neat sample from your code.
;;------------------------------------------------------------------------------
(defmethod handle-object ((handler json-news-archive-handler)
(channel rss-channel))
(with-json-response ()
(with-object-element ("months")
(with-json-array ()
(dolist (month (sort (rss-channel-archived-months channel)
(lambda (a b)
(if (= (first a) (first b))
(> (second a) (second b))
(> (first a) (first b))))))
(with-json-array ()
(encode-array-element (first month))
(encode-array-element (second month))))))))
;;------------------------------------------------------------------------------
;; If I am not wrong, this is how it would look in the
;; current cl-json implementation.
(defmethod handle-object ((handler json-news-archive-handler)
(channel rss-channel))
(encode-json-response ;; or similar
(with-object-element ("months")
(sort (rss-channel-archived-months channel)
(lambda (a b)
(if (= (first a) (first b))
(> (second a) (second b))
(> (first a) (first b))))))))
More information about the cl-json-devel
mailing list