Outcome:

Agenda Item 1:

Continue to move forwardon a check-in this week to try and meet M1 milestone.

Agenda Item 2:  How to define core apis which are API definitions stores are to conform to.

Agenda Item 1:  Status:

• JaredJ updated minor changes denoted from last week's meeting into API.
• Updated comments/code format to hopefully corrispond to current style guidelines.
• Nothing further, JaredJ was out Thurs/Fri of last week on a short vacation.
• JaredJ will contact Adam Peller on 04-02-2007 to get review and hopefully start checkin procedure into Dojo SVN.

Agenda Item 2:  How to define core apis which are API definitions stores are to conform to.

This item is to address something Adam Peller raised while discussing how to get the code committed in.  The issue is around the API specification files, which are the large part of dojo.data.core.  The purpose of Read.js, Write.js, etc, are to define out the API a store must conform to in order to implement a feature.  These are currently implemented as classes created by dojo.declare().  This really seems unnecessary as no one will ever generally subclass these files as what would be the point?  They just provide 'unimplemented' methods which must be over-ridden to work anyway, so subclassing them just forces stores to import them, which wastes download space.  

So, the question put to the Dojo organizxation is, how should these files be defined such that API doc tools can provide the API docs easily but doesn't so something inefficient like make a require on dojo.declare?  Should they be done as simple Javascript objects defined as: dojo.data.core.Read = {};   Should they not be capitalized?   Basically, input from the senior Dojo devs is needed here to d the right thing for dojo.  JaredJ has been following the pattern that has existed for these files (dojo.declare() creations), but has also commented on this seeming odd.  Before we go further and commit items in, we should decide definitively how an API specification file for Dojo should be written so developers can easily get the API docs as well as understand what they must implement.  Does anything else in Dojo do this?

skinner: I don't have any answers for most of those questions, but for what it's worth, at one point we talked about putting the API interface files in an "api" directory, which I think might be an improvement:
    dojo.data.api.Read
    dojo.data.api.Write

Agenda Item 3:  Nested/child attribute access:

From Contributors discussion:

From Jesse Kubnert:

I'd personally really like to see this appear somewhere. It could be that it only gets used as a ui binding kind of construct but I've found it very intuitive / nice to have around ...Unless there are better / simpler ways of doing something like it with say FilteringTable (or whatever the next incarnation becomes) .

On 3/28/07, Tom Trenka <ttrenka@gmail.com> wrote:
> One other thing I might mention is that collections.Store right now supports
> a basic pathing feature, so that things in a hierarchical store *can* be
> used, including methods that take no parameters:
>
> field="someObject.someProperty "
> field="someObject.someMethod().someOtherMethod().someProperty"

>
> ...in this way, it supports both calculated expressions as well as the
> display of nested properties.  I don't remember seeing a plan for this in
> the read API, though I seem to remember it being discussed.  Is there any
> plans for this sort of field retrieval at all?
>
> trt

From Brian Skinner in reply to the above:

We don't yet have a plan for that sort of retrieval.

We've talked about that sort of feature many times now, but its been controversial and we've always deferred the discussion.  In particular, we've talked about adding a new datastore accessor method that could parse some sort of limited XPath expression or JavaScript dot-path notation.

I'd like to avoid using any string-based path description, like "book.author.name", or "book/author/name".  Using path expressions like that would mean that we need to start reserving special characters (like . or / ), which would then cause problems for any datastore that connects to a datasource which already uses those characters in its attribute names.
Comment from JaredJ:  If we reserve characters off, then it is just a matter for DS users to escape said characters in some fashion so that they are not parsed as a path.  This is not uncommon behavior, just look at the general escapes already used for things like JSON.  I'm not sure this is such a big issue in that respect.

In particular, I'm concerned about RDF datastores.  We already have a dojo.data.RdfStore, which we started using in OpenRecord last fall.  And OpenLink Software has written a preliminary dojo.data adapter for their  Virtuoso server.  In RDF, attributes are identified by URLs.  For example, the "title" of a web page would use the title attribute, which has the id "http://purl.org/dc/elements/1.1/title".

As an alternative, I've suggested using an array of attributes as the argument to any new path-based accessor method, like this:   var = store.getValueFromPath(book, ['author', 'name']);

skinner: Some questions, to try to understand how our path-based access would work...

(1) If we have this feature, is the plan that it will be consistent across datastores -- it will work the same way for an XML datastore and a JSON datastore?

jaredj:  From my perspective I think it would need to be consistent, otherwise it is useless to exploit in a generic fashion in widgets.

ttrenka: +1 on consistent

skinner: +1 on consistent

(2) Are we talking about "sub-attributes", where you have attributes that have sub-parts?  For example, say you have a single data item that represents a person, with attributes like:

{height:'1.65 meters', weight:'61 kg', name:{first:'Jaime', last:'Sommers'}}

then you could get the person's last name by doing:

var lastName = store.getValueFromPath(person, 'name.last');

(3) Or are we talking about "traversing items", where you traverse a series of items by getting the attribute values of each item along the way?  For example, think of a bookstore database, with data items representing books and authors.  Given a single item representing an author, you could ask for a list of of the titles of the related book items:

var titles = store.getValuesFromPath(stephenKing, 'books.title')

ttrenka: "I'd say that we are not traversing items"

(4) Or, are we talking about support for both "sub-attributes" and "traversing items", with a single unified API?

(5) If the attribute 'name' has sub-attributes 'first' and 'last', when you do store.getValue(person, 'name'), is the return value an item?

var lastName = store.getValueFromPath(person, 'name.last');
var something = store.getValue(person, 'name');
??? = store.isItem(something);

(6) Can "sub-attributes" contain item references as well as literals? For example:

var marge = "Marge Simpson";
var homer = store.newItem({name:{first:"Homer", last:"Simpson"}, spouse:marge});
var lisa  = store.newItem({name:"Lisa", parents:{mom:marge, dad:homer}});
    

(7) Can "sub-attributes" contain nested sub-sub-attributes, and so on?

(8) If we want our simple JsonItemStore to support "sub-attributes", how will that change the file format that it reads? For example, we currently have files that look like this:

{ identifier: 'key',
  items: [
    { key:'homer', name:'Homer Simpson', spouse:{reference:'marge'}},
    { key:'marge', name:'Marge Simpson', spouse:{reference:'homer'}},
  ]}

What would that file look like if Homer's name had sub-attributes for 'first' and 'last'? In the file format, how do we distinguish between name:{first:'Homer'} and spouse:{reference:'marge'}? What happens if you have a sub-attribute named "reference"?

