Time | Who | Said
--- | --- | ---
[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.22 Expedited
[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 = )