Time Who Said
[10:04am]slightlyoffhowdy
[11:46am]tris left the chat room. (Read error: 60 (Operation timed out))
[12:07pm]tris joined the chat room.
[12:58pm]slightlyoffhey tris, do you work on ehtereal?
[1:30pm]fbos joined the chat room.
[1:30pm]slightlyoffhowdy
[1:30pm]fbosHi
[1:31pm]fbosI understand there's a chat 'round 2 PM PST ?
[1:31pm]slightlyoffthat's the hope = )
[1:31pm]slightlyoff(this is Alex, btw)
[1:31pm]fbosAbout data binding... So, what's to talk about ?
[1:32pm]fbosGreat, pleased to meet you, I am FranÁois incompatible encoding
[1:32pm]slightlyoffso we've known for a long time that Dojo is going to need some sort of nice way to provide data binding
[1:32pm]slightlyoffand bi-directional binding at that
[1:32pm]fbosBinding to databases or XML ?
[1:33pm]slightlyoffdoes it matter?
[1:33pm]slightlyoffone can be the other
[1:33pm]fbosJust wanted to make sure we were talking about the same thing
[1:33pm]slightlyoffoh, OK
[1:33pm]fbosAny plans currently ?
[1:33pm]fbos(BTW, anybody keeping a log for offline use ?)
[1:33pm]slightlyoffnope, other than to spec out a sane api for dojo to use on the client side
[1:33pm]slightlyoff(I am)
[1:34pm]slightlyoffand then provide some way for people to map that to data sources on servers
[1:34pm]fbosSo, the hope is to say something like "bind control X to such and such at URL Y" ?
[1:34pm]slightlyoffwe have all kinds of issues like paging, flat vs. hierarchial, etc. to work through
[1:34pm]slightlyoffif that's what the developer wants, yes
[1:35pm]slightlyoffbut like all things Dojo, the easy things should be trivial and the hard things easier
[1:35pm]fbosI have to admit I stumbled upon Dojo when I was searching for an Ajax-style JavaScript solution.
[1:35pm]fbosI only used dojo.io.bind() at the moment.
[1:35pm]slightlyoffso 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]slightlyoffhow are you finding it?
[1:36pm]fbosGreat !
[1:36pm]fbosIt's working just fine.
[1:36pm]slightlyoffI built a new package the other day
[1:36pm]slightlyoffit fixes some bugs that people were reporting with back-button stuff
[1:36pm]fbosYes, I saw, but I'm using a checked out copy.
[1:36pm]slightlyoffok
[1:36pm]fbosI 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]slightlyoffahh = )
[1:37pm]fbosIt'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]slightlyoffok
[1:37pm]fbosOn the server, I have a PHP script which generates XML which in turn contains things like 12.22Expedited
[1:37pm]fbosyada, yada
[1:37pm]slightlyoffrighty
[1:37pm]fbosThere can be multiple items
[1:37pm]slightlyoffok
[1:38pm]fbosSo, I have an HTML SELECT control at the moment
[1:38pm]fbosI'm using dojo.io.bind to get at the XML, and then I'm parsing to create OPTION elements, live
[1:39pm]slightlyoffright, makes sense
[1:40pm]fbosIt's slightly painful to create the elements by-hand
[1:40pm]fbosIf there is some kind of data binding, I would like to say:
[1:40pm]fbosattach(ID of element, URL, XPath expression)
[1:40pm]slightlyoffah, hrm
[1:41pm]slightlyoffso I guess I'm a bit wary of xpath right now (on the client, anyway)
[1:41pm]slightlyoffbut I can see your point
[1:41pm]fbosYeah, sure. That was in an ideal world, of course
[1:41pm]slightlyoffheh
[1:41pm]slightlyoffif xpath is ideal, I want a new world
[1:42pm]fbosOf 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]slightlyoffright
[1:42pm]slightlyoffso I think the Dojo approach for something like this would be a widget
[1:42pm]slightlyoffwhich would handle the creation of the elements
[1:42pm]slightlyoffand the widget would get bound to the data source
[1:42pm]slightlyoffbut I'm just ad-libbing here
[1:42pm]fbosOk, NP
[1:43pm]slightlyoffsince we don't even know what binding will look like yet
[1:43pm]slightlyoffI'm in the middle of an article on fast widget authoring
[1:43pm]slightlyoffbut it's not done yet = \
[1:43pm]fbosRefreshing the control's values must || should be manual && automatic.
[1:43pm]fbosIn my case, I know when to refresh - every time the user changes the destination country
[1:44pm]fbosBut I can envision use cases where the values should refresh themselves.
[1:46pm]slightlyoffrefresh themselves? based on what event?
[1:46pm]fbosTime ? Other controls changing values ? Randomly ?
[1:46pm]slightlyoffok
[1:47pm]fbosOkay, third one's probably not that useful, but time is surely something important.
[1:47pm]fbosSome kind of polling, since we can't get a notification when the server's view of the world changes.
[1:48pm]fbosHTTP already offers "304 Not Modified" for such cases
[1:49pm]slightlyoffso we've already talked about things like mod_pubsub or LivePage for up-to-date communciation w/ the server
[1:49pm]slightlyoffbut I've already had other requests for polling w/ bind()
[1:50pm]fbosWasn't aware of that.
[1:50pm]fbosBut it would probably be something interesting.
[1:50pm]slightlyoffI've started on the mod_pubsub port, but there are integration issues w/ the current server
[1:50pm]slightlyoffI started on the LivePage port yesterday
[1:51pm]slightlyoffand that looks more promising
[1:51pm]PSquad32 joined the chat room.
[1:51pm]PSquad32hey there
[1:51pm]PSquad32<-- Patrick Lightbody
[1:51pm]slightlyoffhi Patrick!
[1:51pm]fbosHello Patrick,
[1:51pm]PSquad32i'll mostly be lurking
[1:51pm]fbosHow do you do ?
[1:51pm]fbosOk
[1:52pm]progrium joined the chat room.
[1:52pm]slightlyoffI'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]fbosYummy!
[1:53pm]slightlyoffeh, there's not much there
[1:53pm]slightlyoffand I dislike the API
[1:53pm]fbosWell, something's better than nothing when we want to discuss
[1:53pm]slightlyoffbut it would at be nice to have it at least semi-functional = )
[1:54pm]PSquad32who is the moderator for this meeting?
[1:56pm]slightlyoffI guess me = )
[1:56pm]PSquad32ok, is there an agenda?
[1:56pm]slightlyoffalthough I'm more inflamitory than most people
[1:56pm]PSquad32are you Alex?
[1:56pm]slightlyoffother than to come up w/ a sane set of APIs for producers and consumers of data, no
[1:56pm]slightlyoffyes, I'm alex
[1:57pm]PSquad32ok, well i suggest in the future that an agenda be set -- especially when you get more users, things can get hectic
[1:57pm]PSquad32anyway, my personal feelings are that Dojo is missing a framework for bring users in to the fold and understanding what dojo is
[1:57pm]progriumyay for agendas
[1:58pm]fbosOkay, I gotta go, since my wife just came in.
[1:58pm]fbosHave a nice one, everyone !
[1:58pm]fbos left the chat room.
[1:58pm]PSquad32given 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]PSquad32lemme dig up a good example of this:
[1:58pm]slightlyoffwell, I've started working on an article that discusses how to easily build widgets
[1:58pm]slightlyoffbut yes, I see your point
[1:59pm]PSquad32http:/​​/​​www.laszlosystems.com/​​lps/​​laszlo-in-ten-minutes/​​
[1:59pm]dylanks joined the chat room.
[1:59pm]alerque_ joined the chat room.
[1:59pm]PSquad32see how they show you some code, plus what it is renders as? then they let you _change_ the code
[1:59pm]progriumor a video of making something cool like ruby on rails, haha
[1:59pm]PSquad32that would get people having that "Ah ha!" moment _much_ faster
[1:59pm]schontz joined the chat room.
[2:00pm]slightlyoffso who's gonna help w/ this stuff?
[2:00pm]slightlyoffI agree w/ everything you're saying
[2:00pm]slightlyoffbut I'm swamped
[2:00pm]PSquad32yes, help is definitely needed
[2:00pm]PSquad32what i found at OpenSymphony is that all you have to do is establish the framework, then others will do the ground work
[2:01pm]PSquad32for example, write one tutorial like in that example URL
[2:01pm]PSquad32others will write the rest
[2:01pm]You changed the topic to "data binding for fun and profilt!".
[2:01pm]dylankswhat's profilt?
[2:02pm]slightlyoffyou can "/topic" just as well as I can
[2:03pm]slightlyoffone of the things that might good would be a tutorial on how to use JS inside the wiki
[2:03pm]slightlyoffsince that might be somepalce where people could work on this kind of thing
[2:03pm]dylanksare mda or trenka going to join us?
[2:03pm]slightlyoffdunno, ping 'em
[2:03pm]slightlyoffI would hope for at least one or the other
[2:05pm]slightlyoffso it's 2:05 by my clock
[2:05pm]PSquad32i concur
[2:05pm]PSquad32(that it is 2:05 )
[2:05pm]dylanksno from trenka
[2:05pm]schontz left the chat room.
[2:05pm]dylanksno response from mda
[2:05pm]slightlyoffhrm
[2:05pm]dylanksoh wait, mda is on his way
[2:05pm]slightlyoffgreat!
[2:06pm]PSquad32who is mda?
[2:06pm]slightlyoffMark Anderson
[2:06pm]slightlyoffauthor of the the Burst library
[2:06pm]dylanksburstlib
[2:06pm]slightlyoffand a freaking smart guy
[2:06pm]slightlyoffhe is a committer to netWindows as well
[2:07pm]slightlyoffhe also came up w/ the basics of the bind() API and the Dojo bootstrap system
[2:07pm]mda joined the chat room.
[2:07pm]slightlyoffspeak of the devil!
[2:07pm]slightlyoffhi Mark
[2:07pm]mdahi.
[2:07pm]dylanksso 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]mdayes data binding - what has happened since the last time we discussed it?
[2:08pm]slightlyoffnada
[2:08pm]dylankswell, not exactly
[2:08pm]slightlyoffI'm afraid = \
[2:08pm]dylanksbasically I've implemented some very basic interfaces for it
[2:09pm]dylanksbasically all it does now though is two things:
[2:09pm]slightlyoffas have I (but they're not passing my tests right now)
[2:09pm]dylanksfetch an external data file that is a JS object, load/eval it with dojo.io.bind, and provide it to a widget
[2:09pm]dylanksby specifying a dataProvider attribute
[2:10pm]slightlyoffright
[2:10pm]dylanks2) an abstract dataProvider class
[2:10pm]dylanksthat basically is something widgets can read and write to
[2:10pm]mdawhat is an example of a dataProvider attribute?
[2:10pm]dylanksdataProvider="someUrl" in markup
[2:11pm]slightlyoffdyaln, is this checked in somewhere that we can look at?
[2:11pm]dylanksthe abstract data provider basically can live independently before a widget is created or after it is destroyed
[2:11pm]dylankslet me see
[2:12pm]dylanksthe code to load it is checked in, but no example of the data itself yet
[2:12pm]slightlyoffOk
[2:12pm]dylanksbasically it is just a JS object of key value pairs
[2:12pm]slightlyoffso making this a bit more concrete, my current use case is for a combo box
[2:12pm]dylanksof which the value can also be objects
[2:12pm]slightlyoffright
[2:12pm]slightlyoffand I can easily see one for "grid" type data
[2:12pm]slightlyoffas well as tree-style data (trees, menus, etc.)
[2:13pm]dylanksbasically anything where it isn't just a set of attributes
[2:13pm]dylanksor where incremental loading or replacement of data is needed
[2:13pm]slightlyoffand 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]slightlyoffmy first thought was that there should be a couple of mixins/interfaces for data providers
[2:14pm]schontz left the chat room.
[2:14pm]slightlyoffand that they should all be asynchronous
[2:14pm]dylanksis everyone following what we're talking about?
[2:14pm]progriumyes and no
[2:15pm]mdaafaik what is currently implemented isn't really data binding.
[2:16pm]mdait is more a convenience for a widget declaration to say where some remote data comes from.
[2:16pm]dylanksfeel free to ask questions...
[2:16pm]mdabut it is up to that widget implementation to programmatically decide what to do with that data.
[2:16pm]dylanksright
[2:16pm]dylanksI said it was primitive
[2:17pm]progriumwhat's the alternative?
[2:17pm]mdawhereas 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]progriumah
[2:17pm]dylanksnegative widths?
[2:17pm]mdait would be in kelvin
[2:18pm]slightlyoffheh
[2:18pm]slightlyoffso lets work backwards from that definition
[2:18pm]dylanksso basically we need some ideas for ways of providing useful interfaces for both
[2:19pm]slightlyoffMDA's definition implies what you want
[2:20pm]dylanksright... just reframing the question...
[2:20pm]slightlyoffOK
[2:20pm]mdai think the missing (bridging) piece is that there has to be an indicator of what propert of the widget is being set.
[2:20pm]mdai mean, i guess it could be some property named "data"
[2:20pm]dylanksyeah, right now it is dataProvider
[2:21pm]mdano, dataProvider is the url where you get the value.
[2:21pm]mdathe question is what is the variable that is being set to that value?
[2:21pm]mdait is some property of the widget such as "combochoices" or "tablevalues"
[2:22pm]mdai 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]mdaand so that you can actually set multiple distinct properties of a single widget to different data sources.
[2:22pm]slightlyoffso throwing a bit of every-more-icky reality into the situation: we can't detect property changes or act on them
[2:22pm]slightlyoffwe can detect and act on function calls, however
[2:23pm]progriumgetters and setters : \
[2:23pm]dylanksthis 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]dylanksyeah, getters and setters buy us that, but suck in having to have them
[2:24pm]slightlyoffor an observer that's keyed by name
[2:24pm]slightlyoffwhich you can listen to
[2:25pm]slightlyoffsome function that gets called when a property gets set and passes that name in
[2:25pm]slightlyoffanyway, that's putting the cart before the horse
[2:25pm]dylanksright
[2:26pm]mdawhat i want to do is find a way where the common use cases require no coding at all.
[2:26pm]slightlyoffI agree w/ mda that we should be able to bind different properties to different sources
[2:26pm]slightlyoffamen = )
[2:26pm]mdai mean, except for core implementors.
[2:26pm]slightlyoffyes
[2:26pm]dylanks
[2:27pm]slightlyoffso 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]mdabut 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]mdait doesn't care or want to know how that value comes in at run time.
[2:27pm]slightlyoffsure, 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]dylanksor when it has expired
[2:28pm]slightlyoffor anotherwise implicit syntax for saying "I want this to happen when this is set"
[2:28pm]mdaand 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]slightlyoffyes
[2:29pm]slightlyoffeach might also imply some kind of translator that we apply to set the end value
[2:29pm]mdai think all widgets have to implement a "redraw" method or something like that.
[2:29pm]slightlyoffthey then scurry around saying "what changed?"
[2:29pm]mdaif they *want* to optimize for what in particular has actually changed, they can do that.
[2:29pm]slightlyoffah, hrm
[2:29pm]mdabut minimally, all widgets have to implement that base method.
[2:29pm]slightlyoffI want watch() back in the language...
[2:29pm]slightlyoff
[2:29pm]mdathat is how X Window widget sets usually did it back in the 80s, as i recall
[2:30pm]slightlyoffyeah, that's how the heavyweight widget sets do it today
[2:30pm]slightlyoff(Isomorphic, etc.)
[2:30pm]manzoid joined the chat room.
[2:30pm]mdait would be something like the widget implementing changeNotify(propname, propvalue)
[2:30pm]mdaand returning a boolean indicating that it has handled it or not.
[2:31pm]mdaif not, or if the method doesn't exist, it calls the universal redraw() method.
[2:31pm]slightlyoffOK
[2:31pm]slightlyoffso I want something else for DOM-based widgets
[2:32pm]slightlyoffand 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]slightlyoffalthough perhaps that's a separate but related problem
[2:32pm]slightlyoffright 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]mdai've got this vague notion that your "template" should be merged somehow with metadata declaration of the widget.
[2:33pm]slightlyoffcould be
[2:33pm]slightlyoffyou could do that today by setting the templateString property in the ctor
[2:33pm]dylankssomewhat unrelated... for things like a grid or combobox, you need add/remove for data that populates subtemplates
[2:33pm]slightlyoffbut they're usually pretty big/long
[2:33pm]slightlyoffyes
[2:33pm]mdasince something somewhere needs to be able to say that the title property is a string without markup, etc.
[2:34pm]mdafor kaiser i had to implement the ability to dynamically add new expander definitions for the textarea without a refresh.
[2:34pm]mdathat was a bit of a pain.
[2:34pm]slightlyoffI can imagine
[2:34pm]mdabecause the code was very oriented around doing everything at constructor time.
[2:34pm]slightlyoffmy bad
[2:35pm]mdaso imposing some requirements on widget writers i think is entirely fair.
[2:35pm]slightlyoffI agree
[2:35pm]mdain particular, doing everything at constructor time is natural for the web apps that are doing page refreshes all the time.
[2:35pm]mdabut not for what we are imagining where they sit there forever.
[2:35pm]slightlyoffagreed
[2:36pm]slightlyoffalso, 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]slightlyoffso whatever constraints we impose shouldn't endanger that
[2:36pm]slightlyofftoday, it's actually reasonably straightforward
[2:37pm]mdai also think there are two levels of declaration complexity.
[2:37pm]slightlyoff?
[2:37pm]mdafor the person writing a GUI declaration.
[2:37pm]mdathere is the simple case where they just say that the grid data comes from this remote URL.
[2:38pm]mdaand then various default policies are used for polling, or fetch once, etc.
[2:38pm]mdabut then there is the more complex case where there is a level of indirection, so that the person can declare that stuff.
[2:38pm]mdathey can say that the values of the griddata comes from invoking the "alaskatemp" service.
[2:39pm]mdaand the "alaskatemp" service is declared elsewhere, with some properties about it.
[2:39pm]mdathe difference is whether there is an explicit declaration of that data source, or it is all inline.
[2:39pm]mdayou 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]slightlyoffsure
[2:40pm]slightlyoffthis is starting to sound like the propertyset concept that Dylan and I have been working on
[2:40pm]slightlyoffbut with the second level of indirection added
[2:40pm]mdaanother case of indirection is where you want to set the value to some calculation .
[2:41pm]mdasome computed value.
[2:41pm]slightlyoffyes
[2:41pm]mdafor 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]slightlyoffand in that case, you need some sort of selector syntax
[2:41pm]mdathat *could* be done by a custom change notification handler.
[2:41pm]mdabut instead i'd rather just declare both properties, and have the infrastructure do it.
[2:42pm]slightlyoffso would we then have properties that act as calculations?
[2:42pm]slightlyoff(properties of the widget, taht is)
[2:43pm]dylanksso we had talked a lot early on about basically providing what is in essence script based transformations of data
[2:43pm]dylanksso that the data from a remote source doesn't have to map directly to what a widget expects
[2:44pm]slightlyoffyou would provide some sort of transformation object that acted as a proxy
[2:44pm]slightlyoffbut we run into all kinds of dirty-data issues with back-propigation of changes from the UI
[2:44pm]mdalaszlo and avalon have some support for such dependency tracking, as i recall.
[2:45pm]mdait is a familiar problem with every mature gui toolkit.
[2:45pm]mdai remember the old days of the motif XmForm....
[2:45pm]slightlyoffwell, I'm glad that I'm running into problems of mature toolkits and not just immature toolkits = )
[2:45pm]mdayou drag one thing, and it spends a minute vibrating with dependencies....
[2:45pm]slightlyoffheh
[2:47pm]slightlyoffI'd like it to be hard for users to hurt themselves like that...or at least an intentional choice
[2:48pm]dylanksany thoughts from anyone else, or have we overwhelmed you all?
[2:49pm]slightlyoffso I think the easy thing to do is mark data w/ an "isDirty" flag and refuse to back-propigate changes
[2:49pm]slightlyoffwhich is fine
[2:50pm]slightlyoffbut it gets us back to the question of bi-directional data
[2:50pm]slightlyoffshould we even try to solve it?
[2:50pm]dylanksthe approach I've been taking is as follows
[2:51pm]dylanksbasically I update on the client when I submit
[2:51pm]dylanksand then I update from the server when I'm notified of an update
[2:51pm]dylanksso basically I update twice
[2:51pm]dylanksthe isDirty would apply between the two updates
[2:52pm]slightlyoffright
[2:52pm]dylanksit works ok with small data
[2:52pm]slightlyoffso you just make an end-run around synchronization
[2:52pm]dylanksnot sure how/if it scales
[2:52pm]dylanksright
[2:53pm]slightlyoffso 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]slightlyoffdata
[2:53pm]slightlyoffand if it's offloading some of that to the client anyway, no big deal
[2:54pm]slightlyoffwhich just leaves us w/ specifying how to propagate changes back
[2:54pm]dylanksor if the data change isn't accepted/allowed
[2:54pm]slightlyoffyes
[2:54pm]slightlyoffwhich should probably be the default?
[2:55pm]dylanksright
[2:55pm]dylanksso by how to propagate, you are wondering if we have an interface for specifying diffs?
[2:55pm]slightlyoffno, just a way to specify a URL or other type of method to pass the new data back to
[2:56pm]slightlyoffSOAP, REST, function call, etc.
[2:56pm]dylanksgotcha
[2:56pm]dylanksso basically something like dojo.io.bind, but that creates the thing to be sent/posted/enveloped/etc.
[2:57pm]slightlyoffyes, and a way of specifying it along with the bound data
[2:57pm]slightlyoffsource
[2:57pm]dylanksright... so I'm currently doing this with post, and just populating a form
[2:58pm]dylanksfor get/post requests at least
[2:58pm]slightlyoffright, I think that'll be a common case
[2:58pm]slightlyoffwe're just turning the widget into a protocol participant
[2:58pm]dylanksright
[2:58pm]slightlyoffwhich is, frankly, what I think they should be doing
[2:58pm]dylanksso I guess there needs to be a way to specify what properties the server expects
[2:59pm]slightlyoffyeah, but I think this goes back to mda's concept of multiple levels of indirection
[2:59pm]dylanksfor example, if there's a generic url, and then a property to specify the data record
[2:59pm]dylanksgotcha
[2:59pm]slightlyoffwhere each level of indirection can specify it's preferred method of handling updates
[2:59pm]slightlyoffand the one "closest" to the wire actually wins
[2:59pm]dylanksdid we lose mda?
[3:00pm]dylanksseems like I'm talking a lot more now
[3:00pm]slightlyoff: \
[3:00pm]mdamda just got called into a kaiser outage....
[3:00pm]slightlyoffouch
[3:00pm]slightlyoffat least they pay you by the hour
[3:02pm]slightlyoffso we've at least got a couple of organizing principles for doing a design:
[3:03pm]dylanksyes
[3:03pm]mdawe haven't talked about xpath vs. javascript vs. something else.
[3:03pm]mdabut i don't think we need to.
[3:03pm]slightlyoffmy feeling is that at the end of the day, it's all gotta run through JS anyway
[3:03pm]mdabecause i think the answer is (1) you get a lot of mileage without any expressions, and (2) we can support both.
[3:04pm]dylanksagreed
[3:04pm]slightlyoffI agree on both counts
[3:04pm]dylanksand JS is the one that will get implemented first
[3:04pm]mdai might have been imagining it, but i thought i even saw an IETF draft for a "data:" url.
[3:04pm]mdafor inline values....
[3:04pm]dylankssvg has that
[3:05pm]slightlyoffthey use it for specifying paths, right?
[3:05pm]dylanksalso for raster image data
[3:06pm]dylanksso any questions before Alex summarizes?
[3:06pm]slightlyoffwell, I don't know that we have enough for a summary yet
[3:06pm]slightlyoffwe have some principles:
[3:06pm]slightlyoffdon't make the end-developer work
[3:06pm]dylanks(that's what I meant)
[3:06pm]slightlyoffmake most translations implicit if possible, and put the burden on the widget author where you can't
[3:07pm]slightlyoffand allow layering of both data reading and writing activities for those that need it
[3:07pm]slightlyoffso, about those APIs...
[3:07pm]slightlyoff
[3:08pm]slightlyoffwhat SHOULD this look like to a.)
[3:08pm]slightlyoffthe end developer
[3:08pm]slightlyoffb.) the widget author
[3:09pm]slightlyoffc.) the core infrastructure
[3:09pm]slightlyoff(in that order)
[3:09pm]dylankswell, a probably needs to be possible with just attributes
[3:09pm]dylanksfor most common cases
[3:09pm]slightlyoffwell, we've got attribute/subitem duality via the parser
[3:10pm]dylanksyes, those are equivalent in my mind... point was just some properties in markup
[3:10pm]slightlyoffbut I agree, the syntax should lend itself to being settable as just an attr for most cases
[3:10pm]dylanksexactly
[3:11pm]dylanksie dataProvider="someUrl"
[3:11pm]slightlyoffso 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]slightlyoffwell, more like:
[3:12pm]dylankssomething like
[3:12pm]slightlyoffdataProvider="name:foo; source: someVariable;" bindData="localAttribute: foo.bar.baz"
[3:12pm]slightlyoffmda, suggestions?
[3:13pm]dylanksproblem with two attributes is how do you tie them together
[3:13pm]slightlyoffyes
[3:13pm]slightlyoffI agree
[3:13pm]dylanksand multiple providers
[3:13pm]slightlyoffalso true
[3:14pm]dylanksso really you need a data provider list
[3:14pm]slightlyoffyes
[3:14pm]slightlyoffand a compact syntax
[3:14pm]dylanksand here's where we run into trouble of how we want to specify them (xpath, js object style, css style, etc.)
[3:14pm]mdai guess i'm not a big fan of it being so provider-ish.
[3:15pm]mdamakes it smell of java
[3:15pm]dylanksmeaning the name or how it works?
[3:15pm]mdathe name.
[3:15pm]dylanksalex really like the name canvas
[3:15pm]dylanks
[3:15pm]slightlyoff
[3:16pm]dylanksI'm pretty sure I picked up the idea of Provider from either laszlo or flex
[3:16pm]slightlyoffand Java! don't forget how much I love java!
[3:16pm]mda
[3:16pm]mda:
[3:16pm]mda
[3:17pm]slightlyoffno selector syntax (even an eval())?
[3:17pm]mdadojo:set name="width" expr-type="text/javascript" expr="1 + 1"/>
[3:18pm]mda
[3:18pm]mdaor maybe js-expr and xpath-expr and forget about expr-type
[3:18pm]slightlyoffsure
[3:18pm]slightlyoffWFM
[3:19pm]mda
[3:19pm]mdathat may be the same as src.....
[3:19pm]mdai'm just not sure what to do about things like "data:" and "javascript:"
[3:20pm]dylankswell, we have a few choices... attr name, separate attr, or wrap the attr value... is value="js( )"
[3:22pm]slightlyoffso MDA, I think we could get layering of this kind of thing using the propertyset mechanism
[3:23pm]mdaok.
[3:23pm]slightlyoffwhere 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]slightlyoffor give the a "type" and have it apply to all widgets of that type
[3:24pm]slightlyoffso from that perspective, I think we've got some of the layering groundwork done
[3:24pm]slightlyoffit doesn't sound like we're coming up w/ a simple syntax that you can use on the widget, though
[3:25pm]slightlyoffor rather, as an attribute of widget declaration
[3:25pm]slightlyofflike:
[3:25pm]slightlyoff
[3:25pm]mdawell, you can still say
[3:25pm]mdabut i think for any value that isn't a literal, you have to be nested.
[3:26pm]slightlyoffalrighty
[3:26pm]mda
[3:26pm]dylankswell, unless the data source is just a list of name value pairs
[3:26pm]dylanksthat applies directly
[3:26pm]slightlyoffI'm actually fine with now that we've shown it's not easy
[3:27pm]slightlyoffs/with/with that/
[3:28pm]slightlyoffso as for the widget author, what should (s)he be expecting?
[3:28pm]slightlyoffwe mentioned the need to be notified
[3:29pm]slightlyoffand, worst case, provide for a full "repaint"
[3:30pm]slightlyoffman, while we're yapping, Schontzler going to town on the animation stuff
[3:30pm]dylanksyup
[3:30pm]dylanksI'm discussing that with him as well
[3:31pm]slightlyoffw00t!
[3:32pm]slightlyoffso how do we make this easy for widget authors?
[3:32pm]mdawhat 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]slightlyoffhowso?
[3:32pm]slightlyoff(pointer to code?)
[3:32pm]mdagiving type, name, default value, help string in english, optional vs. mandatory, the usual thing.
[3:33pm]mdathen, if they do that, the widget author is free to simply refer to this.mydata
[3:33pm]mdathe values are just taken care of by the core, without the widget author knowing.
[3:33pm]slightlyoffso would that be a packed structure (object) that you set for every property that can be used this way?
[3:34pm]slightlyoffor more like a pre-preocessor?
[3:36pm]mdasee http:/​​/​​burstproject.org/​​burst/​​webui/​​widgets/​​SortTable.js
[3:37pm]slightlyoffhrm, OK
[3:38pm]dylanksway too long for me to parse while chatting
[3:38pm]slightlyoffif done this way, we could actually build implicit getters/setters for these things
[3:38pm]mdaso you can see that PROP_DEFS data structure.
[3:38pm]mdawhich of course could have been done in XML for the true believers.
[3:39pm]slightlyoffheh
[3:39pm]slightlyoffthe last thing this toolkit needs is a strong reliance on XML in environments where it's not free
[3:40pm]mdathere 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]mdahttp:/​​/​​burstproject.org/​​build/​​apidoc/​​html/​​classburst_1_1webui_1_1widgets_1_1SortTable.html
[3:40pm]slightlyoffcustom parsing for doxygen?
[3:41pm]mdaright.
[3:41pm]mdasome bastard combination of perl and java.
[3:41pm]mdayou don't want to see how the sausage is made.
[3:42pm]mdaoh wait, you guys have already been exposed to my makefiles....
[3:43pm]dylanks
[3:44pm]slightlyoffyeah, they're the reason I keep clinging to my hope of generating docs straight from Rhino
[3:45pm]mdakeep in mind that this declaration can also be the basis some day of a graphical gui builder...
[3:46pm]slightlyoffyeah, with automatic property introspection
[3:46pm]slightlyoffOK, this is actually pretty siple
[3:46pm]slightlyoffsimple
[3:46pm]slightlyoffand retrofitting the mix-in properties code to handle this is straightforward
[3:50pm]slightlyoffso widget authors should be able to expect that any property built this way will be available for binding
[3:50pm]slightlyoffare there open loose ends that I'm missing before I go post a log of this discussion the Dojo site?
[3:53pm]mdawell, there is the aspect of how this relates to styling.
[3:53pm]dylankshow so?
[3:54pm]mdawell, you might want to be able to tie color, width, background image, etc. to remote data.
[3:54pm]dylankshow to connect data to style attributes
[3:55pm]mdaor make it computed.
[3:55pm]mdaright; the issue is that it is a case where there is no explicit metadata for the properties.
[3:55pm]mdathe 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]slightlyoffwell, those are DOM properties generally, and I say that's up toe the wiget
[3:55pm]slightlyoffwidget
[3:56pm]dylanksI was going to say it's the widget authors pain as well
[3:56pm]dylanksbut maybe we provide something to widget authors to ease their map
[3:56pm]dylankspain, not map
[3:56pm]slightlyoffI can see building a proxy attribute and doing a connect() to the implicit setter
[3:56pm]slightlyoffand maybe make a shorthand for that pattern from the template?
[3:57pm]slightlyoffor from the widget?
[3:57pm]mdaone of these other toolkits has a delegation model.
[3:58pm]mdai forget which one....
[3:58pm]slightlyoffhrm, how would that help?
[3:58pm]mdait helps the widget implementor.
[3:58pm]slightlyoffI was trying to think through style and DOM value assignment the other day
[3:58pm]slightlyoffand given the issues, I eventually wound up w/ some sort of eval()-able JS that the widget author can set
[3:59pm]mdathey 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]slightlyoffah, OK
[4:00pm]slightlyoffa quick google turns up lots of references to event delegation models
[4:00pm]slightlyoffbut nothing about property setting (or nothing that I'm seeing)
[4:01pm]slightlyoffboodman had mentioned that XBL has an inherits tag that handles something like this
[4:01pm]slightlyoffbut since we can't count on sanity for property setting, it needs to be more flexible
[4:01pm]slightlyofftake the case of setting a CSS class
[4:02pm]slightlyoffI SHOULD be able to say node.className = "foo"
[4:02pm]slightlyoffbut some browsers prefer setAttribute("class", "foo");
[4:03pm]slightlyoffso do we just punt on this for now and revisit as necesaray?
[4:03pm]mdai think so.
[4:05pm]slightlyoffOK
[4:05pm]slightlyoffalright, we just crossed the oh-so-magical 2-hour line
[4:05pm]slightlyoffI'm gonna cut this off now for the sake of everyone = )