• Data Binding Update (IBM)
  • Jared Jurkiewicz will present work since 3D2 on a data binding framework (MVC) for dojo.data.  This will easily take the hour scheduled for this meeting 
  • Present and discuss scenarios/use cases for data binding
    • Use Case link: http://dojo.jot.com/WikiHome/DojoDataUseCases
      • Note the use cases are ordered based on complexity.
      • Goal: Agree on scope of work
        
      • Note: Requirements and design information will be transferred to the Jot wiki and linked from here prior to this meeting
  • Present candidate api's and examples for data binding
    • Programmatic API prototype: http://dojo.jot.com/WikiHome/DataBindingAPI
    • Goal: Begin detailed api review of programming model (declarative and programmatic) in follow-on meetings.
• Discuss issues:
  • Notation concerns on individual items.  (JS dot versus XPath versus dojo.query)
  • Discuss namespace assignmet for dojo.data and the associated binding APIs
• Discuss Requirements for Dojo Data 0.9
• Discuss dojo.data meeting schedules going forward

   

---

Minutes:

• The meeting began at 4:00 PM EST US.  It ended at 6:00 PM EST US.
• People present:
  • Brian Skinner (brian_skinner)
    
  • Christopher Mitchell (jaxsphere)
  • Jared Jurkiewicz (jared_j)
  • Eugene Lazutkin (uhop)
  • Adam Peller (peller)
• Items covered:
  • The declarative use-cases were gone through
    • General agreement was reached that the use-cases covered much of what dojo.data needs to accomplish.
    • Use cases still required are:
      • Simplified table/tree binding.
      • Table data -> datastore binding, not just loading data from the datastore into a table.
      • Handling paged data in a complex widget such as a table/grid    
• • A prototype code zip file was sent out to those present which demonstrates much of the use-cases discussed.
  • Concerns over the format of 'path' binding (item lookup) in datastore was raised again.  Being specific to the data in the datastore limits the generic usability of the datastore interface.
  • Tentative agreement was reached on the namespaces where the new data binding apis should go (dojo for the core programmatic, dojox for the declarative markup wrappers and so on).  This needs to be reviewed by the dojo elders.
• Actions:
  • Jared to provide a new zip containing the namespace factoring for distribution to the wider dojo community for review.
  • The use-cases will be updated further in hopes of fleshing out other issues.
  • The idea of providing 'simple' table and tree binding shortcuts will be examined and hopefully by the next meeting with have a tentative proposal for how to handle them.
  • Flesh out the declarative API (attributes and meanings).
  • Rename ControllerWidget to something mor meaningful.  It's not really a widget.  Name decided on betweej jaxsphere and jared_j later that night: Trigger.  Both binding and actions inherit from it; it is what implements the 'trigger' points that activate a data bind or method/data action.
    
  • Establish time for the next dojo.data meeting to start going through code as well as reviewing the programmatic API in more detail.
    

---

Transcript:

    [12:29] * dmachi (n=dmachi@pool-72-66-189-43.ronkva.east.verizon.net) Quit ()
