[10:04am] slightlyoff: howdy [11:46am] tris left the chat room. (Read error: 60 (Operation timed out)) [12:07pm] tris joined the chat room. [12:58pm] slightlyoff: hey tris, do you work on ehtereal? [1:30pm] fbos joined the chat room. [1:30pm] slightlyoff: howdy [1:30pm] fbos: Hi [1:31pm] fbos: I understand there's a chat 'round 2 PM PST ? [1:31pm] slightlyoff: that's the hope = ) [1:31pm] slightlyoff: (this is Alex, btw) [1:31pm] fbos: About data binding... So, what's to talk about ? [1:32pm] fbos: Great, pleased to meet you, I am FranÁois incompatible encoding [1:32pm] slightlyoff: so we've known for a long time that Dojo is going to need some sort of nice way to provide data binding [1:32pm] slightlyoff: and bi-directional binding at that [1:32pm] fbos: Binding to databases or XML ? [1:33pm] slightlyoff: does it matter? [1:33pm] slightlyoff: one can be the other [1:33pm] fbos: Just wanted to make sure we were talking about the same thing [1:33pm] slightlyoff: oh, OK [1:33pm] fbos: Any plans currently ? [1:33pm] fbos: (BTW, anybody keeping a log for offline use ?) [1:33pm] slightlyoff: nope, other than to spec out a sane api for dojo to use on the client side [1:33pm] slightlyoff: (I am) [1:34pm] slightlyoff: and then provide some way for people to map that to data sources on servers [1:34pm] fbos: So, the hope is to say something like "bind control X to such and such at URL Y" ? [1:34pm] slightlyoff: we have all kinds of issues like paging, flat vs. hierarchial, etc. to work through [1:34pm] slightlyoff: if that's what the developer wants, yes [1:35pm] slightlyoff: but like all things Dojo, the easy things should be trivial and the hard things easier [1:35pm] fbos: I have to admit I stumbled upon Dojo when I was searching for an Ajax-style JavaScript solution. [1:35pm] fbos: I only used dojo.io.bind() at the moment. [1:35pm] slightlyoff: so if they want to bind a paged data set with bi-directional updates, that doesn't have to be the only thing we design for [1:35pm] slightlyoff: how are you finding it? [1:36pm] fbos: Great ! [1:36pm] fbos: It's working just fine. [1:36pm] slightlyoff: I built a new package the other day [1:36pm] slightlyoff: it fixes some bugs that people were reporting with back-button stuff [1:36pm] fbos: Yes, I saw, but I'm using a checked out copy. [1:36pm] slightlyoff: ok [1:36pm] fbos: I thought I should be expanding my use slightly, because I have something currently. Let me explain, and it will probably be made clear. [1:36pm] slightlyoff: ahh = ) [1:37pm] fbos: It's an eCommerce site (like everyone else). I want to update some values on screen when the user selects a country of destination. [1:37pm] slightlyoff: ok [1:37pm] fbos: On the server, I have a PHP script which generates XML which in turn contains things like 12.22Expedited [1:37pm] fbos: yada, yada [1:37pm] slightlyoff: righty [1:37pm] fbos: There can be multiple items [1:37pm] slightlyoff: ok [1:38pm] fbos: So, I have an HTML SELECT control at the moment [1:38pm] fbos: I'm using dojo.io.bind to get at the XML, and then I'm parsing to create OPTION elements, live [1:39pm] slightlyoff: right, makes sense [1:40pm] fbos: It's slightly painful to create the elements by-hand [1:40pm] fbos: If there is some kind of data binding, I would like to say: [1:40pm] fbos: attach(ID of element, URL, XPath expression) [1:40pm] slightlyoff: ah, hrm [1:41pm] slightlyoff: so I guess I'm a bit wary of xpath right now (on the client, anyway) [1:41pm] slightlyoff: but I can see your point [1:41pm] fbos: Yeah, sure. That was in an ideal world, of course [1:41pm] slightlyoff: heh [1:41pm] slightlyoff: if xpath is ideal, I want a new world [1:42pm] fbos: Of couse, the third argument could be a function instead of a regular parameter, which could be handed off something (an element, perhaps ?), and could return the appropriate values [1:42pm] slightlyoff: right [1:42pm] slightlyoff: so I think the Dojo approach for something like this would be a widget [1:42pm] slightlyoff: which would handle the creation of the elements [1:42pm] slightlyoff: and the widget would get bound to the data source [1:42pm] slightlyoff: but I'm just ad-libbing here [1:42pm] fbos: Ok, NP [1:43pm] slightlyoff: since we don't even know what binding will look like yet [1:43pm] slightlyoff: I'm in the middle of an article on fast widget authoring [1:43pm] slightlyoff: but it's not done yet = \ [1:43pm] fbos: Refreshing the control's values must || should be manual && automatic. [1:43pm] fbos: In my case, I know when to refresh - every time the user changes the destination country [1:44pm] fbos: But I can envision use cases where the values should refresh themselves. [1:46pm] slightlyoff: refresh themselves? based on what event? [1:46pm] fbos: Time ? Other controls changing values ? Randomly ? [1:46pm] slightlyoff: ok [1:47pm] fbos: Okay, third one's probably not that useful, but time is surely something important. [1:47pm] fbos: Some kind of polling, since we can't get a notification when the server's view of the world changes. [1:48pm] fbos: HTTP already offers "304 Not Modified" for such cases [1:49pm] slightlyoff: so we've already talked about things like mod_pubsub or LivePage for up-to-date communciation w/ the server [1:49pm] slightlyoff: but I've already had other requests for polling w/ bind() [1:50pm] fbos: Wasn't aware of that. [1:50pm] fbos: But it would probably be something interesting. [1:50pm] slightlyoff: I've started on the mod_pubsub port, but there are integration issues w/ the current server [1:50pm] slightlyoff: I started on the LivePage port yesterday [1:51pm] slightlyoff: and that looks more promising [1:51pm] PSquad32 joined the chat room. [1:51pm] PSquad32: hey there [1:51pm] PSquad32: <-- Patrick Lightbody [1:51pm] slightlyoff: hi Patrick! [1:51pm] fbos: Hello Patrick, [1:51pm] PSquad32: i'll mostly be lurking [1:51pm] fbos: How do you do ? [1:51pm] fbos: Ok [1:52pm] progrium joined the chat room. [1:52pm] slightlyoff: I'm trying like mad to get the test cases for the combo box data provider to pass so we have something to look at = ) [1:53pm] fbos: Yummy! [1:53pm] slightlyoff: eh, there's not much there [1:53pm] slightlyoff: and I dislike the API [1:53pm] fbos: Well, something's better than nothing when we want to discuss [1:53pm] slightlyoff: but it would at be nice to have it at least semi-functional = ) [1:54pm] PSquad32: who is the moderator for this meeting? [1:56pm] slightlyoff: I guess me = ) [1:56pm] PSquad32: ok, is there an agenda? [1:56pm] slightlyoff: although I'm more inflamitory than most people [1:56pm] PSquad32: are you Alex? [1:56pm] slightlyoff: other than to come up w/ a sane set of APIs for producers and consumers of data, no [1:56pm] slightlyoff: yes, I'm alex [1:57pm] PSquad32: ok, well i suggest in the future that an agenda be set -- especially when you get more users, things can get hectic [1:57pm] PSquad32: anyway, my personal feelings are that Dojo is missing a framework for bring users in to the fold and understanding what dojo is [1:57pm] progrium: yay for agendas [1:58pm] fbos: Okay, I gotta go, since my wife just came in. [1:58pm] fbos: Have a nice one, everyone ! [1:58pm] fbos left the chat room. [1:58pm] PSquad32: given that it is 100% javascript, there is no reason you couldn't create a nice tutorial (using frames? eh, maybe) that allows users to enter in some templates/widgets/whatever and render them [1:58pm] PSquad32: lemme dig up a good example of this: [1:58pm] slightlyoff: well, I've started working on an article that discusses how to easily build widgets [1:58pm] slightlyoff: but yes, I see your point [1:59pm] PSquad32: http:/​​/​​www.laszlosystems.com/​​lps/​​laszlo-in-ten-minutes/​​ [1:59pm] dylanks joined the chat room. [1:59pm] alerque_ joined the chat room. [1:59pm] PSquad32: see how they show you some code, plus what it is renders as? then they let you _change_ the code [1:59pm] progrium: or a video of making something cool like ruby on rails, haha [1:59pm] PSquad32: that would get people having that "Ah ha!" moment _much_ faster [1:59pm] schontz joined the chat room. [2:00pm] slightlyoff: so who's gonna help w/ this stuff? [2:00pm] slightlyoff: I agree w/ everything you're saying [2:00pm] slightlyoff: but I'm swamped [2:00pm] PSquad32: yes, help is definitely needed [2:00pm] PSquad32: what i found at OpenSymphony is that all you have to do is establish the framework, then others will do the ground work [2:01pm] PSquad32: for example, write one tutorial like in that example URL [2:01pm] PSquad32: others will write the rest [2:01pm] You changed the topic to "data binding for fun and profilt!". [2:01pm] dylanks: what's profilt? [2:02pm] slightlyoff: you can "/topic" just as well as I can [2:03pm] slightlyoff: one of the things that might good would be a tutorial on how to use JS inside the wiki [2:03pm] slightlyoff: since that might be somepalce where people could work on this kind of thing [2:03pm] dylanks: are mda or trenka going to join us? [2:03pm] slightlyoff: dunno, ping 'em [2:03pm] slightlyoff: I would hope for at least one or the other [2:05pm] slightlyoff: so it's 2:05 by my clock [2:05pm] PSquad32: i concur [2:05pm] PSquad32: (that it is 2:05 ) [2:05pm] dylanks: no from trenka [2:05pm] schontz left the chat room. [2:05pm] dylanks: no response from mda [2:05pm] slightlyoff: hrm [2:05pm] dylanks: oh wait, mda is on his way [2:05pm] slightlyoff: great! [2:06pm] PSquad32: who is mda? [2:06pm] slightlyoff: Mark Anderson [2:06pm] slightlyoff: author of the the Burst library [2:06pm] dylanks: burstlib [2:06pm] slightlyoff: and a freaking smart guy [2:06pm] slightlyoff: he is a committer to netWindows as well [2:07pm] slightlyoff: he also came up w/ the basics of the bind() API and the Dojo bootstrap system [2:07pm] mda joined the chat room. [2:07pm] slightlyoff: speak of the devil! [2:07pm] slightlyoff: hi Mark [2:07pm] mda: hi. [2:07pm] dylanks: so data binding... [2:08pm] schontz joined the chat room. [2:08pm] mda: (hopefully i can stay on. currently my mac is in that "let me mysteriously abuse your disk indefinitely" mode.) [2:08pm] mda: yes data binding - what has happened since the last time we discussed it? [2:08pm] slightlyoff: nada [2:08pm] dylanks: well, not exactly [2:08pm] slightlyoff: I'm afraid = \ [2:08pm] dylanks: basically I've implemented some very basic interfaces for it [2:09pm] dylanks: basically all it does now though is two things: [2:09pm] slightlyoff: as have I (but they're not passing my tests right now) [2:09pm] dylanks: fetch an external data file that is a JS object, load/eval it with dojo.io.bind, and provide it to a widget [2:09pm] dylanks: by specifying a dataProvider attribute [2:10pm] slightlyoff: right [2:10pm] dylanks: 2) an abstract dataProvider class [2:10pm] dylanks: that basically is something widgets can read and write to [2:10pm] mda: what is an example of a dataProvider attribute? [2:10pm] dylanks: dataProvider="someUrl" in markup [2:11pm] slightlyoff: dyaln, is this checked in somewhere that we can look at? [2:11pm] dylanks: the abstract data provider basically can live independently before a widget is created or after it is destroyed [2:11pm] dylanks: let me see [2:12pm] dylanks: the code to load it is checked in, but no example of the data itself yet [2:12pm] slightlyoff: Ok [2:12pm] dylanks: basically it is just a JS object of key value pairs [2:12pm] slightlyoff: so making this a bit more concrete, my current use case is for a combo box [2:12pm] dylanks: of which the value can also be objects [2:12pm] slightlyoff: right [2:12pm] slightlyoff: and I can easily see one for "grid" type data [2:12pm] slightlyoff: as well as tree-style data (trees, menus, etc.) [2:13pm] dylanks: basically anything where it isn't just a set of attributes [2:13pm] dylanks: or where incremental loading or replacement of data is needed [2:13pm] slightlyoff: and I'd like to come up with some set of classes/APIs that allow us to do these things asynchronously, in a paged way, and without tying us too strongly to any server implementation [2:14pm] slightlyoff: my first thought was that there should be a couple of mixins/interfaces for data providers [2:14pm] schontz left the chat room. [2:14pm] slightlyoff: and that they should all be asynchronous [2:14pm] dylanks: is everyone following what we're talking about? [2:14pm] progrium: yes and no [2:15pm] mda: afaik what is currently implemented isn't really data binding. [2:16pm] mda: it is more a convenience for a widget declaration to say where some remote data comes from. [2:16pm] dylanks: feel free to ask questions... [2:16pm] mda: but it is up to that widget implementation to programmatically decide what to do with that data. [2:16pm] dylanks: right [2:16pm] dylanks: I said it was primitive [2:17pm] progrium: what's the alternative? [2:17pm] mda: whereas a "real" data binding would let you say something like: the width of this div should be equal to the temperature in alaska as obtained from some weather service. [2:17pm] progrium: ah [2:17pm] dylanks: negative widths? [2:17pm] mda: it would be in kelvin [2:18pm] slightlyoff: heh [2:18pm] slightlyoff: so lets work backwards from that definition [2:18pm] dylanks: so basically we need some ideas for ways of providing useful interfaces for both [2:19pm] slightlyoff: MDA's definition implies what you want [2:20pm] dylanks: right... just reframing the question... [2:20pm] slightlyoff: OK [2:20pm] mda: i think the missing (bridging) piece is that there has to be an indicator of what propert of the widget is being set. [2:20pm] mda: i mean, i guess it could be some property named "data" [2:20pm] dylanks: yeah, right now it is dataProvider [2:21pm] mda: no, dataProvider is the url where you get the value. [2:21pm] mda: the question is what is the variable that is being set to that value? [2:21pm] mda: it is some property of the widget such as "combochoices" or "tablevalues" [2:22pm] mda: i think it has to be thought of that way, so that instead you can say that the width is equal to the result of some remote query. [2:22pm] mda: and so that you can actually set multiple distinct properties of a single widget to different data sources. [2:22pm] slightlyoff: so throwing a bit of every-more-icky reality into the situation: we can't detect property changes or act on them [2:22pm] slightlyoff: we can detect and act on function calls, however [2:23pm] progrium: getters and setters : \ [2:23pm] dylanks: this is what we currently have as an interface: [2:23pm] dylanks: this.getDataProvider = function(objRef, dataUrl) { [2:23pm] dylanks: // FIXME: this is currently sync. To make this async, we made need to move [2:23pm] dylanks: //this step into the widget ctor, so that it is loaded when it is needed [2:23pm] dylanks: // to populate the widget [2:23pm] dylanks: dojo.io.bind({ [2:23pm] dylanks: url: dataUrl, [2:23pm] dylanks: load: function(type, evaldObj){ [2:23pm] dylanks: if(type=="load"){ [2:23pm] dylanks: objRef.dataProvider = evaldObj; [2:23pm] dylanks: } [2:23pm] dylanks: }, [2:23pm] dylanks: mimetype: "text/javascript", [2:23pm] dylanks: sync: true [2:23pm] dylanks: }); [2:23pm] dylanks: } [2:24pm] dylanks: yeah, getters and setters buy us that, but suck in having to have them [2:24pm] slightlyoff: or an observer that's keyed by name [2:24pm] slightlyoff: which you can listen to [2:25pm] slightlyoff: some function that gets called when a property gets set and passes that name in [2:25pm] slightlyoff: anyway, that's putting the cart before the horse [2:25pm] dylanks: right [2:26pm] mda: what i want to do is find a way where the common use cases require no coding at all. [2:26pm] slightlyoff: I agree w/ mda that we should be able to bind different properties to different sources [2:26pm] slightlyoff: amen = ) [2:26pm] mda: i mean, except for core implementors. [2:26pm] slightlyoff: yes [2:26pm] dylanks: [2:27pm] slightlyoff: so we have a "mixInProperties" method that gets us some of the way there for properties that are set from the parsed ctor nodes [2:27pm] mda: but the person writing the table or combobox widget can just say "hey, i've got this property called griddata, which is an array". [2:27pm] mda: it doesn't care or want to know how that value comes in at run time. [2:27pm] slightlyoff: sure, but it has to have some kind of method for saying "ok, I've got this property called griddata, and I need to know when it gets updated" [2:28pm] dylanks: or when it has expired [2:28pm] slightlyoff: or anotherwise implicit syntax for saying "I want this to happen when this is set" [2:28pm] mda: and the person using the table or combobox widget can declare their widget instance to have that data come from: static inline content, or remote content as xml, or remote content as js, or some js function call, or some expression (xpath?) applied to another bound variable. [2:28pm] slightlyoff: yes [2:29pm] slightlyoff: each might also imply some kind of translator that we apply to set the end value [2:29pm] mda: i think all widgets have to implement a "redraw" method or something like that. [2:29pm] slightlyoff: they then scurry around saying "what changed?" [2:29pm] mda: if they *want* to optimize for what in particular has actually changed, they can do that. [2:29pm] slightlyoff: ah, hrm [2:29pm] mda: but minimally, all widgets have to implement that base method. [2:29pm] slightlyoff: I want watch() back in the language... [2:29pm] slightlyoff: [2:29pm] mda: that is how X Window widget sets usually did it back in the 80s, as i recall [2:30pm] slightlyoff: yeah, that's how the heavyweight widget sets do it today [2:30pm] slightlyoff: (Isomorphic, etc.) [2:30pm] manzoid joined the chat room. [2:30pm] mda: it would be something like the widget implementing changeNotify(propname, propvalue) [2:30pm] mda: and returning a boolean indicating that it has handled it or not. [2:31pm] mda: if not, or if the method doesn't exist, it calls the universal redraw() method. [2:31pm] slightlyoff: OK [2:31pm] slightlyoff: so I want something else for DOM-based widgets [2:32pm] slightlyoff: and I'll add this later: but I think I want a way to say "data bound to this property applies to this part of the template" [2:32pm] slightlyoff: although perhaps that's a separate but related problem [2:32pm] slightlyoff: right now, if I were to implement a redraw() method, it would have to know how to build each part of the widget over [2:33pm] mda: i've got this vague notion that your "template" should be merged somehow with metadata declaration of the widget. [2:33pm] slightlyoff: could be [2:33pm] slightlyoff: you could do that today by setting the templateString property in the ctor [2:33pm] dylanks: somewhat unrelated... for things like a grid or combobox, you need add/remove for data that populates subtemplates [2:33pm] slightlyoff: but they're usually pretty big/long [2:33pm] slightlyoff: yes [2:33pm] mda: since something somewhere needs to be able to say that the title property is a string without markup, etc. [2:34pm] mda: for kaiser i had to implement the ability to dynamically add new expander definitions for the textarea without a refresh. [2:34pm] mda: that was a bit of a pain. [2:34pm] slightlyoff: I can imagine [2:34pm] mda: because the code was very oriented around doing everything at constructor time. [2:34pm] slightlyoff: my bad [2:35pm] mda: so imposing some requirements on widget writers i think is entirely fair. [2:35pm] slightlyoff: I agree [2:35pm] mda: in particular, doing everything at constructor time is natural for the web apps that are doing page refreshes all the time. [2:35pm] mda: but not for what we are imagining where they sit there forever. [2:35pm] slightlyoff: agreed [2:36pm] slightlyoff: also, I kind of get the feeling that it should always be easy for someone to take boilerplate widget code and wire things up [2:36pm] slightlyoff: so whatever constraints we impose shouldn't endanger that [2:36pm] slightlyoff: today, it's actually reasonably straightforward [2:37pm] mda: i also think there are two levels of declaration complexity. [2:37pm] slightlyoff: ? [2:37pm] mda: for the person writing a GUI declaration. [2:37pm] mda: there is the simple case where they just say that the grid data comes from this remote URL. [2:38pm] mda: and then various default policies are used for polling, or fetch once, etc. [2:38pm] mda: but then there is the more complex case where there is a level of indirection, so that the person can declare that stuff. [2:38pm] mda: they can say that the values of the griddata comes from invoking the "alaskatemp" service. [2:39pm] mda: and the "alaskatemp" service is declared elsewhere, with some properties about it. [2:39pm] mda: the difference is whether there is an explicit declaration of that data source, or it is all inline. [2:39pm] mda: you make it explicit if you want to set non-default treatment of it, or share it among multiple properties, or just make your code cleaner. [2:40pm] slightlyoff: sure [2:40pm] slightlyoff: this is starting to sound like the propertyset concept that Dylan and I have been working on [2:40pm] slightlyoff: but with the second level of indirection added [2:40pm] mda: another case of indirection is where you want to set the value to some calculation . [2:41pm] mda: some computed value. [2:41pm] slightlyoff: yes [2:41pm] mda: for example, suppose you want to set the width of the box to the temperature, *and* update a label that gives the temperature in farenheit. [2:41pm] slightlyoff: and in that case, you need some sort of selector syntax [2:41pm] mda: that *could* be done by a custom change notification handler. [2:41pm] mda: but instead i'd rather just declare both properties, and have the infrastructure do it. [2:42pm] slightlyoff: so would we then have properties that act as calculations? [2:42pm] slightlyoff: (properties of the widget, taht is) [2:43pm] dylanks: so we had talked a lot early on about basically providing what is in essence script based transformations of data [2:43pm] dylanks: so that the data from a remote source doesn't have to map directly to what a widget expects [2:44pm] slightlyoff: you would provide some sort of transformation object that acted as a proxy [2:44pm] slightlyoff: but we run into all kinds of dirty-data issues with back-propigation of changes from the UI [2:44pm] mda: laszlo and avalon have some support for such dependency tracking, as i recall. [2:45pm] mda: it is a familiar problem with every mature gui toolkit. [2:45pm] mda: i remember the old days of the motif XmForm.... [2:45pm] slightlyoff: well, I'm glad that I'm running into problems of mature toolkits and not just immature toolkits = ) [2:45pm] mda: you drag one thing, and it spends a minute vibrating with dependencies.... [2:45pm] slightlyoff: heh [2:47pm] slightlyoff: I'd like it to be hard for users to hurt themselves like that...or at least an intentional choice [2:48pm] dylanks: any thoughts from anyone else, or have we overwhelmed you all? [2:49pm] slightlyoff: so I think the easy thing to do is mark data w/ an "isDirty" flag and refuse to back-propigate changes [2:49pm] slightlyoff: which is fine [2:50pm] slightlyoff: but it gets us back to the question of bi-directional data [2:50pm] slightlyoff: should we even try to solve it? [2:50pm] dylanks: the approach I've been taking is as follows [2:51pm] dylanks: basically I update on the client when I submit [2:51pm] dylanks: and then I update from the server when I'm notified of an update [2:51pm] dylanks: so basically I update twice [2:51pm] dylanks: the isDirty would apply between the two updates [2:52pm] slightlyoff: right [2:52pm] dylanks: it works ok with small data [2:52pm] slightlyoff: so you just make an end-run around synchronization [2:52pm] dylanks: not sure how/if it scales [2:52pm] dylanks: right [2:53pm] slightlyoff: so lets assume that we're working with a paged data set (sane), it won't really ever hurt the client too badly until and unless the server chokes on calculations for the updated ata [2:53pm] slightlyoff: data [2:53pm] slightlyoff: and if it's offloading some of that to the client anyway, no big deal [2:54pm] slightlyoff: which just leaves us w/ specifying how to propagate changes back [2:54pm] dylanks: or if the data change isn't accepted/allowed [2:54pm] slightlyoff: yes [2:54pm] slightlyoff: which should probably be the default? [2:55pm] dylanks: right [2:55pm] dylanks: so by how to propagate, you are wondering if we have an interface for specifying diffs? [2:55pm] slightlyoff: no, just a way to specify a URL or other type of method to pass the new data back to [2:56pm] slightlyoff: SOAP, REST, function call, etc. [2:56pm] dylanks: gotcha [2:56pm] dylanks: so basically something like dojo.io.bind, but that creates the thing to be sent/posted/enveloped/etc. [2:57pm] slightlyoff: yes, and a way of specifying it along with the bound data [2:57pm] slightlyoff: source [2:57pm] dylanks: right... so I'm currently doing this with post, and just populating a form [2:58pm] dylanks: for get/post requests at least [2:58pm] slightlyoff: right, I think that'll be a common case [2:58pm] slightlyoff: we're just turning the widget into a protocol participant [2:58pm] dylanks: right [2:58pm] slightlyoff: which is, frankly, what I think they should be doing [2:58pm] dylanks: so I guess there needs to be a way to specify what properties the server expects [2:59pm] slightlyoff: yeah, but I think this goes back to mda's concept of multiple levels of indirection [2:59pm] dylanks: for example, if there's a generic url, and then a property to specify the data record [2:59pm] dylanks: gotcha [2:59pm] slightlyoff: where each level of indirection can specify it's preferred method of handling updates [2:59pm] slightlyoff: and the one "closest" to the wire actually wins [2:59pm] dylanks: did we lose mda? [3:00pm] dylanks: seems like I'm talking a lot more now [3:00pm] slightlyoff: : \ [3:00pm] mda: mda just got called into a kaiser outage.... [3:00pm] slightlyoff: ouch [3:00pm] slightlyoff: at least they pay you by the hour [3:02pm] slightlyoff: so we've at least got a couple of organizing principles for doing a design: [3:03pm] dylanks: yes [3:03pm] mda: we haven't talked about xpath vs. javascript vs. something else. [3:03pm] mda: but i don't think we need to. [3:03pm] slightlyoff: my feeling is that at the end of the day, it's all gotta run through JS anyway [3:03pm] mda: because i think the answer is (1) you get a lot of mileage without any expressions, and (2) we can support both. [3:04pm] dylanks: agreed [3:04pm] slightlyoff: I agree on both counts [3:04pm] dylanks: and JS is the one that will get implemented first [3:04pm] mda: i might have been imagining it, but i thought i even saw an IETF draft for a "data:" url. [3:04pm] mda: for inline values.... [3:04pm] dylanks: svg has that [3:05pm] slightlyoff: they use it for specifying paths, right? [3:05pm] dylanks: also for raster image data [3:06pm] dylanks: so any questions before Alex summarizes? [3:06pm] slightlyoff: well, I don't know that we have enough for a summary yet [3:06pm] slightlyoff: we have some principles: [3:06pm] slightlyoff: don't make the end-developer work [3:06pm] dylanks: (that's what I meant) [3:06pm] slightlyoff: make most translations implicit if possible, and put the burden on the widget author where you can't [3:07pm] slightlyoff: and allow layering of both data reading and writing activities for those that need it [3:07pm] slightlyoff: so, about those APIs... [3:07pm] slightlyoff: [3:08pm] slightlyoff: what SHOULD this look like to a.) [3:08pm] slightlyoff: the end developer [3:08pm] slightlyoff: b.) the widget author [3:09pm] slightlyoff: c.) the core infrastructure [3:09pm] slightlyoff: (in that order) [3:09pm] dylanks: well, a probably needs to be possible with just attributes [3:09pm] dylanks: for most common cases [3:09pm] slightlyoff: well, we've got attribute/subitem duality via the parser [3:10pm] dylanks: yes, those are equivalent in my mind... point was just some properties in markup [3:10pm] slightlyoff: but I agree, the syntax should lend itself to being settable as just an attr for most cases [3:10pm] dylanks: exactly [3:11pm] dylanks: ie dataProvider="someUrl" [3:11pm] slightlyoff: so how does the end widget author say: "set this property of the widget to be equal to this value from this peice of data" [3:11pm] slightlyoff: well, more like: [3:12pm] dylanks: something like [3:12pm] slightlyoff: dataProvider="name:foo; source: someVariable;" bindData="localAttribute: foo.bar.baz" [3:12pm] slightlyoff: mda, suggestions? [3:13pm] dylanks: problem with two attributes is how do you tie them together [3:13pm] slightlyoff: yes [3:13pm] slightlyoff: I agree [3:13pm] dylanks: and multiple providers [3:13pm] slightlyoff: also true [3:14pm] dylanks: so really you need a data provider list [3:14pm] slightlyoff: yes [3:14pm] slightlyoff: and a compact syntax [3:14pm] dylanks: and here's where we run into trouble of how we want to specify them (xpath, js object style, css style, etc.) [3:14pm] mda: i guess i'm not a big fan of it being so provider-ish. [3:15pm] mda: makes it smell of java [3:15pm] dylanks: meaning the name or how it works? [3:15pm] mda: the name. [3:15pm] dylanks: alex really like the name canvas [3:15pm] dylanks: [3:15pm] slightlyoff: [3:16pm] dylanks: I'm pretty sure I picked up the idea of Provider from either laszlo or flex [3:16pm] slightlyoff: and Java! don't forget how much I love java! [3:16pm] mda: [3:16pm] mda: : [3:16pm] mda: [3:17pm] slightlyoff: no selector syntax (even an eval())? [3:17pm] mda: dojo:set name="width" expr-type="text/javascript" expr="1 + 1"/> [3:18pm] mda: [3:18pm] mda: or maybe js-expr and xpath-expr and forget about expr-type [3:18pm] slightlyoff: sure [3:18pm] slightlyoff: WFM [3:19pm] mda: [3:19pm] mda: that may be the same as src..... [3:19pm] mda: i'm just not sure what to do about things like "data:" and "javascript:" [3:20pm] dylanks: well, we have a few choices... attr name, separate attr, or wrap the attr value... is value="js( )" [3:22pm] slightlyoff: so MDA, I think we could get layering of this kind of thing using the propertyset mechanism [3:23pm] mda: ok. [3:23pm] slightlyoff: where you define your tags somewhere, give them a name, and then mix them in by specifying them as properties to get mixed in [3:23pm] slightlyoff: or give the a "type" and have it apply to all widgets of that type [3:24pm] slightlyoff: so from that perspective, I think we've got some of the layering groundwork done [3:24pm] slightlyoff: it doesn't sound like we're coming up w/ a simple syntax that you can use on the widget, though [3:25pm] slightlyoff: or rather, as an attribute of widget declaration [3:25pm] slightlyoff: like: [3:25pm] slightlyoff: [3:25pm] mda: well, you can still say [3:25pm] mda: but i think for any value that isn't a literal, you have to be nested. [3:26pm] slightlyoff: alrighty [3:26pm] mda: [3:26pm] dylanks: well, unless the data source is just a list of name value pairs [3:26pm] dylanks: that applies directly [3:26pm] slightlyoff: I'm actually fine with now that we've shown it's not easy [3:27pm] slightlyoff: s/with/with that/ [3:28pm] slightlyoff: so as for the widget author, what should (s)he be expecting? [3:28pm] slightlyoff: we mentioned the need to be notified [3:29pm] slightlyoff: and, worst case, provide for a full "repaint" [3:30pm] slightlyoff: man, while we're yapping, Schontzler going to town on the animation stuff [3:30pm] dylanks: yup [3:30pm] dylanks: I'm discussing that with him as well [3:31pm] slightlyoff: w00t! [3:32pm] slightlyoff: so how do we make this easy for widget authors? [3:32pm] mda: what i'd like to see for the widget author is something a bit like what i did in burst, where there is an explicit declaration of all the properties of the widget. [3:32pm] slightlyoff: howso? [3:32pm] slightlyoff: (pointer to code?) [3:32pm] mda: giving type, name, default value, help string in english, optional vs. mandatory, the usual thing. [3:33pm] mda: then, if they do that, the widget author is free to simply refer to this.mydata [3:33pm] mda: the values are just taken care of by the core, without the widget author knowing. [3:33pm] slightlyoff: so would that be a packed structure (object) that you set for every property that can be used this way? [3:34pm] slightlyoff: or more like a pre-preocessor? [3:36pm] mda: see http:/​​/​​burstproject.org/​​burst/​​webui/​​widgets/​​SortTable.js [3:37pm] slightlyoff: hrm, OK [3:38pm] dylanks: way too long for me to parse while chatting [3:38pm] slightlyoff: if done this way, we could actually build implicit getters/setters for these things [3:38pm] mda: so you can see that PROP_DEFS data structure. [3:38pm] mda: which of course could have been done in XML for the true believers. [3:39pm] slightlyoff: heh [3:39pm] slightlyoff: the last thing this toolkit needs is a strong reliance on XML in environments where it's not free [3:40pm] mda: there is extra trickier in the build process where those same property declarations that are used by the code are *also* used in the generated documentation. [3:40pm] mda: http:/​​/​​burstproject.org/​​build/​​apidoc/​​html/​​classburst_1_1webui_1_1widgets_1_1SortTable.html [3:40pm] slightlyoff: custom parsing for doxygen? [3:41pm] mda: right. [3:41pm] mda: some bastard combination of perl and java. [3:41pm] mda: you don't want to see how the sausage is made. [3:42pm] mda: oh wait, you guys have already been exposed to my makefiles.... [3:43pm] dylanks: [3:44pm] slightlyoff: yeah, they're the reason I keep clinging to my hope of generating docs straight from Rhino [3:45pm] mda: keep in mind that this declaration can also be the basis some day of a graphical gui builder... [3:46pm] slightlyoff: yeah, with automatic property introspection [3:46pm] slightlyoff: OK, this is actually pretty siple [3:46pm] slightlyoff: simple [3:46pm] slightlyoff: and retrofitting the mix-in properties code to handle this is straightforward [3:50pm] slightlyoff: so widget authors should be able to expect that any property built this way will be available for binding [3:50pm] slightlyoff: are there open loose ends that I'm missing before I go post a log of this discussion the Dojo site? [3:53pm] mda: well, there is the aspect of how this relates to styling. [3:53pm] dylanks: how so? [3:54pm] mda: well, you might want to be able to tie color, width, background image, etc. to remote data. [3:54pm] dylanks: how to connect data to style attributes [3:55pm] mda: or make it computed. [3:55pm] mda: right; the issue is that it is a case where there is no explicit metadata for the properties. [3:55pm] mda: the stumbling block is the general problem we've hit before, which is how to support styling of widgets without exposing too much of their internals. [3:55pm] slightlyoff: well, those are DOM properties generally, and I say that's up toe the wiget [3:55pm] slightlyoff: widget [3:56pm] dylanks: I was going to say it's the widget authors pain as well [3:56pm] dylanks: but maybe we provide something to widget authors to ease their map [3:56pm] dylanks: pain, not map [3:56pm] slightlyoff: I can see building a proxy attribute and doing a connect() to the implicit setter [3:56pm] slightlyoff: and maybe make a shorthand for that pattern from the template? [3:57pm] slightlyoff: or from the widget? [3:57pm] mda: one of these other toolkits has a delegation model. [3:58pm] mda: i forget which one.... [3:58pm] slightlyoff: hrm, how would that help? [3:58pm] mda: it helps the widget implementor. [3:58pm] slightlyoff: I was trying to think through style and DOM value assignment the other day [3:58pm] slightlyoff: and given the issues, I eventually wound up w/ some sort of eval()-able JS that the widget author can set [3:59pm] mda: they can say that setting the color of the widget (which is the js thing) is equivalent of setting the DOM/CSS color of this member DOM object. [3:59pm] slightlyoff: ah, OK [4:00pm] slightlyoff: a quick google turns up lots of references to event delegation models [4:00pm] slightlyoff: but nothing about property setting (or nothing that I'm seeing) [4:01pm] slightlyoff: boodman had mentioned that XBL has an inherits tag that handles something like this [4:01pm] slightlyoff: but since we can't count on sanity for property setting, it needs to be more flexible [4:01pm] slightlyoff: take the case of setting a CSS class [4:02pm] slightlyoff: I SHOULD be able to say node.className = "foo" [4:02pm] slightlyoff: but some browsers prefer setAttribute("class", "foo"); [4:03pm] slightlyoff: so do we just punt on this for now and revisit as necesaray? [4:03pm] mda: i think so. [4:05pm] slightlyoff: OK [4:05pm] slightlyoff: alright, we just crossed the oh-so-magical 2-hour line [4:05pm] slightlyoff: I'm gonna cut this off now for the sake of everyone = )