Most importantly what to do with it. Data is usually not that bad, but not efficiently used in many cases;-|
If you say JSON is only used for examples, than doing this in the actual client code is already a "feature creep" or misplacement, because in that case, rendering to JSON should be restricted to the 1 or 2 example projects in need of that;-) If it turns out to be reusable, that could still be handled by an example "shared" module, but probably exceeds what the client code requires. Unless we think along the lines of "reporting", but that's maybe a future requirement to think about, not necessarily the highest priority. Werner On Wed, Dec 31, 2014 at 2:38 PM, Reza Naghibi < [email protected]> wrote: > 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. > > > > > > > > > > > > > > >