[13:54] * brian_skinner (n=brian_sk@adsl-71-141-100-192.dsl.snfc21.pacbell.net) has joined #dojo-meeting
[13:56] * jaxsphere (i=chatzill@nat/ibm/x-4a8185a5d57c9912) has joined #dojo-meeting
[13:56] <jaxsphere> hi
[13:56] <brian_skinner> hey jaxsphere
[13:56] <jaxsphere> jared's joining in
[13:57] <brian_skinner> great
[13:57] <jaxsphere> do you know if souzis, alex, or tom will be here?
[13:57] <jaxsphere> no other replies to the contrib list
[13:57] <brian_skinner> owen was interested, but he's out of town today so he can't make it this week
[13:58] <jaxsphere> ok
[13:58] * jared_j (i=chatzill@nat/ibm/x-83234510285866d4) has joined #dojo-meeting
[13:58] <jaxsphere> hi jared
[13:58] <brian_skinner> i doubt souzis will be coming to any new meetings -- he's busy with doing his startup
[13:58] <brian_skinner> hi jared
[13:58] <brian_skinner> i don't know about tom or alex
[13:58] <jaxsphere> jared is the developer that i had hinted at during 3d2
[13:59] <jaxsphere> he's going to be carrying forward data/binding through this year
[13:59] <brian_skinner> great! -- welcome jared
[13:59] <jaxsphere> (he had to step away for a sec)
[14:00] <jaxsphere> it looks like it may just be the three of us today
[14:00] <brian_skinner> i just brought up the agenda and saw the new links to the use cases and API -- i'll go have a look at those
[14:01] <jaxsphere> we can go through 1 by 1 if you'd like
[14:01] <jared_j> Hello. We also have a zip of working prototypes and testcases that the use cases are based on we're going to send out. It's still namespaced to IBM, but it does give real code to look at and play with.
[14:01] <jaxsphere> I was hoping that today we could try to get some agreement on highlevel set of scenarios
[14:02] <brian_skinner> that sounds great
[14:02] <jared_j> Brian, what mail address would you like me to send the zip and mail to?
[14:03] <brian_skinner> skinner@dojotoolkit.org
[14:05] * uhop (n=chatzill@cpe-76-183-103-117.tx.res.rr.com) has joined #dojo-meeting
[14:05] <jaxsphere> jared, why don't we start at a high level, and go through each use case first. Not focusing on any code, just getting agreement that each scenario is valid, then come back through each scenario in more detail
[14:05] <brian_skinner> hey uhop
[14:05] <jaxsphere> hi
[14:05] <jared_j> Okay, mail has been sent with a small attachment that has the functioning prototypes.
[14:05] <uhop> hey guys
[14:06] <uhop> could you forward one to me (elazutkin@dojotoolkit.org)?
[14:07] <jared_j> Right. The use cases can be found on the wiki at: http://dojo.jot.com/WikiHome/DojoDataUseCases I've tried to order them from least complex to most complex in terms of the number of widgets, items being bound, and so forth. And certainly, I'll forward right now..
[14:08] <jared_j> The first use case we can look at for validity is the simplest one. Binding widget values to widget values: http://dojo.jot.com/WikiHome/Binding%20Widget%20Values%20to%20Widget%20Values
[14:08] <uhop> got it, thx
[14:09] <brian_skinner> the first use case sounds good to me
[14:09] * peller (n=peller@209-6-218-233.c3-0.nwt-ubr2.sbo-nwt.ma.cable.rcn.com) has joined #dojo-meeting
[14:10] <jaxsphere> hi adam
[14:10] <brian_skinner> hey peller
[14:10] <peller> hey. sorry I'm late. lurking, as usual
[14:10] <jaxsphere> we're going through the use cases at a high level first, validating each one, then we'll take another pass through in more detail
[14:10] <peller> jaxsphere: aren't you on vacation? :-|
[14:10] <jaxsphere> The use cases can be found on the wiki at: http://dojo.jot.com/WikiHome/DojoDataUseCases
[14:11] <jared_j> The first one was: http://dojo.jot.com/WikiHome/Binding%20Widget%20Values%20to%20Widget%20Values Really basic use case.
[14:11] <jaxsphere> back as of this morning
[14:11] <peller> cool. Is there something like "DataGrid" on there? Or is that too high-level? :-)
[14:11] <jaxsphere> [Binding Widget Values to Widget Values] +1
[14:11] <jaxsphere> yes, there is
[14:12] <jared_j> We have an example of binding to filtering table, which is close (and one of the more complex examples below)
[14:12] <jared_j> So, we'll get to that one. :)
[14:12] <jaxsphere> uhop/peller: ok with first use case?
[14:13] <peller> right. with some subtle differences in DataGrid, like random access.
[14:13] <peller> Definitely do FilteringTable first
[14:13] * jaxsphere (i=chatzill@nat/ibm/x-4a8185a5d57c9912) Quit (Read error: 104 (Connection reset by peer))
[14:14] <uhop> ok with me
[14:14] * jaxsphere (i=chatzill@nat/ibm/x-ace60bb0aa14a5c4) has joined #dojo-meeting
[14:14] <jaxsphere> back
[14:14] <jared_j> Next use case is slightly more complex (but not much). Binding a item from a datastore query into a widget: http://dojo.jot.com/WikiHome/Binding%20Data%20Values%20to%20a%20Widget
[14:16] <brian_skinner> reading...
[14:18] <jaxsphere> comment: modify the picture slightly to show data value on datastore side
[14:18] <jaxsphere> otherwise, makes sense
[14:18] <jared_j> Noted. Will update.
[14:20] <brian_skinner> i'm feeling a little slow this afternoon -- i'm having trouble wrapping my head around the idea of passing "scope:args" into the bind() function
[14:20] <brian_skinner> with args.completed as an empty placeholder function
[14:21] <brian_skinner> sorry, that's args.oncompleted
[14:22] <brian_skinner> oh, okay, i think I understand
[14:22] <jared_j> We'll come back and revisit the programmatic bits, some of that does take a bit of explaining. Does the general high-level scenario make sense? First goal is to get closure on scenarios, then we go back through and go through each in more detail and focus on programmatic and declarative
[14:22] <brian_skinner> sure, sounds good
[14:22] <jared_j> (Quickly, the oncompleted is registering a callback 'event' for the find of datastore, if that helps)
[14:22] <brian_skinner> yes, the high level goal of the scenario certainly sounds good
[14:23] <jaxsphere> [Binding Data Values to a Widget]v+1
[14:23] <brian_skinner> +!
[14:23] <brian_skinner> +1
[14:23] <jared_j> The next scenario is the inverse of this one. Saving widget data to the datastore. http://dojo.jot.com/WikiHome/Binding%20Properties%20of%20a%20Widget%20to%20DataStore
[14:24] <brian_skinner> yup, sounds good
[14:25] <jaxsphere> +1
[14:26] <uhop> looks good
[14:26] <jared_j> The next one is indirectly associated with data and binding, the ability to declaraively bind/associate a widget event to some action, such as a datastore save. The way I think of it is a declaraive version of dojo.event.connect() http://dojo.jot.com/WikiHome/Binding%20Widget%20to%20Action This comes into play in more complex examples and scenarios.
[14:27] <jared_j> Forgive the table glitch on the page, I'll fix that. :)
[14:29] <jaxsphere> so on some event, perform some action (ie. invoke some function, potentially on some object)
[14:30] <jaxsphere> The implementation of Action also hides the differences between connecting with dojo.event.connect() and dojo.event.topic's, right?
[14:31] <jared_j> Yes. The general Action widget used can be set to perform widget actions, post to a topic, and do an action in response to a topic. The next scenario shows where a widget event auto-triggers a post to a topic.
[14:31] <brian_skinner> that doesn't sound bad, but I'm not sure I fully appreciate the infrastructure you're putting in place -- could you do the same things just with dojo.event.connect, or is this more powerful -- or, not more powerful, but just available declaritively
[14:31] <brian_skinner> ?
[14:32] <jared_j> It's more for the latter situation, to allow people who wish to work in markup, or tooling that does markup, to be able to easily wire together actions on widgets/etc without writing all the connect() logic.
[14:33] <jared_j> It handles all the Widget id resolutions and connect calls for you.
[14:33] <jaxsphere> so Action does not apply for programmatic case
[14:33] <jared_j> Not really. As Brain said, you can accomplish the same thing with connect() programmatically.
[14:34] <brian_skinner> okay, that sounds good -- but i don't have a strong background with either dojo.event.connect or with declarative scenarios -- it's too bad we don't have alex or dylan or tom here, they would be interested in this part
[14:35] <brian_skinner> would it be good to call that Connect instead of Action?
[14:35] <jared_j> And think about this as well, with it done in markup, a document parser can look through the page and graphically rshow how each widget/event links to another. If it's all in JS code, that's a lot more difficult to do that.
[14:37] <brian_skinner> yup, i see the power of having this all available declaratively -- i was a big fan the old NeXT interface builder app, which let you wire up widgets and datastores and objects in a GUI environment
[14:37] <jared_j> Possibly. That is definitely something to consider. :)
[14:38] <jared_j> Making a note on Action -> Connect. The scenario we looked at here that pushed the name 'action' was that it could also be used to potentially encapsulate calling a service (io.bind), but we're still trying to flesh out if it makes sense to have that all in action, or divide it.
[14:38] <jaxsphere> Action subclasses can also be used for RPC service invocations (dojo.rpc)
[14:39] <brian_skinner> i see -- not necessarily just doing what dojo.event.connect() does
[14:40] <jared_j> Right.
[14:40] <brian_skinner> onward?
[14:40] <jared_j> Do you feel the scenario is valid? Yep, will move on if all agree to move.
[14:41] <jaxsphere> +1, i believe this is necessary for declarative, not programmatic
[14:42] <brian_skinner> that scenario is beyond the scope of what i've been thinking about -- certainly not _invalid_, but not something i'm qualified to have an opinion on one way or another without first reading and thinking more
[14:43] <jared_j> Next one is a variant of action. Linking action/event in a declarative manner to publishing some value onto a topic. http://dojo.jot.com/WikiHome/Binding%20Widget%20to%20TopicPublishAction This encapsulates handling the publishing to a named topic with arbitrary data on any sort of event. The data can come from any widget (the whole widget even), or a property on it, or even data from a...
[14:43] <jared_j> ...datastore.
[14:43] <brian_skinner> it's cool that you're thinking about use cases beyond what we talked about last year
[14:44] <jaxsphere> actually have some real scenarios from tools that have been built around this
[14:44] <brian_skinner> yup
[14:45] <jared_j> A lot of these came up because of more complex cases, like chaining together and triggering a bunch of binds on one event. Event A causes bind B, Bind B's oncomplete fires Action C, which does..
[14:45] <jared_j> And so on.
[14:46] <jaxsphere> Widget to TopicPublishAction is another declarative case
[14:46] <brian_skinner> this scenario is like the last one for me -- sounds good, but i'm out of depth
[14:46] <brian_skinner> out of my depth
[14:47] <jaxsphere> next...
[14:47] <brian_skinner> :-)
[14:47] <jared_j> Okay, next one. Topics can be seen as a data source. So, binding parts of a topic message (or whole thing), to data/properties of a widget: http://dojo.jot.com/WikiHome/Binding%20Topic%20Subscription%20to%20Widget
[14:48] <jared_j> This actually simplifies dealing with topic subscriptions a fair amount.
[14:48] <jaxsphere> example scenarios: binding Gauge widgets to changing data values on a topic
[14:48] <jaxsphere> Chart widget for performance metrics or stock quotes
[14:50] <jared_j> Disregard the ibm* we updated these and forgot to clear the namespaces to dojo. (These were taken frm testcases). We're fixing that now. :)
[14:52] <brian_skinner> just read through it all -- sorry, i feel kinda lame -- i've never used dojo topics before and don't haven't been thinking much about them in connection with the rest of this
[14:53] <jaxsphere> so a variation on this that may make more sense...
[14:53] <jaxsphere> say you have a feed (RSS/ATOM) as a DataStore
[14:53] <jaxsphere> that periodically polls for updates
[14:54] <brian_skinner> right
[14:54] <jaxsphere> you want data changes to be bound to widgets
[14:54] <brian_skinner> right
[14:54] <jared_j> And if you broadcast the change to the topics, anyone listening to them can be easily bound into the part of the message it wants to display/work with.
[14:55] <jaxsphere> y
[14:55] <jaxsphere> makes sense to me
[14:55] <jaxsphere> next... ?
[14:55] <brian_skinner> i see
[14:55] <brian_skinner> yup
[14:55] <jared_j> Next one is the complicated widget cases. The first is Filtering table to a datastore: http://dojo.jot.com/WikiHome/Binding%20FilteringTable%20to%20DataStore
[14:57] <jaxsphere> This example scenario doesnt handle paged access, but there is a test case in the zip jared sent that does
[14:58] <jaxsphere> we should probably call out large dataset/paging as an alternate scenario for table and tree binding
[14:58] <jared_j> The yahooStore.js test. The more complex binding examples were all built off using the original example/conceptual uses of DataStore.
[14:59] <jared_j> Jaxsphere: Agreed. Would be worthwhile having separate scenario that explicitly showed paging.
[14:59] <jaxsphere> how are we for time? I can go until 6pm est...
[15:00] <brian_skinner> i can go for another hour too, if we want to
[15:00] <jared_j> Lets get through all the scenarios, then, and we can start discussing the deeper details of them if we still have time before 6, then.
[15:00] <jaxsphere> sounds good
[15:01] <jared_j> Everyone okay with the filtering table scenario?
[15:01] <brian_skinner> after we break, i can go back and read through everything in more detail
[15:01] <brian_skinner> yup, filtering table scenario sounds good
[15:01] <jaxsphere> +1
[15:01] <jared_j> Next case then is another complex widget binding. The tree. http://dojo.jot.com/WikiHome/Binding%20Tree%20to%20DataStore
[15:03] <brian_skinner> that one looks good to -- very similar to the filtering table one
[15:03] <jaxsphere> This one brings data into the tree, but we need alternate flow for editable tree nodes saving data out
[15:03] <jared_j> Making note we need the inverse examples maping data out to save.
[15:03] <jaxsphere> same with datagrid
[15:03] <jaxsphere> yep
[15:04] <brian_skinner> i'd like to think some about whether there might be ways to have simple defaults so that it's possible to do basic bindings with less boilerplate code
[15:04] <jared_j> Actually, let me double-check, we have testcases for this I do believe. We just need to call them out as scenarios.
[15:04] <jaxsphere> cool
[15:04] <jared_j> I agree. We've already gone a couple iterations internally and simplified it. If we could simplify it further, all the better.
[15:05] <jaxsphere> y, there may be a default mapping that makes sense, but i think you'll need this for custom cases
[15:05] <brian_skinner> yup, custom cases will require full expressiveness
[15:05] <jaxsphere> like what's already in the multi-store testcase
[15:05] <jaxsphere> we should code that example up with the binding library...
[15:06] <brian_skinner> i'm also interested in the question of whether it would make sense to have an abstraction layer above the XPath stuff
[15:06] <jared_j> We should show a scenario that does simple one to one data to item mapping, not a mapping where the item is a collection of things.
[15:06] <jaxsphere> yeah (perhaps if alex can support dojo.query with common syntax)???
[15:07] <jared_j> Yes, that is a concern. The path items are already datastore/item specific (XPAth, js notation, etc). ... What Jaxsphere said. :)
[15:07] <brian_skinner> right :-)
[15:07] <jaxsphere> we purposely punted on that issue for v1, but it's worth revisiting
[15:07] <brian_skinner> sounds good
[15:08] <brian_skinner> next case?
[15:08] <jared_j> Cool Now we get to scenarios we haven't done examples for yet (but are valid things that need to work.) First one is: http://dojo.jot.com/WikiHome/Binding%20Widget%20to%20ServiceAction
[15:09] <jared_j> This is invoking services (RPC/ etc). Similar to the action ones above.
[15:09] <brian_skinner> +1
[15:10] <jared_j> Next one. Binding the selections available in a combobox to a datastore: http://dojo.jot.com/WikiHome/Binding%20ComboBox%20to%20DataStore
[15:10] <brian_skinner> and then the next couple use cases aren't so fleshed out ;-)
[15:10] <brian_skinner> but they both sound good too
[15:10] <jaxsphere> combobox: this one may already be possible with the current library...the scenario is valid tho
[15:10] <jared_j> Right. We're getting there. ;) We're going from least to more complex, more or less.
[15:11] <brian_skinner> peachy
[15:11] <jared_j> And the one after that http://dojo.jot.com/WikiHome/Binding%20Chart%20to%20DataStore The chart widget. We should have bindings for that like table, tree, etc.
[15:11] <jaxsphere> +1 on chart--very related to the topic scenarios
[15:11] <brian_skinner> +1
[15:11] <jaxsphere> (may end up being the same)
[15:12] <jaxsphere> brian, you had a time-series data set vizualization use case...
[15:12] <brian_skinner> yup, long ago that was one of my goals
[15:12] <jaxsphere> should we consider for the chart binding to datastore (separate use case from topic data)
[15:12] <jared_j> And then the last two which realistically pull together alot of the above: http://dojo.jot.com/WikiHome/Binding%20Views%20to%20DataStores%20with%20Polling%20Updates How to bind views to data that changes over time/gets update. With this one, updates are polled for.
[15:12] <brian_skinner> but i'm not sure our dojo.data notion of items and attributes is well suited to representing time series data
[15:14] <jaxsphere> not sure I understand what would make time-series data more complex...if you get a chance, send your thoughts, and we can revisit as a scenario
[15:14] <brian_skinner> okay
[15:15] <brian_skinner> in the polling use case, might be good to group the "polling" scenario along with the "comet" scenario (server push)
[15:15] <jaxsphere> I think (hope) that polling interval scenario for feeds will converge with the topic-subscription scenario we visited earlier
[15:15] <jaxsphere> hehe
[15:15] <brian_skinner> could just call it the update notification scenario or something
[15:15] <jaxsphere> great minds...
[15:15] <jared_j> Same idea, yep. :)
[15:16] <brian_skinner> back in the day, we talked about extending the dojo.data APIs themselves to represent this
[15:16] <brian_skinner> we now have Read, Write, and Identity APIs
[15:16] <brian_skinner> would it be good to have a Notification API?
[15:16] <jaxsphere> yeah, maybe we should consider standard topic names?
[15:17] <jared_j> I think so, because this scenario and the next (http://dojo.jot.com/WikiHome/Binding%20Views%20to%20DataStores%20with%20Service%20Triggered%20Updates) Would both bea able to make use of that
[15:17] <jaxsphere> the topic name and message format would be the ap
[15:17] <jaxsphere> api
[15:17] <jaxsphere> eliminate need for registerObserver kind of api's
[15:18] <brian_skinner> is there an advantage to topic names over registerObserver style apis?
[15:18] <brian_skinner> or, put another way...
[15:18] <jaxsphere> loose coupling
[15:19] <jaxsphere> and no need for tracking listeners and explicitly unregistering listeners
[15:19] <jaxsphere> pubsub does it for u
[15:19] <brian_skinner> can you give me a quick example?
[15:20] <brian_skinner> so you've got a FilteringTable, and you want to bind it to a datastore
[15:20] <brian_skinner> and the datastore is going to have update notifications about the items in the datastore
[15:20] <jaxsphere> y, one sec...jared...
[15:20] <brian_skinner> and the FilteringTable should update whenever the data updates
[15:21] <jaxsphere> datasource would have standard topic name
[15:21] <jaxsphere> and instance id as part of the topic
[15:21] <jared_j> Well, what each DataStore could provide is a property that defines out the name of its topic that it wil publish change events on. You could then use the above binders to bind that property, to say the Topic to Widget scenario (Or the filtering table example)
[15:21] <jaxsphere> right
[15:22] <jared_j> that way if you want to connect any object easily to a partocular datastore noftification, it's just a matter of binding the topic name to the topic to 'wdget'. If that makes sense? No need to write and register observers explicitly.
[15:23] <jaxsphere> alternative would be to do something like a register/unregisterObserver() api that the ds would have to signal each observer on data update
[15:23] <jaxsphere> but the topic approach seems much cleaner
[15:23] <jared_j> topics give you the auto-notify ability upfront.
[15:24] <brian_skinner> what about just being able to say ...bind(table, datastore) and have it just work? no need write and register observers, or to subscribe to topics
[15:24] <brian_skinner> under the covers there's some connection, but that's an implementation detail
[15:24] <brian_skinner> ...
[15:24] <brian_skinner> sorry, digression
[15:25] <jared_j> That's an idea. No need to be sorry, it fits in.
[15:25] <jaxsphere> n, not a digression... makes sense to have a high level version of bind to do that...under the covers it could use topics
[15:25] <jaxsphere> but to write a ds that is conformant with the auto-binding mechanism, we'd need to detail how one would hook into the topics in the ds impl
[15:26] <jared_j> Or whatever mechanism that gets decided on. The user then doesn't care, or have to write register() calls.
[15:26] <jared_j> The datastore impl people will care. But the app level devs won't have to care.
[15:26] <jaxsphere> y
[15:27] <brian_skinner> the thing that worries me about topics is that they require a whole bunch of unique text strings, which have to somehow get automatically created, which seems unnecessary since all the javascript objects already had unique pointers
[15:27] <jaxsphere> the scenario seems valid either way :)
[15:27] <brian_skinner> jaxsphere: +1 yes, the scenario is certain valid regardless of the details
[15:27] <jaxsphere> we can try it both ways and weigh pros/cons
[15:28] <brian_skinner> yup
[15:28] <jaxsphere> and the final? scenario is...
[15:29] <jared_j> Last one (didn't get a chance to write the example, but it would be pretty easy): http://dojo.jot.com/WikiHome/Binding%20Widget%20to%20Intermediary%20to%20Widget Connecting data together through an intermediary which does some sort of transform/update on it.
[15:29] <jared_j> Examples: Spreadsheet cell formulas.
[15:29] <jared_j> Calculating and adding on tax/shipping.
[15:30] <jared_j> Combinign first and last names.
[15:31] <jared_j> This is more or less a chaining scenario. IT builds on the basic one to one stuff above.
[15:31] <brian_skinner> so in those cases, is this really a binding thing, or is it more a data thing?
[15:32] <brian_skinner> area = width * height
[15:32] <jaxsphere> could be functions in js as well
[15:32] <jared_j> It's binding a data value to a component, which may/can act as a transform.
[15:32] <brian_skinner> regardless of the widget binding, the notion of area should be available
[15:33] <brian_skinner> what's a "component"?
[15:33] <jaxsphere> one way would be via model-layer abstraction (spreadsheet datastore), that could have user-defined functions
[15:33] <brian_skinner> jaxsphere: yes, that's how I'd been thinking about it
[15:34] <jaxsphere> another would be just a JS object (jared's "component") that could do the calculation
[15:34] <jaxsphere> i think both are valid
[15:34] <jared_j> So in this case the idea is you're binding the inputs of a function to some data values and the output is bund to another place.
[15:34] <brian_skinner> i see: component == arbitrary JS object
[15:34] <jared_j> Right
[15:34] <brian_skinner> yup, sounds good
[15:35] <jared_j> Okay, so that's the basic scenarios. Are there others you think should be covered?
[15:35] <jaxsphere> Ok! Now... What's missed in the scenarios?
[15:35] <jaxsphere> :)
[15:35] <jaxsphere> if we implement these, as next step, will we hit the mark?
[15:35] <brian_skinner> did we skip the next to last scenario?
[15:35] <brian_skinner> service triggered updates?
[15:35] <jaxsphere> yeah, we did
[15:36] <jared_j> I thought we covered it in our discussion about registering for change events on a datastore.
[15:36] <brian_skinner> ah, okay
[15:36] <jared_j> It was very related to it (similar idea), but where you have to force the DS to get updates (no automatic updates)
[15:36] <jaxsphere> right, its a variation on the previously discussed scenario
[15:37] <brian_skinner> you've thought about a lot of scenarios -- off the top of my head, i can't think of anything important that's missing
[15:37] <jaxsphere> remote service updates state in db, db changes propogate through feed (or comet) back to client
[15:37] <jaxsphere> have we over-shot?
[15:38] <jared_j> Yeah, have we broken the 80/20 rule and are trying to cover too much? :)
[15:38] <brian_skinner> over-shot == too ambitous?
[15:38] <brian_skinner> maybe
[15:38] <jaxsphere> at least we arent making them up :)
[15:39] <jaxsphere> let's assume were
[15:39] <jaxsphere> fairly close on scope
[15:39] <jaxsphere> there's a layering that's done in the current binding library
[15:39] <brian_skinner> certainly the jist of it is right, even if a couple things end up being unneeded
[15:39] <jaxsphere> programmatic core
[15:39] <jaxsphere> plus declarative layer on top
[15:39] <jaxsphere> declarative layer is optional
[15:40] <brian_skinner> yup
[15:40] <jaxsphere> there were a couple issues to discuss...
[15:40] <brian_skinner> lead on
[15:40] <jared_j> Now, issues! Here's the big one. Where the heck do we stick this? What should the namespace for dojo.data and bindings be in the new structure.
[15:41] <jaxsphere> brian, have you discussed with alex where the dojo.data stuff will end up?
[15:41] <brian_skinner> i don't know -- we need to pull in some of the dojo-elders to talk about this
[15:41] <jared_j> I said big because I was lurking on the meeting where the api split was starting and packages were trying to be decided. :)
[15:42] <brian_skinner> at dojo-dev-day, there was talk about dojo.data staying in dojo core rather than being in dojox
[15:42] <jaxsphere> i'd like us to repackage the current codebase that was sent out under dojo/dojox namespaces
[15:42] <jaxsphere> y
[15:42] <jaxsphere> core but not "base"
[15:42] <jaxsphere> eg bootstrap
[15:42] <brian_skinner> not in bootstrap
[15:42] <jaxsphere> right
[15:42] <jared_j> But then I would wonder about bindings. And then about the declarative widgets? Separate packages or part?
[15:42] <jaxsphere> and dojox.data would contain the concrete store impls
[15:43] <brian_skinner> but probably not _all_ of dojo.data should be in core -- some will end up in dojox?
[15:43] <jared_j> I would think the declarative ones -> dojox definitely.
[15:43] <brian_skinner> jared_j: yes, i think this is complicated, and i don't think anybody has thought it through yet
[15:43] <jared_j> Store impls -> dojox.
[15:43] <jaxsphere> I think it would be nice to have binding programmatic api's in dojo.data, and declarative in dojox.data.decl or something similar
[15:44] <jared_j> And we really need Alex and crew here to discuss this, don't we?
[15:44] <jaxsphere> well, to finalize it, we will
[15:44] <brian_skinner> i think having a couple store implementations in dojo rather than dojox might make sense
[15:44] <jaxsphere> i'd like us to get basic agreement, so that we can take another round and clean up the library before exposing to contrib list
[15:44] <jaxsphere> skinner: yep, JSONStore, XMLStore ?
[15:44] <brian_skinner> yes, we really need alex and others before we can finalize anything on this
[15:45] <brian_skinner> jaxsphere: just wanted to mention, the coding standards call for JsonStore and XmlStore rather than JSONStore, XMLStore
[15:45] <jaxsphere> i'd like to get this out for broader comments to the contrib list next week
[15:46] <jaxsphere> to achieve that goal, let's put a strawman namespace split in place
[15:46] <jared_j> How about this:
[15:46] <brian_skinner> yes, i think posting to the contrib list sounds good -- raise some of the questions, and offer some strawman suggested answers, and see what people thing
[15:47] <brian_skinner> think
[15:47] <jaxsphere> we'll post the code as well (simiar to how 2d was done)
[15:47] <jared_j> the bindings cor e(programmatic) go into dojo core namespace. The widgets (delcarative ones), and additional stores like XmlStore, go to something like datax. At least as an initial suggesiton.
[15:47] <brian_skinner> datax or dojox?
[15:48] <jared_j> Good question.
[15:48] <jaxsphere> dojox
[15:48] <jared_j> How many root spaces are there? I never heard the conclusion on it.
[15:48] <jaxsphere> dojo, dijit, dojox
[15:48] <brian_skinner> i think three: dojo, dojox, and digit
[15:48] <brian_skinner> dijit
[15:48] <jaxsphere> :)(
[15:48] <jared_j> dojox then
[15:49] <brian_skinner> right, that sounds good, but maybe with a couple other things in dojo.data as well
[15:49] <jared_j> What pieces do you see as belonging in the dojo.data part of core?
[15:49] <brian_skinner> for example, a couple weeks ago I checked in a dojo.data.SimpleBaseStore.js
[15:50] <jaxsphere> yeah, and JSONStore
[15:50] <jaxsphere> those are very common onese
[15:50] <jared_j> JsonStore, jaxsphere. ;)
[15:50] <brian_skinner> which I think would be useful as an abstract superclass for about 95% of all datastore implementations
[15:50] <jaxsphere> heh, yeah on style
[15:51] <brian_skinner> and maybe having a couple very general purpose stores, like JsonStore and XmlStore
[15:51] <jaxsphere> I think XMLStore and all XML-ish binding stuff should go into dojox.data
[15:51] <jaxsphere> although XML *IS* really common
[15:51] <jared_j> *cough* ATOM, RSS...
[15:51] <jaxsphere> n
[15:51] <jaxsphere> dojox
[15:51] <jaxsphere> dojox.data <- atom/rss
[15:52] <jaxsphere> atom is a pos
[15:52] <jaxsphere> in terms of verbosity
[15:52] <brian_skinner> a pos?
[15:52] <jaxsphere> like soap
[15:52] <jared_j> It can be, yessir. :) Boy do *I* know.
[15:52] <jaxsphere> piece of s...
[15:52] <brian_skinner> :-)
[15:53] <jared_j> ATOM is crazy-verbose. I've been playing aith an AtomIO/AtomTransport plugin for Dojo.
[15:53] <brian_skinner> so, it's just about 6:00 for jaxsphere
[15:53] <jared_j> But that's a topic for another time.
[15:53] <brian_skinner> :-)
[15:53] <jaxsphere> yep
[15:53] <jared_j> 6:00 for me too. Same TZ as jaxsphere.
[15:53] <brian_skinner> thanks for posting so much new material
[15:54] <brian_skinner> i'll look at everything more closely later this week
[15:54] <jared_j> I'll refactor the current examples to the new namespaces and send out another zip for review and discussion on putting on contrib for wider review.
[15:54] <brian_skinner> that sounds great
[15:55] <jared_j> I'll target by friday to send out the refactor for review.
[15:55] <brian_skinner> i'm available to come to weekly meetings, if you want to do that -- but really it would be good to have people like tom/bill/owen/alex/dylan involved
[15:56] <jaxsphere> yeah, we really need to get more eyes
[15:56] <jared_j> I want them involved too.
[15:56] <brian_skinner> you might need to do some one-on-one prodding to recruit them to be involved
[15:56] <jaxsphere> let's get the initial cut, and then work via contrib thread
[15:56] <jaxsphere> ok
[15:56] <jared_j> I can refacotr the current and I'll mail that out next time to them as well.
[15:56] <jaxsphere> ok
[15:57] <jaxsphere> do we want to put anything on agenda for tommorrow?
[15:57] <jaxsphere> or wait till next week?
[15:57] <brian_skinner> i've stopped attending the wednesday meetings, so i won't be there
[15:57] <jared_j> I say wait till next week. Lets clean up the use cases a bit more and get the refactor done. Then we can ask folks to review then on next weeks meeting
[15:58] <brian_skinner> okay
[15:58] <jaxsphere> sounds good
[15:58] <jaxsphere> good call, thanks jared!
[15:58] <jaxsphere> ttyl
[15:58] <brian_skinner> thanks guys!
[15:58] <jared_j> Thanks!
[16:00] * jared_j (i=chatzill@nat/ibm/x-83234510285866d4) Quit ("Chatzilla 0.9.77 [Firefox 1.5.0.9/2006120612]")
[16:14] * brian_skinner (n=brian_sk@adsl-71-141-100-192.dsl.snfc21.pacbell.net) Quit ("Chatzilla 0.9.77 [Firefox 1.5.0.9/2006120612]")
[16:18] * jaxsphere (i=chatzill@nat/ibm/x-ace60bb0aa14a5c4) Quit (Read error: 110 (Connection timed out))
[16:41] * uhop (n=chatzill@cpe-76-183-103-117.tx.res.rr.com) Quit ("Chatzilla 0.9.77 [Firefox 2.0.0.1/2006120418]")
[17:18] * jaxsphere (n=chatzill@cpe-024-211-156-070.nc.res.rr.com) has joined #dojo-meeting
[18:57] * jaxsphere (n=chatzill@cpe-024-211-156-070.nc.res.rr.com) Quit ("Chatzilla 0.9.77 [Firefox 1.5.0.9/2006120612]")
[20:25] * peller (n=peller@209-6-218-233.c3-0.nwt-ubr2.sbo-nwt.ma.cable.rcn.com) Quit ()