(9) If we allow for "traversing items", does the API we're defining require that the datastore be able to traverse across any arbitrary set of items and attributes, or is the datastore only required to successful traverse across items that are already loaded into local memory? For example, drilling down within a single XML file, versus navigating through a huge server-side data graph (such as a social network on a web service like LinkedIn).

(10) Is each datastore required to provide its own implementation for this feature, or is there a single standard implementation that automatically works across all datastores, by building on top of the getValue() and getValues() methods?  If we do have a single standard implementation, does that code live in an abstract superclass that all datastores inherit from, or does the code live in a generic mixin file (like the dojo.data.core.nestedTransaction mixin, which adds beginTransaction and endTransaction methods to any datastore that supports the Write API)?

(11) Do we want to provide a method that allows you to get (a) just a single result value or (b) just a list of result values?  Or two separate methods, one that always returns single values and one that always returns lists?

(12) Are we talking about just simple paths, like "foo.bar.iggy" and/or "foo/bar/iggy"? Or are we talking about additional XPath style features, like:

"/foo"
"foo/bar[2]"
"foo/bar/text()"

(13) Are we talking about also supporting method calls via the path syntax? For example:

"foobar.someMethod()"

jesse:

My only experience with these kinds of expressions are when they've been embedded as html attributes, so for instance we might have a situation like:

<table id="datagrid">
   <thead>
      <th data="person.name">Name</th>
      <th data="person.dob" format="date">Date of Birth</th>
   </thead>
</table>

The grid would then just have a single string to throw at a data provider with no knowledge of the actual structure. You could get into function invocation semantics like checking for getDob/setDob getName/setName if the property paths weren't resolvable.

Of course things could get really silly really quickly, so it might be easier to start with supporting the most basic subset of property paths + get/set function detections. Another project I'm also currently working on does all of this and much much more, so it could be referenced as an example of how things could "get silly" wrt the expression syntax allowed. (which we probably don't want to do, as I've got the benefit of being able to do bytecode jit compilation of my expressions) http://www.ognl.org/2.6.9/Documentation/html/LanguageGuide/index.html .

Agenda Item 4:  Discuss sematics/expectations of store.newItem(). 

The Grid widget needs a defined behavior here, such as the names of the attributes of an item are the parameters of an anonymus object for the newItem call.  Right now I do not believe this is documented as what should be expected.  Should it be, or is this a poor assumption on my part?

skinner: In the dojo.data.core.Write API doc for newItem() we say "Sets the attributes of the new item based on the keywordArgs provided", and the documentation has an example that shows it being used like this:

    var kermit = store.newItem({name: "Kermit", color:[blue, green]});

I think that in any datastore, newItem() should take a single optional keywordArgs argument, with attribute names and values.  We might need to clarify that in the Write API documentation.

jaredj:  I think we do need to update the documentation, then.  It's unclear that it should be just attribute name/value pairs passed in; in effect an anonymous construction of the item.  This question came up from the work Bill was doing on grid, and how some prototype stores (such as an XmlStore?), were not following that pattern.

---

Minutes:

