devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Volkan Yazıcı <volkan.yaz...@gmail.com>
Subject Re: JSON toString methods in data classes
Date Wed, 31 Dec 2014 10:38:40 GMT
My take on the issue is as follows:

1) Console example was already in a messy form and addressed in DMAP-54
<https://issues.apache.org/jira/browse/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 <werner.keil@gmail.com> 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 <
> reza.naghibi@yahoo.com.invalid> wrote:
>
> > Just to be clear, whats the proposed change?
> >
> >
> >
> >
> > <div>-------- Original message --------</div><div>From: Volkan
Yazıcı <
> > volkan.yazici@gmail.com> </div><div>Date:12/30/2014  11:12 AM
> > (GMT-05:00) </div><div>To: dev@devicemap.apache.org </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 <werner.keil@gmail.com>
> > 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 <
> > > reza.naghibi@yahoo.com.invalid> wrote:
> > >
> > > > JSON is used in our servlet, spring, and console examples.
> > > >
> > > >
> > > >
> > > > <div>-------- Original message --------</div><div>From:
Volkan
> Yazıcı <
> > > > volkan.yazici@gmail.com> </div><div>Date:12/30/2014  5:02
AM
> > > (GMT-05:00)
> > > > </div><div>To: dev@devicemap.apache.org </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.
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message