Key-Value pair data provider

[guest]

Wraps data of the form {key1: "val1", key2: "val2, ... } with a data provider. Implements the Read and Identity data APIs

CLA sent by e-mail (no confirmation of receipt received)

Russell Jones

[Jared Jurkiewicz]

Concerns with the provided file:

One: dojo.provide("oucas.data.KeyValPairReadStore?");

It isn't namespaced to dojo.

Two: No unit tests.

Cannot commit contribution without both problems resolved.

[Jared Jurkiewicz]

No contact information for contributor, nor verification of CLA. Cannot commit. Patch is not complete. Needs UT, docs, etc.

[guest]

I put my name in the bug, thinking that would be sufficient. What else do you need? Obviously, I'm reluctant to put my email address here because a passing spider would wrap it up in its nasty little regexp and cart it off to the spam pits of Mordor.

Of course oucas should be changed to dojo.data or dojox.data, sorry to have missed that.

UT = Unit test? I guess I'd have to look at the ItemFileReadStore.js tests. I'm afraid I don't understand the testing framework. I've sketched out some tests for the functions, but I couldn't work out how to get them into the testing framework (it seems very different from, e.g. JUnit) or if they would be considered sufficient. Would it be useful to attach these sketches here?

Docs? Where are the docs for ItemFileReadStore.js? What needs to be said beyond the comments at the start of the file?

[guest]

You can find my name on ​http://dojo.jot.com/WikiHome/ContributorListing I provided my CLA to Carrie Sackett

[Jared Jurkiewicz]

The ItemFileReadStore? has docs in the dojo book like: http://dojotoolkit.org/book/dojo-book-0-9/part-3-programmatic-dijit-and-dojo/what-dojo-data/available-stores/dojo-data-item

Basically, docs that show simple general usage of the store is very helpful to dojo users.

As for UT, yes, Unit Tests. To commit anything into dojo or dojox, I prefer that there are basic unit tests that exercise each of the core functions that the store implements to ensure it conforms to the dojo.data API. It also helps with preventing bugs and adding a regression point for any bugs found later; unit tests are added for them to make sure it doesn't return. They're very helpful for sanity checks.

I would advise to look at something like the CsvStore? tests over the ItemFileReadStore? tests. ItemFileReadStore? tests are using templates so we can share the tests with ItemFileWriteStore?, which makes them much more complicated to understand. The CsvStore? tests are much simpler. You can see them at: dojox/data/tests/stores/CsvStore.js They're loaded by the dojox/data/tests/module.js file

[Jared Jurkiewicz]

I've got a co-worker here who's willing to help write some UT for this, so I'm referring him to this tracker. If all goes well, it should go in pretty quickly...

[guest]

I actually ended up changing the format of the expected file and re-writing this store. The expected format I used was:

[
    {"key1": "value1"},
    {"key2": "value2"}
]

"Items" from the store are now these individual objects, with three available attributes: "key", "value", and the actual value of the key (for example, "key1" in the first object above).

I've attached a .patch file that contains the KeyValueStore? and the test cases. I've also attached a .html file that could be dumped directly into a new Book page on the dojotoolkit.org website (I copied the CsvStore? page to keep the correct formatting and classes).

-Ben Schell

[guest]

Patch file containing KeyValueStore?.js and UT test cases.

[guest]

Doc page mimicing format/layout of the CsvStore? page from the Dojo Book

[Jared Jurkiewicz]

Updated patch with better root, plus a couple style fixes.

[Jared Jurkiewicz]

Tested on:

FireFox? 2.0.0.12 IE 6 IE 7 SeaMonkey? 1.1.2 Opera 9.2 Safari B3

[Jared Jurkiewicz]

(In [11862]) Applying in a key/value store. fixes #4676