[12:47] * jared_j (i=chatzill@nat/ibm/x-0d2c7d907878fef5) has joined #dojo-meeting
[12:51] * peller (n=peller@pool-151-203-123-17.bos.east.verizon.net) has joined #dojo-meeting
[12:53] <jared_j> Hey, Peller. Quick question, have you done any of the async/deferred tests in the new framework?
[12:53] <peller> nope
[12:53] <peller> are there any for Deferred in there now?
[12:54] <jared_j> Looking now. I think I have JsonItemStore and SimpleBaseStore ported and working, Ijust need to port the unit tests as much as I can, so I need to find out how to do the aync calls.
[12:56] <jared_j> There is a tests/_base/Deferred, looking at it now. Not quite sure how to use this to do async tests, unfortunately.
[12:56] <peller> yup, looks like he just declares the functions inline
[12:56] <peller> you *could* set up functions in setup on tests.data.blah and delete them in teardown, but that's verbose
[12:57] <jared_j> Yeah, supposedly this should be easy to do. I just need an example. :)
[12:58] <peller> for the setup/teardown stuff?
[12:59] <jared_j> You can supposedly do it without setup and teardown
[12:59] <jared_j> I think Brian knows how. I'll ask him when he shows up.
[13:00] <jared_j> He was talking to Alex about it one time.
[13:00] <peller> cool
[13:00] <peller> yeah, you ought to be able to declare anything you need locally, including Deferreds and callback functions
[13:00] <peller> if you find it's easier to anchor them to something like tests.data and reuse them across your tests, that's another option
[13:01] * brian_skinner (n=brian_sk@adsl-67-127-58-153.dsl.pltn13.pacbell.net) has joined #dojo-meeting
[13:01] <jared_j> The callbacks vary per test, so I don't think it will, admittedly.
[13:01] <jared_j> Hey, Brian, we were just talking about you... Do you know how to do the async tetsts in the new framework without the setup/teardown?
[13:01] <brian_skinner> nope, i haven't yet tried out the new test frameword
[13:02] <jared_j> Crud. You were talking to Alex about it that one time, so was hoping you had gotten more info on how to do it.
[13:03] <jared_j> I'm trying to port the unit tests over. I have JsonItemStore working in the 0.9 split, I believe.
[13:03] <brian_skinner> i was eager to try it out, but then i fell behind with everything -- to much packing and moving junk to deal with
[13:03] <jared_j> Well, working as long as you're using data input, not url. Split still doesn't have the xhr port over yet.
[13:04] * ttrenka (n=ttrenka@c-24-131-182-228.hsd1.ma.comcast.net) has joined #dojo-meeting
[13:04] <ttrenka> heh
[13:04] <ttrenka> whoops, wrong window.
[13:05] <jared_j> Well, I know ChrisM really won't be here (ccmitchel_ is a zombie), as he's out on vacation. I also know Alex won't be here; he told me such last night.
[13:05] <jared_j> So, is there anyone else we should wait on?
[13:06] <brian_skinner> i'm not sure
[13:06] <brian_skinner> i don't know of anyone else who said they would be here
[13:07] <brian_skinner> is peller here?
[13:07] <peller> sorta
[13:07] <peller> about to hit the road in 5 minutes
[13:07] <brian_skinner> :-)
[13:08] <jared_j> Yeah, we're going to be pretty light today, so not sure how much we'll really get done. Some of the items probably require more imput than we have.
[13:08] <brian_skinner> yup
[13:08] <jared_j> But, we'll do what we can.
[13:08] <brian_skinner> okay
[13:08] <brian_skinner> lead on...
[13:08] <jared_j> If we have to stop, so be it. :)
[13:08] <robkinyon> will slightlyoff be in?
[13:08] <peller> ok, if there's anything we have to figure out to check in the code, let's do it up front
[13:08] <peller> I'm hoping Jared and I can get that done by week's end
[13:09] <jared_j> Okay, quick status! Been talking to Peller today about getting stuff merged in. So, yeah, that's #1. I'm currently porting it into the 0,.9 tree
[13:09] <jared_j> With one caveat, url based json loading is disabled (because xhr isnt' there yet)
[13:09] <brian_skinner> sounds good
[13:09] <jared_j> I've tagged that with FIXMEs to update it when we can. Looks like it is working, I just need to sort out the unit test stuff and toss Peller a patch
[13:10] <jared_j> Anyway, hwere's what I see going in first pass:
[13:10] <jared_j> All the API files (Read, write, Indentity, Notifications, Request), SimpleBaseStore, and JsonItemStore.
[13:10] <jared_j> utils of: sorter and filter.
[13:10] <jared_j> (As needed by JsonItemStore).
[13:10] <jared_j> And unit tests for all of that.
[13:11] <brian_skinner> sounds good
[13:11] <jared_j> Does anyone feel we need more than that for M1?
[13:11] <jared_j> If not, second minor nit. Layout changing. Here's what I'm going with unless people really hate it...
[13:11] <brian_skinner> we're using dojo.data.core.nestedTransaction in OpenRecord, but that could live in dojox if that seems better than dojo
[13:12] <jared_j> We could look at pushing that in fo r m2.
[13:12] <brian_skinner> peachy
[13:12] <jared_j> I'm mainly concerned with what I can test in M1 now. :)
[13:12] <brian_skinner> yup
[13:12] <jared_j> Given what is there.
[13:13] <jared_j> dojo.data.api.* for all abstract APIs, dojo.data for the stores (SimpleBaseStore, JsonItemStore). dojo.data.utils.* for all untility functions/files which can be shared by or mixed into stores.
[13:13] <peller> nestedTransaction in dojox sounds safer for now?
[13:13] <jared_j> Does anyone have an issue with that as the current layout?
[13:13] <peller> we can always move stuff into dojo.
[13:13] <brian_skinner> jared_j: that sounds great +1
[13:13] <peller> how much is in utils.*?
[13:13] <jared_j> peller: We'll need to see what it is/does in M2 and choose then, I think. I'm not sure what to do with it since I haven't seen it yet. :)
[13:14] <jared_j> Two files.
[13:14] <brian_skinner> peller: yup, dojox is find for now for nestedTransaction
[13:14] <jared_j> sorter functions based of Trenka's sort code, and filter functions that do basic pattern->regexp matching that agrees with the filter requirements we laid out earlier.
[13:14] <peller> I'd question where SimpleBaseStore belongs to indicate that it's a base class
[13:14] <jared_j> Where do you think, then, Peller?
[13:15] <jared_j> I wasn't sure on that one either.
[13:15] <peller> *shrugs*
[13:15] <jared_j> It's not really an API, and it's not a util.
[13:15] <brian_skinner> i'm inclined to have SimpleBaseStore in dojo.data
[13:15] <jared_j> And creating another package to hold one file seems funny. :)
[13:15] <brian_skinner> even though it isn't a usable store
[13:16] <brian_skinner> we could always move it later, without impacting too many people
[13:16] <peller> I suppose.
[13:16] <jared_j> Well, we can put it there for M1, and if we come up with something better in M2, we move it. I don't think we're locked in stone in placement in M1, are we?
[13:16] <peller> People will try to instantiate it,won't they?
[13:16] <peller> well, I don't know exactly what the rules are
[13:16] <peller> I'm sure stuff will move, but it's something to avoid
[13:17] <jared_j> If people read the API doc for SimpleBaseStore, they shouldn't be trying to instantiate it.
[13:17] <jared_j> // summary:
[13:17] <jared_j> // The SimpleBaseStore is designed to serve as an abstract base class for
[13:17] <jared_j> // other datastore implementations. The SimpleBaseStore should work well
[13:17] <jared_j> // for any datastore that can respond to a _fetchItems() call by returning
[13:17] <jared_j> // an array of all the found items that matched the query. The SimpleBaseStore
[13:17] <jared_j> // is not designed to work for datastores that respond to a fetch() call by incrementally ...
[13:18] <peller> hrm
[13:18] <peller> ok, it's just an internal. I'd love to see it hidden somehow
[13:18] <peller> sorry, I don't have a good answer
[13:18] <jared_j> Well, internal in what sense? Other DS implementors can extend from it.
[13:18] <brian_skinner> peller: put it in dojo.data.util?
[13:18] <brian_skinner> or in some other directory?
[13:19] <brian_skinner> including it in util doesn't seem like a bad option
[13:20] <jared_j> No, as it's a class people can use as a baseline not unlike the helper functions in there already people can import and use. It's not directly a utility, per se, but. Maybe we should rename util?
[13:20] <jared_j> Not sure what else to call it, though.
[13:21] <peller> maybe util, yeah
[13:21] <peller> maybe rename util
[13:21] <peller> what are the other 2 things in util?
[13:21] <brian_skinner> sorting and filtering
[13:22] <brian_skinner> and the nestedTransactions mixin could go there too
[13:22] <jared_j> Hm.
[13:23] <jared_j> dojo.data.helpers ?
[13:23] <peller> sure
[13:23] <jared_j> Little mroe generic than util.
[13:23] <peller> are data stores the only thing people need to instantiate?
[13:24] <jared_j> To use it? Should be.
[13:24] <brian_skinner> peller: i think so
[13:24] <jared_j> To use dojo.data, that is.
[13:24] <brian_skinner> certainly that's the case now
[13:24] <brian_skinner> we might someday have data types as well
[13:24] <peller> sounds reasonable, having not looked at that code :)
[13:24] <peller> keep going without me... I'm off in a minute
[13:24] <jared_j> Okay, I'l rename to helpers for now. If we have to rename it again, it doesn't affect much.
[13:25] <brian_skinner> a datastore might know how to deal with complex types like Color or Url or MailingAddress
[13:25] <brian_skinner> so someone using one of those datastores might want to instantiate a MailingAddress
[13:25] <jared_j> Thanks for stopping by, Peller!
[13:26] <brian_skinner> thanks peller!
[13:26] <peller> np. sorryI can't stay
[13:26] <peller> we may need a d.d.types someday
[13:26] <peller> later
[13:26] * peller (n=peller@pool-151-203-123-17.bos.east.verizon.net) Quit ()
[13:26] <jared_j> Hm.
[13:27] <jared_j> Maybe dojo.data.types? Well, it's not really a 'type', either. Blah. :)
[13:27] <jared_j> I don't really have a major liking for any of the locations so far.
[13:28] <jared_j> ttrenka: You here? Any suggestions?
[13:28] <ttrenka> i haven't been paying attention, what's the issue?
[13:29] <jared_j> Just trying to sort out locations a bit. We have an abstract base class that a lot of stores can use to implement a chunk of the base fetch functionality for them. Not sure where to put it in the hierarchy such that it makes sense.
[13:29] <jared_j> So far we have:
[13:29] <jared_j> dojo.data.api for all purely abstract definitions of the API.
[13:29] <jared_j> dojo.data for all concrete impls.
[13:29] <ttrenka> ok.
[13:29] <jared_j> and dojo.data.util for all utility functions stores can share.
[13:30] <ttrenka> are you expecting that people implementing APIs will be forced to mixin or inherit using code from the api directory?
[13:30] <jared_j> From the API dir? No. It's purely for documentation fo the interface, really. At least that's how it is now.
[13:31] <ttrenka> ok.
[13:31] <brian_skinner> and how we hope it will stay
[13:31] <ttrenka> are you expecting people to have to inherit or mixin SimpleStore in their own store implementations?
[13:31] <jared_j> For a lot of stores, yes.
[13:31] <ttrenka> then to be honest, I would keep it in dojo.data
[13:32] <ttrenka> and I'd make sure that you could actually *use* it as a simple store
[13:32] <jared_j> You can't.
[13:32] <ttrenka> any reason why not?
[13:32] <jared_j> It provides some of the impl, not all.
[13:32] <jared_j> Because the impls control the format of the items, etc.
[13:32] <brian_skinner> they don't *have* to inherit from SimpleBaseStore, but it does a lot of work for them if they choose to
[13:32] <ttrenka> forgive my ignorance. Then what's the point of it?
[13:33] <jared_j> It can take care of handling some of the work of the callbacks and so on. It's to allow people to get up and running with their own stores with less work.
[13:33] <brian_skinner> ttrenka: SimpleBaseStore provides a lot of basic functionality, so that implementing some new datastore is much easier
[13:33] <ttrenka> why not make it a complete implementation then?
[13:33] <jared_j> If their stores meet the critera as defined in its symmary and description
[13:34] <brian_skinner> because then it would have to include a lot of cruft that the subclasses would never use
[13:34] <ttrenka> such as?
[13:34] <brian_skinner> we'd have to decide where it was reading data from
[13:34] <brian_skinner> and what in-memory format to use to represent the items
[13:34] <jared_j> How items are formatted (which is store data dependent).
[13:34] <ttrenka> ok
[13:35] <ttrenka> so what's to stop it from, say, using a JSON array? (forgetting for now the fact that you have a JsonStore)
[13:35] <brian_skinner> well, that's pretty much what JsonItemStore does
[13:35] <jared_j> Nothing, but some store impls may not want to store it that way, they may want to use an XML dom.
[13:35] <ttrenka> see, the point I'm getting at is that it seems like it's a partial implementation that can't be used at all other than for mixin or for API reference
[13:36] <brian_skinner> yup, that's what it is
[13:36] <ttrenka> at which point I'd say it's not a store but a mix-in, and probably you shouldn't call it Store.
[13:36] <ttrenka> and stick it in util with the other mixins.
[13:36] <jared_j> Fair enough.
[13:36] <jared_j> What do you think, Brian?
[13:37] <brian_skinner> yup, fair enough -- i'm not sure what would be involved in turning it into a mixin, but if that's doable then it seems like a good idea
[13:37] <ttrenka> otherwise I'd say make it a full, simplistic implementation and put it in data.
[13:37] <jared_j> Let me see what it takes to make it a mixin.
[13:37] <brian_skinner> i think making it into a full, simplistic implementation would be hard to do in a useful way
[13:37] <jared_j> And then it does fit nicely into util.
[13:37] <jared_j> brian_skinner: agreed.
[13:38] <ttrenka> i've only glanced over the code that still in the trunk, so I wouldn't really know
[13:38] <jared_j> Really, JsonItemStore is a full, simplistic, impl.
[13:38] <ttrenka> I do have some issues with names though.
[13:38] <ttrenka> method names mostly
[13:38] <jared_j> Such as?
[13:38] <ttrenka> but I'm sure that will resolve itself.
[13:38] <ttrenka> well, for one, the nestedTransaction methods don't follow the style guide at all
[13:39] <brian_skinner> ttrenka: thanks for looking over the code
[13:39] <ttrenka> it should be .begin, .end, and .commit (IIRC)
[13:39] <jared_j> Ah, okay, I haven't looked at that file myself. So I don't know what they look like.
[13:39] <ttrenka> not beginTransaction...
[13:39] <ttrenka> etc.
[13:39] <brian_skinner> ttrenka: nestedTransaction has had very little peer review
[13:39] <ttrenka> i didn't look too close, that one jumped out at me and I remember all the back and forth on find and fetch, so I keep my trap shut about that.
[13:40] <ttrenka> brian_skinner: sure, i can understand that
[13:40] <brian_skinner> but, i think changing the names to just .begin and .end could be confusing
[13:40] <ttrenka> transaction.begin? transaction.end?
[13:40] <brian_skinner> because you never instantiate a transaction object
[13:40] <ttrenka> that doesn't really matter
[13:40] <brian_skinner> nestedTransaction is just a mixin for a datastore
[13:41] <ttrenka> hmmm
[13:41] <brian_skinner> so the code would look like...
[13:41] <brian_skinner> store.begin()
[13:41] <jared_j> So once you mix it in, it becomes: store.beginTransation().
[13:41] <ttrenka> that wasn't explicit in the copy I reviewed
[13:41] <brian_skinner> store.newItem({name:'foo'})
[13:41] <brian_skinner> store.end()
[13:41] <ttrenka> I'd say at that point it should also be in util, no?
[13:41] <jared_j> ttrenka: That's the plan.
[13:41] <brian_skinner> yup, we've just been talking about putting it in util
[13:41] <ttrenka> do you guys have any idea of how that's going to work yet?
[13:42] <brian_skinner> how what's going to work?
[13:42] <ttrenka> because I could see attaching a transaction object to a store as the mixin
[13:42] <ttrenka> transactions.
[13:42] <jared_j> I don't. I haven't been involved in any discussions related to them.
[13:42] <ttrenka> brian?
[13:42] <brian_skinner> we haven't talked about having a transaction object
[13:42] <ttrenka> ok
[13:43] <brian_skinner> we are using the nestedTransaction mixin in OpenRecord, as a mixin with the JsonItemStore
[13:43] <ttrenka> because I could see it working something like this:
[13:43] <ttrenka> store.begin(new Transaction());
[13:43] <ttrenka> where you start an actual transaction object that you're pushing actions into.
[13:43] <ttrenka> but this is still just conjecture, so...
[13:44] <brian_skinner> what problem does that solve?
[13:44] <ttrenka> storing actions for delayed execution?
[13:44] <ttrenka> i'm thinking it through as I go so it may not make sense.
[13:44] <brian_skinner> can't a datastore do that without exposing it in API?
[13:44] <brian_skinner> in the API
[13:44] <ttrenka> I suppose that's the real question, isn't it
[13:45] <ttrenka> how much is exposed and how much isn't
[13:45] <brian_skinner> yup, that's what we've wrestled with in many parts of the API ;-)
[13:45] <ttrenka> i wouldn't mind seeing how you've implemented it but we'll leave it and come back to it?
[13:46] <brian_skinner> okay
[13:46] <ttrenka> for some reason I have a strong feeling that mixing that directly onto a store will cause problems but I couldn't tell you what.
[13:47] <brian_skinner> okay, if you have more time to think about it, it'd be good to hear more about what problems it could cause
[13:47] <brian_skinner> anyway, for the time being Jared will leave nestedTransaction out of dojo core
[13:48] <brian_skinner> needs more review/discussion
[13:51] <jared_j> Okay. Well, then I'll go with the basic layout mentioned above and try to make SimpleBaseStore into a mixin that stores just pull in for the few function impls they get from it and throw it in util. Cool. So, shall we move on?
[13:51] <brian_skinner> yup, sounds good
[13:51] <brian_skinner> thanks jared_j
[13:51] <ttrenka> yah
[13:52] <ttrenka> i need to reboot quick, brn
[13:52] <ttrenka> brb
[13:52] * ttrenka (n=ttrenka@c-24-131-182-228.hsd1.ma.comcast.net) Quit ()
[13:52] <jared_j> Waiting for ttrenka to get back...
[13:53] <brian_skinner> okay
[13:53] <jared_j> The next item is one he's commented on in mail, so that's why I'm holding.
[13:55] * ttrenka (n=ttrenka@c-24-131-182-228.hsd1.ma.comcast.net) has joined #dojo-meeting
[13:56] <jared_j> Ah, okay.
[13:56] <jared_j> Agenda Item 3 Nested child items. (I'm not sure we have everyone we would want to have to discuss this now).
[13:56] * ttrenka (n=ttrenka@c-24-131-182-228.hsd1.ma.comcast.net) Quit (Client Quit)
[13:56] <jared_j> Or not.
[13:57] <jared_j> How's the move going, btw, Brian?
[13:57] <jared_j> (As an aside while we wait a minute or two.)
[13:57] <brian_skinner> we're making progress on the move
[13:57] <brian_skinner> mostly packed now
[13:57] * ttrenka (n=ttrenka@c-24-131-182-228.hsd1.mn.comcast.net) has joined #dojo-meeting
[13:57] <brian_skinner> we do the actual move on Thursday and Friday
[13:57] <ttrenka> sorry about that
[13:58] <ttrenka> something goofy with Colloquy
[13:58] <brian_skinner> with luck i'll have DSL again by Monday
[13:58] <jared_j> brian_skinner: Cool. I hate moving. :P
[13:58] <jared_j> Okay, back: Agenda Item 3 Nested child items. (I'm not sure we have everyone we would want to have to discuss this now).
[13:58] <brian_skinner> i used to like it, but this time it's seeming like a *lot* of work
[13:59] <ttrenka> is this the path access item?
[13:59] <brian_skinner> okay, i just added a couple more questions to the big long list: http://dojo.jot.com/2007-04-03
[13:59] <brian_skinner> yup -- path access
[13:59] <jared_j> I was under the original impression that item atrributes were supposed to be considered simple. Yes that one, ttrenka
[13:59] <ttrenka> ok
[14:00] <ttrenka> reading.
[14:00] <ttrenka> I'd agree with jared_j that it would have to be consistent
[14:00] <brian_skinner> +1
[14:00] <ttrenka> I'd also say that we are not traversing items
[14:01] <ttrenka> so here's what I pulled in collections.Store, if it helps
[14:01] <ttrenka> basically it's a one-way traversal that assumes the final destination will be translateable to a string via .toString
[14:02] <ttrenka> or else it will return null
[14:02] <ttrenka> for instance, in list item (6)
[14:02] <ttrenka> var homer = store.newItem({name:{first:"Homer", last:"Simpson"}, spouse:marge});
[14:02] <ttrenka> if I were then to do something like this:
[14:02] <ttrenka> field="spouse"
[14:03] <ttrenka> the final output would probably be Object [object], unless spouse implemented toString
[14:03] <ttrenka> well, actually that's a bad example because that's a string to begin with
[14:03] <brian_skinner> :-)
[14:03] <ttrenka> ...say spouse was a Spouse object.
[14:03] <brian_skinner> okay
[14:03] <ttrenka> then what I said makes sense.
[14:03] <jared_j> Well, today that's what you would get from: store.getValue(homer,"spouse");
[14:04] <jared_j> I believe, no?
[14:04] <ttrenka> probably.
[14:04] <jared_j> Any toplevel attribute in an object is accessable via getValue()
[14:04] <jared_j> Whatever it is.
[14:04] <ttrenka> now, say spouse had this structure:
[14:04] <ttrenka> {name:{first:"Marge", last:"Simpson"}}
[14:05] <ttrenka> you'd want to do something like:
[14:05] <ttrenka> store.getValue(homer, "spouse.name.first");
[14:05] <jared_j> Okay, hmm.
[14:05] <ttrenka> that's the basic idea.
[14:05] <brian_skinner> and then what happens if you do this:
[14:06] <brian_skinner> store.getValue(homer, "spouse.name");
[14:06] <ttrenka> but...we wouldn't want to get into other axes, and we don't want to get into predicates
[14:06] <brian_skinner> what's the return value?
[14:06] <ttrenka> object [Object]
[14:06] <brian_skinner> and if you do this:
[14:06] <ttrenka> unless spouse.name happens to implement getValue or toString
[14:06] <brian_skinner> store.isItem(store.getValue(homer, "spouse.name"));
[14:06] <jared_j> brian_skinner: false, I would think.
[14:07] <brian_skinner> okay
[14:07] <jared_j> Because that's not directly an item.
[14:07] <ttrenka> hmm
[14:07] <jared_j> Unless it was really an item in the store.
[14:07] <brian_skinner> that would be consistent with ttrenka's earlier answer, saying that we're not talking about traversing items
[14:07] <ttrenka> one of the advantages of this is that all JS properties are accessible via the selector at that point.
[14:08] <ttrenka> let me give you another example.
[14:08] <ttrenka> say I had something like this:
[14:08] <ttrenka> { name: {last:"Simpson",first:"Marge"}, accounts:[] }
[14:08] <ttrenka> where accounts is an array
[14:08] <ttrenka> ...and say somewhere along the line, 8 accounts (whatever that might be) are added.
[14:09] <ttrenka> this would be valid:
[14:09] <ttrenka> store.getItem(homer, "spouse.accounts.length");
[14:09] <brian_skinner> getItem?
[14:09] <ttrenka> I don't remember what your method is.
[14:09] <ttrenka> getValue
[14:09] <brian_skinner> or did you mean getValue?
[14:09] <brian_skinner> okay
[14:10] <jared_j> That would return 8, I would think.
[14:10] <ttrenka> exactly
[14:10] <brian_skinner> is that better than just doing this:
[14:10] <brian_skinner> store.getValues(homer, "spouse.accounts").length
[14:11] <ttrenka> yeah, it is.
[14:11] <jared_j> Reasoning?
[14:11] <brian_skinner> the current documentation says that:
[14:11] <ttrenka> for one thing, I can't really define a column in a grid with the latter.
[14:11] <brian_skinner> getValue *always* returns a single value
[14:11] <brian_skinner> getValues *always* returns an array
[14:11] <ttrenka> yeah, but the accounts property/attribute here is still a single value--it's just an array object.
[14:12] <ttrenka> in theory I could even do this:
[14:12] <ttrenka> getValue(homer, "spouse.accounts")
[14:12] <jared_j> And you'd get back the array.
[14:12] <ttrenka> and I'd get back a comma-delimited list of all the elements in accounts
[14:13] <ttrenka> (if we assume the string cast)
[14:13] <jared_j> Ah, right, you expect the item to always be cased to a string.
[14:13] <ttrenka> well, not necessarily but that's another story :)
[14:13] <ttrenka> I'd say that widgets probably will
[14:14] <brian_skinner> but that story does impact this story
[14:14] <jared_j> If you don't assume that, then how is this different?
[14:14] <ttrenka> I think it depends on how the value is being consumed
[14:14] <jared_j> store.getValues(homer, "spouse.accounts").length or store.getValues(homer, "spouse.accounts.length")
[14:14] <jared_j> Both would return you an 'int', no?
[14:14] <jared_j> Well, number.
[14:14] <ttrenka> not sure but I thought that getValues was a different action than getValue.
[14:15] <brian_skinner> ttrenka: yes, it is
[14:15] <jared_j> Er, wait, sorrt.
[14:15] <jared_j> Sorry
[14:15] <ttrenka> using this example:
[14:15] <ttrenka> store.getValuesFromPath(stephenKing, 'books.title'
[14:15] <brian_skinner> getValue always returns the first value, if there's more than one value
[14:15] <ttrenka> I'm assuming here that I'm getting an array of titles, based on an array of books.
[14:15] <jared_j> store.getValue(homer, "spouse.accounts").length or store.getValue(homer, "spouse.accounts.length");
[14:15] <ttrenka> right?
[14:16] <jared_j> brian_skinner: Ah.
[14:16] <brian_skinner> ttrenka: yes, an array of titles, in that example
[14:16] <ttrenka> the array of books is part of the data structure
[14:16] <ttrenka> title is an attribute of a book
[14:16] <ttrenka> right?
[14:16] <brian_skinner> title is an attribute of a book
[14:16] <ttrenka> ok
[14:17] <ttrenka> that makes sense.
[14:17] <brian_skinner> books is an attribute of author
[14:17] <ttrenka> but then this doesn't:
[14:17] <brian_skinner> but now we're traversing items
[14:17] <ttrenka> store.getValues(homer, "spouse.accounts").length
[14:17] <ttrenka> right, I'm just trying to clarify the differences
[14:18] <ttrenka> so this:
[14:18] <brian_skinner> i got lost -- that last example doesn't what?
[14:18] <ttrenka> store.getValues(homer, "spouse.accounts.length")
[14:18] <ttrenka> is not a traversal
[14:18] <ttrenka> length is an attribute of the accounts array object
[14:18] <brian_skinner> well, it may be traversal, if the value of spouse is an item
[14:18] <ttrenka> (it is a bit confusing)
[14:19] <jared_j> Yes it is. I think I' a bit lost, I'm afraid.
[14:20] <ttrenka> I think it depends on how you define "item".
[14:20] <jared_j> I define it as any uniquely addressable top-level data object
[14:21] <jared_j> Something you can pass to getValue, or isItem().
[14:21] <ttrenka> yes, but is that a native JS object, or something else?
[14:21] <brian_skinner> ttrenka: that depends on the datastore
[14:21] <ttrenka> ok
[14:21] <jared_j> Could be anything, realisically, JS, XML dom, whatever.
[14:21] <brian_skinner> in our existing OpmlStore, each item is an XML DOM node
[14:22] <ttrenka> brian_skinner: so then you're saying the path accessor code has to be implemented by every store author because it's unique to that store.
[14:22] <brian_skinner> scott plans to represent items as arrays, for the TurboWidgets grid
[14:22] <brian_skinner> ttrenka: not necessarily
[14:22] <ttrenka> but most likely?
[14:23] <brian_skinner> we might be able to implement the path accessor code as a standard mixin, built on top of the existing getValue and getValues methods
[14:23] <ttrenka> you'd have to implement a version for OpmlStore, for instance.
[14:23] <jared_j> There could be mixin helpers for some of them I would think (js objects, XML dom node, etc).
[14:23] <ttrenka> just out of curiosity
[14:23] <brian_skinner> given that OpmlStore already implements getValue and getValues, then the new path accessor mixin would just work
[14:23] <ttrenka> why did we decide that there would be no conversion to a single internal format again?
[14:24] <jared_j> I believe the rason was cost and efficientcy of the store in its accessors. (From history I was told)
[14:25] <ttrenka> ok. I think I never bought that argument but I seem to remember I was in the minority
[14:25] <brian_skinner> allows for more performance tuning
[14:25] <brian_skinner> allows for fast XML stores for people who are already using XML transforms
[14:25] <brian_skinner> allows the TurboWidgets guys to use arrays instead of objects for large datasets
[14:26] <brian_skinner> allows simple stores like JsonItemStore to use a fairly intuitive JSON representation
[14:26] <ttrenka> ...and effectively forces us to write several custom versions of a path accessor setup, if we try to go that route.
[14:26] <ttrenka> I can say from experience with Filtering that I needed it almost immediately
[14:27] <ttrenka> and I know I wrote that code because others really needed it too.
[14:27] <brian_skinner> ttrenka: what sorts of things did you use it for?
[14:27] <ttrenka> ok, so here's what spawned the whole FilteringTable to begin with
[14:27] <brian_skinner> if we have a few real world examples to guide us, that will help in making decisions
[14:27] <ttrenka> (it may help)
[14:27] <ttrenka> I was working on a project where we were trying to represent parts of an object structure in 2D grids (i.e. table)
[14:28] <ttrenka> the data we were receiving was in JSON format but the structure of it was being determined by Hibernate (in essence)
[14:28] <ttrenka> (it's actually an open source project now called Bodega, think it's on Source Forge)
[14:28] <ttrenka> ...so the first version, which was SortableTable, was a flat read.
[14:28] <ttrenka> no nested path accessor.
[14:29] <ttrenka> what ended up happening was that I had to translate data I received to a specific, single level format and use that to populate Sortable.
[14:29] <ttrenka> ...because I wrote the path accessor code with collections.Store, was then able to (instead) to simply point FilteringTable right at the original objects.
[14:30] <ttrenka> no translation or chagne.
[14:30] <ttrenka> change.
[14:30] <ttrenka> I'd show you the app but it's been locked behind a lot of legal wrangling and probably won't see the light of day
[14:31] <ttrenka> anyways
[14:31] <brian_skinner> i'd be curious just to see an example of what the raw JSON looked like, and what different paths you ended up using
[14:31] <ttrenka> the point is that by having that accessor, I was able to truly separate the view from the data.
[14:31] <ttrenka> if I had an example, I'd show you
[14:31] <brian_skinner> here's an idea...
[14:31] <ttrenka> it was pretty extensive though
[14:32] <brian_skinner> what about doing that path translation step *behind* the datastore, instead of in front of it
[14:32] <ttrenka> let me boot up the vm and see if I saved any of the structures.
[14:32] <jared_j> What do you mean b y behind it, brian?
[14:32] <brian_skinner> instead of having the view code ask the datastore for store.getValues(item, 'foo.bar.baz')
[14:32] <ttrenka> I think he means setting up accessor definitions as virtual attributes.
[14:33] <brian_skinner> instead you tell the datastore something like this:
[14:33] <brian_skinner> datastore, you're going to read from this ugly raw JSON file, and i want you to treat all the objects at 'foo.bar.baz' as being items
[14:34] <brian_skinner> does that make sense?
[14:35] <ttrenka> brian_skinner: sorry, doesn't look like I have any of the examples
[14:35] <brian_skinner> ttrenka: thanks for looking
[14:35] <jared_j> brian_skinner: No. I'm missing something.
[14:36] <ttrenka> np--but I can tell you that I'm talking about some deeply nested entities
[14:36] <brian_skinner> jared_j: okay, i need to make a longer example
[14:36] <ttrenka> allow me?
[14:36] <brian_skinner> please
[14:36] <jared_j> Ok.
[14:37] <ttrenka> jared_j: I think what he's suggesting is that instead of the consumer asking for something using a complex path, we instead set up the store to present a user with a simple path, and internally to the store let that simple path be an alias for the more complex one
[14:37] <ttrenka> another words, a widget might ask for:
[14:37] <ttrenka> store.getValue(homer, "foobar");
[14:37] <jared_j> brian_skinner: Is this going to the idea of having items used as attributes on an input?
[14:37] <ttrenka> and the store would say to itself "oh yeah, that really means foo.bar.baz"
[14:38] * KindSol (n=chatzill@ip68-6-79-24.sb.sd.cox.net) has joined #dojo-meeting
[14:38] <brian_skinner> jared_j: nope, that's a separate idea
[14:38] <jared_j> So, is ttreka's explanation what you meant?
[14:38] <ttrenka> brian_skinner: that sound right?
[14:39] <jared_j> I understand what ttrena is suggesting.
[14:39] <jared_j> Even if I can't spell his handle worth a crud. :P
[14:39] <ttrenka> and for that you say pay!
[14:39] <ttrenka> s/say/shall
[14:40] <brian_skinner> ttrenka: yup that's the idea -- or, actually i was thinking of a slightly different varient, in which the datastore actually did the transformation form 'foo.bar.baz' to "foobar" at the time the file is read, rather than at the time the getValue() call is made
[14:40] <ttrenka> ok
[14:40] <ttrenka> but either way you'd be setting it up so that the store handles the alias.
[14:40] <brian_skinner> yup
[14:40] <ttrenka> personally I wouldn't be happy with that solution but it would work
[14:40] <ttrenka> i'm not a fan of anything that hides stuff, but you knew that already
[14:41] <brian_skinner> okay, i'm just brainstorming -- not pushing the idea
[14:41] <ttrenka> no, it's not a bad idea
[14:41] <ttrenka> certainly it'd be easier on the store implementors.
[14:41] <ttrenka> and at that point we wouldn't have to define an accessor spec, which is what it would come down to.
[14:41] <jared_j> Yes, setting up virtual maps to attributes, effectively, JSON stransromation upon read of the file.
[14:42] <ttrenka> (if we did the path accessor)
[14:42] <brian_skinner> i'm just worried about the complexity we get into if we allow path-based access at the Read API level
[14:42] <ttrenka> so then, what would we do? Provide a method called "createAlias" or something, that took a function that would do the actual translation?
[14:43] <brian_skinner> needing to come up with a proposal that answers all the different questions posed -- http://dojo.jot.com/2007-04-03
[14:43] <ttrenka> store.createAlias("foobar", function(item){
[14:43] <ttrenka> return item.foo.bar.baz;
[14:43] <ttrenka> });
[14:44] <brian_skinner> we could do something just like that -- but I think it can be datastore-specific -- i don't think we actually need to require createAlias as part of the standard Read API
[14:44] <ttrenka> ok
[14:44] <ttrenka> i think we'll probably want to though
[14:44] <jared_j> If we don't have a way to define it, then how do we make sure it's consistent?
[14:45] <brian_skinner> good point
[14:45] <ttrenka> you'd be amazed at how many people asked for tweaks to that when I first wrote it for collections.Store.
[14:46] <jared_j> No I wouldn't. People have a habit of wanting it 'your' way ... just *slightly* different. :)
[14:46] <ttrenka> heh
[14:46] <ttrenka> but that would also allow for calculated values
[14:46] <brian_skinner> yup, that'd be good too
[14:46] <ttrenka> it means a little bit more store setup but I think that's ok.
[14:46] <brian_skinner> but it could be optional store setup
[14:47] <ttrenka> right
[14:47] <brian_skinner> a simple CsvStore wouldn't need any setup at all
[14:47] <ttrenka> and it wouldn't affect the underlying data.
[14:47] <jared_j> store.createAlias("fullName", function(item) { item.first + " " + item.last;});
[14:47] <ttrenka> that's the big one.
[14:47] <ttrenka> right
[14:47] <jared_j> Or whatever.
[14:48] <brian_skinner> but, if do want the store.createAlias() to have a datastore-independent API, then
[14:48] <ttrenka> store.createAlias("numAccounts", function(item){ return item.debitAccounts.length + item.creditAccounts.length; });
[14:48] <brian_skinner> we can't have function(item) { item.first + " " + item.last;}
[14:48] <ttrenka> we can say this:
[14:48] <ttrenka> createAlias(alias, getterFunction);
[14:48] <brian_skinner> we can't assume a JSON data representation
[14:48] <ttrenka> as the API.
[14:48] <brian_skinner> needs to work for XML too
[14:48] <ttrenka> I think that's what we really mean.
[14:48] <brian_skinner> so
[14:49] <ttrenka> ok, here's an XML one:
[14:49] <jared_j> Fine. function(item) {return this.getValue(item,"first") + this.getValue(item, "last"}); :)
[14:49] <brian_skinner> jared_j: +1
[14:49] <ttrenka> store.createAlias("foobar", function(node){ return node.nodeValue; });
[14:49] <brian_skinner> ttrenka: but that's still not datastore independent
[14:49] <brian_skinner> that one won't work for a JSON store
[14:49] <ttrenka> at that point it doesn't need to be
[14:49] <ttrenka> all we are saying is:
[14:50] <ttrenka> createAlias requires a getterFunction
[14:50] <jared_j> If stores wanted to alias up front, they know about their inetrnal structures, they could construct aliases in their constructore, or whatever.
[14:50] <jared_j> constructor, sheesh.
[14:50] <ttrenka> the function will be passed an item and you have to do something with it.
[14:50] <ttrenka> what *kind* of item is really dependant on the store.
[14:50] <brian_skinner> so then why have a standard store.createAlias() method as part of the API, if it's not intended to be used in any standard way
[14:50] <ttrenka> um
[14:50] <ttrenka> that is a standard way?
[14:51] <brian_skinner> if the getter function is store-dependent
[14:51] <ttrenka> the signature of it isn't
[14:51] <jared_j> I think brian's point is a store user doesn't know anything about the structureof an item, so how can the user call createAlias.
[14:51] <ttrenka> signature of the function is store independant.
[14:51] <ttrenka> I think that's probably a bogus argument though
[14:52] <ttrenka> if I'm creating an alias, that means I probably have a good idea of the structure of an item
[14:52] <ttrenka> and I probably have a *real* good idea of the underlying data as well.
[14:52] <brian_skinner> having just the signature be standard doesn't buy you much, practically speaking, if you can't swap one datastore out for another
[14:52] <ttrenka> you'd have to swap the functions anyways
[14:53] <brian_skinner> so then why have a standard signature?
[14:53] <ttrenka> so that you could implement it as part of the read API?
[14:53] <brian_skinner> but what problem does that solve?
[14:53] <ttrenka> its' not like we'll be providing the getter functions, right?
[14:54] <ttrenka> all we're doing is providing a way for a consumer to delve deeper into the data structure
[14:54] <brian_skinner> right, but with the getter functions, you know that you can call them the same way on any datastore
[14:54] <ttrenka> how do you envision the getter functions working?
[14:55] <ttrenka> I think I have a good idea how--they'd be called by store.getValue
[14:55] <brian_skinner> oops, sorry -- ignore my last comment -- i got confused
[14:55] <ttrenka> no worries
[14:56] <ttrenka> I see these getters working similar to the way you'd use array.map
[14:56] <brian_skinner> unfortunately, i need to go soon
[14:56] <ttrenka> me too
[14:56] <brian_skinner> and i'll probably be offline until next week
[14:56] <ttrenka> you said you were moving?
[14:57] <brian_skinner> hopefully DSL will be up and running at my new place by Monday
[14:57] <ttrenka> good luck with it
[14:57] <brian_skinner> yup, thanks!
[14:57] <ttrenka> jared_j, did you want to keep talking about this?
[14:57] <jared_j> I need to get going soon too. We've thrown ideas on the table and answered other issues. Overall, fairly productive.
[14:57] <ttrenka> ok
[14:57] <ttrenka> talk to you all soon, then!
[14:58] * ttrenka (n=ttrenka@c-24-131-182-228.hsd1.mn.comcast.net) Quit ()
[14:58] <brian_skinner> bye!
[14:58] <jared_j> I see both points of view, I just need to digest a bit on it and think.
[14:58] <brian_skinner> that sounds good
[14:58] <jared_j> I understand what ttrenka is getting at, I'm just not sure the best way to manage it yet.
[14:58] <brian_skinner> we can talk about it more at the next meeting
[14:58] <jared_j> And get something common.
[14:58] <brian_skinner> or maybe somebody can write up a proposal
[14:58] <jared_j> The key is common.
[14:59] <brian_skinner> yup
[14:59] <brian_skinner> i resisted this whole path thing for too long
[14:59] <jared_j> Hopefulyl when everyone gets back from being out on whatever, it'll help too.
[14:59] <brian_skinner> yup
[14:59] <jared_j> And btw, I *think* XmlStore actually implemented XML walking as js path style.
[14:59] <brian_skinner> cool
[14:59] <jared_j> I'll need to follow up with the folks working on that store.
[15:00] <jared_j> Becuase this was discussed, but I can't remember all the particulars on it, unfortunately.
[15:00] <brian_skinner> i'll be curious to look at the XML store
[15:00] <brian_skinner> anything else we need to talk about today?
[15:01] <brian_skinner> can we sign off on the newItem() semantics in under 30 secons?
[15:01] <brian_skinner> seconds?
[15:01] <jared_j> Last item was just should we clarify the doc that the format expected for newItem is a set opf attribute/value pairs that define the item?
[15:01] <jared_j> Basically one to one map, generally
[15:01] <brian_skinner> yup
[15:01] <brian_skinner> var kermit = store.newItem({name: "Kermit", color:[blue, green]});
[15:01] <jared_j> if getValue(item, "foo"), means you do: newItem({foo:bar}), then we're probably fine.
[15:01] <brian_skinner> yup
[15:02] <jared_j> That's needed by grid for a consistent way to create a new item.
[15:02] <jared_j> Godo enough
[15:02] <brian_skinner> sounds good
[15:02] <jared_j> Good luck moving.
[15:02] <brian_skinner> thanks!
[15:02] <jared_j> Thank you!