So I sent this email out yesterday, it never made it. So here it is again.
-Can we nail down the use case here with specifics? Everything mentioned below
is vague and generic. This is bad for feature development.
-Mission creep. This project is data first, api second. A presentation
formatter is way out of scope. Effort is better spent on the data.
So regarding removing JSON altogether, ok, but we need to rethink our examples
then. Please see my previous point regarding mission creep. While I think its
good we are putting a lot of focus on the Java client, iterations are much
needed on the data.
From: Volkan Yazıcı <[email protected]>
To: "[email protected]" <[email protected]>
Sent: Wednesday, December 31, 2014 5:38 AM
Subject: Re: JSON toString methods in data classes
My take on the issue is as follows:
1) Console example was already in a messy form and addressed in DMAP-54.
2) It is not client's responsibility to ship the functionality to format
Device/DeviceType/Map<String,String> for JSON/XML. Java client -- as its name
implies -- after all is just a client and it should behave like one so.
3) Servlets... I really could not understand what a servlet example has to do
in a UserAgent-to-DeviceAttributes library. Anyway... I will address this issue
in a separate thread.
In the attachment, you can find the following two patches: 1) Remove JsonParser
from Java client and 2) improve servlet example. Since I still could not manage
to convince you to migrate to GitHub, you will not be able to see my
intermediate commits and we together will not be able to go into a make
pull-review-update cycle.
On Tue, Dec 30, 2014 at 6:42 PM, Werner Keil <[email protected]> wrote:
I'd say a separate "presentation" element, *Format, *Formatter, *Renderer
or what we think sounds best.
At least JSON would normally be Locale neutral so maybe Renderer sounded
better for that, but other suggestions welcome.
Werner
On Tue, Dec 30, 2014 at 6:37 PM, Reza Naghibi <
[email protected]> wrote:
> Just to be clear, whats the proposed change?
>
>
>
>
> <div>-------- Original message --------</div><div>From: Volkan Yazıcı <
> [email protected]> </div><div>Date:12/30/2014 11:12 AM
> (GMT-05:00) </div><div>To: [email protected] </div><div>Cc:
> </div><div>Subject: Re: JSON toString methods in data classes </div><div>
> </div>I agree. While it is not a big problem, it looks like an ad-hoc hack
> in its
> current form. Further, I believe its consumer's responsibility to pick the
> format for marshalling. Even if JSON is the way to go, we shouldn't be
> writing our own JsonParser class -- whose name implies a parser but which
> is actually a formatter -- and use a more decent library for that purpose,
> I believe. Anyway, not a big issue. If the rest approves the change, I can
> come up with a patch.
>
> On Tue, Dec 30, 2014 at 4:37 PM, Werner Keil <[email protected]>
> wrote:
>
> > Maybe we can abstract that a bit, e.g. a formatter/renderer that offers
> > multiple output options. Whatever is best as default could be used behind
> > toString() if JSON is best, why not, but it would be good to abstract
> data
> > from the output/representation.
> >
> > Werner
> >
> >
> >
> > On Tue, Dec 30, 2014 at 2:19 PM, Reza Naghibi <
> > [email protected]> wrote:
> >
> > > JSON is used in our servlet, spring, and console examples.
> > >
> > >
> > >
> > > <div>-------- Original message --------</div><div>From: Volkan Yazıcı <
> > > [email protected]> </div><div>Date:12/30/2014 5:02 AM
> > (GMT-05:00)
> > > </div><div>To: [email protected] </div><div>Cc:
> > > </div><div>Subject: JSON toString methods in data classes </div><div>
> > > </div>Hi,
> > >
> > > Is there a particular reason for why are we returning JSON formatted
> > output
> > > from toString() methods of o.a.d.data.* classes? This convention is not
> > > followed by .NET/VB clients, if I am not mistaken.
> > >
> > > Best.
> > >
> >
>
