<div>
Hi Thomas,
</div><div><br></div><div>The first view projects where we did the mapping "by hand" were exactly using record_info, and for very simple records it works just fine.</div><div><br></div><div>The problems that we had with that approach is that we don't have any type information, so it makes it hard to get some types (atoms, timestamps) to roundtrip to JSON and back with full type fidelity. For example, you have to convert atoms to strings to pass to the browser but on the way back it's impossible to know whether the string you're receiving from the browser should stay a string to be turned back into an atom. From a parse transform with type information, all these transformations can be done automatically, and nested structures can be handled easily.</div><div><br></div><div>If type information was available at runtime, that would be great but unfortunately the only way to get that is via the parse_transform mechanisms.</div><div><br></div><div>Cheers,</div><div><br></div><div>Steve</div>
<div><div><br></div><div>-- </div><div>Steve Strong</div><div>Sent with <a href="http://www.sparrowmailapp.com/?sig">Sparrow</a></div><div><br></div></div>
<p style="color: #A0A0A8;">On Friday, 14 June 2013 at 14:06, Thomas Allen wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>Hi Steve,</div><div><br></div><div>I've done some similar things, except rather than using a parse</div><div>transform to do this (I do not like parse transforms except as a last</div><div>resort, I find macros a more explicit way to express compile-time</div><div>things) I simply store my record info in application env when my</div><div>application starts, and define functions that access these values:</div><div>db:fields(RecName), etc. Then, I have higher level functions that use</div><div>this metadata. It's easy to test, and I reason it's pretty fast, with</div><div>application env being backed by ETS (it's never been a bottleneck).</div><div><br></div><div>%% in .hrl</div><div>-define(DB_FIELDS(Model), {Model, record_info(fields, Model)}).</div><div><br></div><div>%% in app:start/0:</div><div> application:set_env(db, model_fields,</div><div> [?DB_FIELDS(blog_post),</div><div> ?DB_FIELDS(contact_message)]),</div><div><br></div><div>%% in record utils</div><div>fields() -></div><div> {ok, Fields} = application:get_env(db, model_fields),</div><div> Fields.</div><div><br></div><div>fields(Model) -></div><div> proplists:get_value(Model, fields()).</div><div><br></div><div>%% etc.</div><div><br></div><div>Maybe others here with more experience can correct me, but I think some</div><div>Erlang developers are too eager to introduce parse transforms to solve</div><div>simple problems.</div><div><br></div><div>Thomas</div><div><br></div><div><br></div><div>On Fri, Jun 14, 2013, at 03:34 AM, Steve Strong wrote:</div><blockquote type="cite"><div><div>My plan for the actual JSON encode / decode is for the mapper to produce</div><div>a structure that's compatible with jsx</div><div>(<a href="https://github.com/talentdeficit/jsx">https://github.com/talentdeficit/jsx</a>) - that's the encoder / decoder</div><div>that we currently use. If we go the open-source route, I'd probably aim</div><div>to make that pluggable so that folk can use their preferred JSON encoder.</div><div><br></div><div>Cheers,</div><div><br></div><div>Steve </div><div><br></div><div>-- </div><div>Steve Strong</div><div>Sent with Sparrow (<a href="http://www.sparrowmailapp.com/?sig">http://www.sparrowmailapp.com/?sig</a>)</div><div><br></div><div><br></div><div>On Friday, 14 June 2013 at 12:31, Slava Yurin wrote:</div><div><br></div><blockquote type="cite"><div><div> See <a href="https://github.com/iskra/jsonx">https://github.com/iskra/jsonx</a>. Maybe it decoder/encoder will help you.</div><div> </div><div>14.06.2013, 17:13, "Steve Strong" <steve@srstrong.com (<a href="mailto:steve@srstrong.com">mailto:steve@srstrong.com</a>)>:</div><blockquote type="cite"><div><div>Hi,</div><div> </div><div>We have built a number of projects recently that have a mongodb backend, an HTML / javascript frontend and Erlang in the middle - pretty standard stuff. One of the things the we end up repeating over and over is mapping data from BSON (the mongo format) to Records (our preferred in-memory format for Erlang) and JSON (to send / receive from the browser). To add to the mix, we also like using proplists in configuration files, so have mappings from those to records as well.</div><div> </div><div>On the last project I finally got sick of doing it by hand, so knocked up a fairly simple parse transform to take the records (with their type specifications) and generate the mapping code, which has resulted in being able to do things like (note - pseudocode only!):</div><div> </div><div>Foo = build_my_record(),</div><div>mongo:insert(collection, mapper:record_to_bson(Foo)),</div><div>web_socket:send(Client, mapper:record_to_json(Foo)),</div><div> </div><div>receive</div><div>{client, Response} -></div><div>do_stuff_with(mapper:json_to_record(foo, Response)</div><div>end</div><div> </div><div>This has worked very well, and handles about 80% of the types we throw at it. The sorts of types that it doesn't deal with are unions and tuples, e.g.</div><div> </div><div>-record(bla, {</div><div>metadata :: x() | y(),</div><div>ratio :: {integer(), integer()}</div><div>}). </div><div> </div><div>Due to the value the simple version has had to us, I'm about to embark on a re-work that is going to aim to handle (pretty much) any type you can throw at it, and give full two-directional fidelity on the conversions (e.g., you can assert that Data == xxx_to_record(record_to_xxx(Data)) ). </div><div> </div><div>So, a couple of questions:</div><div> </div><div>1. Does such a thing already exist? I'm no fan of re-inventing the wheel :)</div><div>2. If not, would anyone be interested in it being open-sourced?</div><div>3. If 2., then does anyone have opinions on the functionality / API etc?</div><div> </div><div>Interested in any feedback,</div><div> </div><div>Cheers,</div><div> </div><div>Steve</div><div>-- </div><div>Steve Strong</div><div>Sent with Sparrow (<a href="http://www.sparrowmailapp.com/?sig">http://www.sparrowmailapp.com/?sig</a>)</div><div> </div><div> </div><div><br></div><div>,</div><div>_______________________________________________</div><div>erlang-questions mailing list</div><div>erlang-questions@erlang.org (<a href="mailto:erlang-questions@erlang.org">mailto:erlang-questions@erlang.org</a>)</div><div><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a> </div></div></blockquote></div></blockquote><div><br></div><div>_______________________________________________</div><div>erlang-questions mailing list</div><div><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a></div><div><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a></div></div></blockquote></div></div></span>
</blockquote>
<div>
<br>
</div>