fluid-work IRC Logs-2008-10-09

[07:57:04 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[08:21:54 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[08:22:52 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[08:33:10 EDT(-0400)] * jhung (n=Administ@H188.C195.cci.switchworks.net) has joined #fluid-work
[09:10:03 EDT(-0400)] * Bosmo1 (n=Bosmon@87-194-196-18.bethere.co.uk) has joined #fluid-work
[09:16:55 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279475053.dsl.bell.ca) has joined #fluid-work
[09:25:11 EDT(-0400)] * EricDalquist (n=EricDalq@static-210-59.vpn.wisc.edu) has joined #fluid-work
[09:43:53 EDT(-0400)] * athena7 (n=athena7@adsl-75-58-126-207.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[09:55:55 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[10:04:48 EDT(-0400)] * anastasiac (n=stasia@72.33.23.226) has joined #fluid-work
[10:38:42 EDT(-0400)] * apetro (n=apetro@72.33.23.236) has joined #fluid-work
[11:03:23 EDT(-0400)] <Bosmon> ping
[11:04:01 EDT(-0400)] <Justin_o> Bosmon: looking for someone or testing your connection?
[11:04:52 EDT(-0400)] <anastasiac> michelled, good morning
[11:05:10 EDT(-0400)] <michelled> good morning
[11:05:21 EDT(-0400)] <michelled> how's the unconference going?
[11:05:38 EDT(-0400)] <anastasiac> excellent - we're in the 'hanging out with the developers' phase
[11:05:48 EDT(-0400)] <michelled> fun!
[11:05:55 EDT(-0400)] <anastasiac> do you remember diagramming the parts of the Pager on the white board a while back?
[11:06:10 EDT(-0400)] <michelled> yes, quite a while ago
[11:06:29 EDT(-0400)] <anastasiac> any idea whether or not that diagram survived in some format?
[11:07:11 EDT(-0400)] <michelled> did you search the wiki? I don't have high hopes that it made it there but you never know
[11:07:36 EDT(-0400)] <anastasiac> I did search, but didn't find it. I was just wondering if you remember any photos taken.
[11:07:45 EDT(-0400)] <anastasiac> you tend to be the keeper of whiteboard photos
[11:07:50 EDT(-0400)] <anastasiac> or at least, you used to be
[11:08:00 EDT(-0400)] <anastasiac> no problem, if not
[11:08:14 EDT(-0400)] <anastasiac> I'm working on a rendered/data driven version of the pager
[11:08:29 EDT(-0400)] <anastasiac> mostly as an exercise in learning about the renderer, but also thinking about the pager
[11:09:07 EDT(-0400)] <michelled> cool
[11:09:24 EDT(-0400)] <michelled> I just checked my mail but didn't find one. I'll look again quickly
[11:09:57 EDT(-0400)] <anastasiac> I've been pondering who has responsibility for 'rendering' the actual paged content i.e. not the pager link bars
[11:11:22 EDT(-0400)] <anastasiac> the pager itself shouldn't really need to know about what it's paging
[11:11:36 EDT(-0400)] <michelled> no, it shouldn't
[11:11:57 EDT(-0400)] <anastasiac> but should it be able to 'receive' a tree and cutpoint list, and call the renderer?
[11:12:07 EDT(-0400)] <anastasiac> or should the app using the pager be doing that itself?
[11:12:43 EDT(-0400)] <michelled> it will need to know something about what it's paging if I remember the designs correctly. I think there is a plan for tool tip info about what each page contains, something like "A-D", "E-G"
[11:13:22 EDT(-0400)] <anastasiac> yes, but that could be for student names, or product id codes, or anything
[11:13:37 EDT(-0400)] <anastasiac> and is the paged data in a table? list? paragraphs?
[11:13:47 EDT(-0400)] <michelled> I think the strategy for content rendering needs to be pluggable. I think a good default case is to call back to the server for a DOM fragment
[11:14:29 EDT(-0400)] <michelled> the paged data structure should be completely up to the app, I think.
[11:15:00 EDT(-0400)] <anastasiac> but the pager would make the actual call to fluid.render(), given the necessary data from the app?
[11:15:42 EDT(-0400)] <Bosmon> Oh, lots happening here
[11:15:53 EDT(-0400)] <michelled> I don't think so. I think that the server would want to generate the full markup in the default case
[11:16:21 EDT(-0400)] <anastasiac> hm...
[11:16:43 EDT(-0400)] <Bosmon> I never quite understood what the pager "did"...
[11:16:47 EDT(-0400)] <anastasiac> and if the app wants to use the client-side rendering, it would do that itself, independent of the use of the pager?
[11:17:05 EDT(-0400)] <anastasiac> the pager would control the request to the server for the block of data that is to be rendered
[11:17:37 EDT(-0400)] <michelled> well I think the pager would relinquish control when a request was made
[11:17:38 EDT(-0400)] <anastasiac> Bosmon, the pager provides the useable, well-designed controls for paging the data
[11:17:53 EDT(-0400)] <anastasiac> michelled, can you elaborate a bit?
[11:18:27 EDT(-0400)] <michelled> essentially provide a hook or callback. the implementation would be up to the integrator
[11:18:31 EDT(-0400)] <michelled> does that make sense?
[11:19:03 EDT(-0400)] <anastasiac> what is the pager relinquishing control of, and on what request?
[11:19:42 EDT(-0400)] * anastasiac has a tired brain, and is slow to understand things
[11:19:53 EDT(-0400)] <michelled> when a page link is clicked, the pager calls a callback
[11:20:03 EDT(-0400)] <anastasiac> right...
[11:20:17 EDT(-0400)] <michelled> it assumes that the callback will refresh the content, I think.
[11:20:47 EDT(-0400)] <anastasiac> so you're saying that the callback will be completely responsible for refreshing the content?
[11:20:50 EDT(-0400)] <anastasiac> as opposed to
[11:21:20 EDT(-0400)] <anastasiac> the callback retrieving a new component tree full of fresh data, and then the pager using that to refresh the content
[11:21:38 EDT(-0400)] <Bosmon> anastasiac: These two approaches can be layered on top of each other
[11:21:42 EDT(-0400)] <Bosmon> "In the usual way"
[11:21:52 EDT(-0400)] <Bosmon> At base, there is a "simple callback"
[11:21:53 EDT(-0400)] <anastasiac> makes sense, Bosmon
[11:21:58 EDT(-0400)] <Bosmon> For which we provide a number of pre-canned alternatives
[11:22:51 EDT(-0400)] <michelled> meaning that one of the pre-canned alternatives would use the client side renderer.
[11:23:20 EDT(-0400)] <anastasiac> right, and I suppose another can would relinquish control completely to the server
[11:25:44 EDT(-0400)] <anastasiac> ok, this has been helpful - thanks michelled and Bosmon
[11:25:59 EDT(-0400)] <michelled> np, glad it was helpful
[11:26:17 EDT(-0400)] <michelled> so, if you've got this happening with the renderer, any reason to be working in the sandbox?
[11:26:28 EDT(-0400)] <michelled> perhaps it would be good to have this functionality in trunk
[11:27:08 EDT(-0400)] <anastasiac> well, that depends what "this" refers to in your sentence "you've got this happening with the renderer"
[11:27:12 EDT(-0400)] <anastasiac>
[11:27:19 EDT(-0400)] <anastasiac> I do not have a working pager
[11:27:37 EDT(-0400)] <anastasiac> or anything close
[11:27:41 EDT(-0400)] <anastasiac> not yet
[11:28:12 EDT(-0400)] <anastasiac> that's why I have the questions - how will the pager work with the renderer?
[11:28:27 EDT(-0400)] <anastasiac> we'd need to understand that before we can create a pager that works with the renderer
[11:28:40 EDT(-0400)] <michelled> true
[11:28:43 EDT(-0400)] <anastasiac> I'm focusing mainly on understanding the renderer, so that I can document it
[11:28:55 EDT(-0400)] <anastasiac> I'm using the pager as the learning tool, since we'll want that eventually
[11:29:05 EDT(-0400)] <anastasiac> kill one and a half birds with one stone
[11:29:25 EDT(-0400)] <anastasiac> (? kill one, wound another?)
[11:29:46 EDT(-0400)] <michelled> free one and put the other in a bigger cage
[11:29:55 EDT(-0400)] <anastasiac>
[11:43:46 EDT(-0400)] <Bosmon> Make sure one of the birds is not a PENGUIN
[11:44:09 EDT(-0400)] <Bosmon> Well, throwing a rock at a PENGUIN would probably make it angry and attack you
[11:55:47 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-70.LIPS.Berkeley.EDU) has joined #fluid-work
[12:17:49 EDT(-0400)] <anastasiac> michelled, we don't publish fluid to a public maven repo yet, do we?
[12:20:02 EDT(-0400)] <anastasiac> We may want to raise the priority of that task
[12:20:41 EDT(-0400)] <anastasiac> FLUID-141
[12:27:34 EDT(-0400)] <michelled> anastasiac: no, we don't. I know that simonwang is working on a few infrastructure tasks. I wonder if he could take this on too.
[12:28:52 EDT(-0400)] <anastasiac> part of the question is who would host the repo
[12:29:32 EDT(-0400)] <anastasiac> it probably wouldn't be an issue to put it on the same server as the build site, but we should at least give it a moment's thought first
[12:29:39 EDT(-0400)] <anastasiac> maybe a colin question
[12:35:24 EDT(-0400)] * jrnorman (n=john@ginger.caret.cam.ac.uk) has joined #fluid-work
[13:04:07 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined #fluid-work
[13:04:50 EDT(-0400)] <ecochran> stand up
[13:04:58 EDT(-0400)] <ecochran> !
[13:36:22 EDT(-0400)] * jrnorman (n=john@ginger.caret.cam.ac.uk) has joined #fluid-work
[14:31:24 EDT(-0400)] <anastasiac> Bosmon, if I put rsf:id on the elements in my template, and I use those ids in my component tree, then I don't need a cutpoints object in the opts to fluid.selfRender() - is this right?
[14:32:03 EDT(-0400)] <michelled> anastasiac: I confirmed with Bosmon that there is a bug currently
[14:32:10 EDT(-0400)] <anastasiac> oh?
[14:32:23 EDT(-0400)] <michelled> if there are no cutpoints the renderer blows up
[14:32:31 EDT(-0400)] <michelled> I think he was going to open a JIRA
[14:32:43 EDT(-0400)] <anastasiac> ok, good! that explains things
[14:32:56 EDT(-0400)] <michelled> yes, I stumped me for a while as well
[14:33:02 EDT(-0400)] <anastasiac> if I do have rsf:ids, what should my cutpoints object look like?
[14:33:21 EDT(-0400)] <anastasiac> I can't reference rsf:ids in a css selector, can I?
[14:33:34 EDT(-0400)] <anastasiac> or maybe with the [rsf:id=...] format?
[14:33:44 EDT(-0400)] <michelled> maybe, I really don't know
[14:33:45 EDT(-0400)] * anastasiac is still very new to cutpoints
[14:33:53 EDT(-0400)] <anastasiac> ok, I'll experiment
[14:34:02 EDT(-0400)] <michelled> also, I don't think if the rsf:ids will still be around by the point that the cutpoints are used
[14:34:05 EDT(-0400)] <anastasiac> thanks, michelled, you saved me lots of head pashing
[14:34:15 EDT(-0400)] <anastasiac> bashing
[14:34:22 EDT(-0400)] <michelled> I'm fairly certain that the renderer removes the rsf:ids
[14:34:24 EDT(-0400)] <michelled> np
[14:34:31 EDT(-0400)] <anastasiac> but not before it uses them!
[14:35:04 EDT(-0400)] <anastasiac> my understanding was that if you use selectors in the cutpoints object (like you did in your preferable example)
[14:35:08 EDT(-0400)] <michelled> no, certainly not. But I don't know when in the cycle it uses the rsf:ids, when it removes them, and when it uses the cutpoints
[14:35:14 EDT(-0400)] <anastasiac> then the renderer converts it all to rsf ids
[14:35:52 EDT(-0400)] <michelled> what is 'it'? the cutpoints?
[14:36:10 EDT(-0400)] <anastasiac> cutpoints, and the tree, I think
[14:36:25 EDT(-0400)] <anastasiac> I think the renderer examines the two in concert to infer the rsf:ids
[14:36:48 EDT(-0400)] <anastasiac> by the way, no jira related to this yet
[14:38:40 EDT(-0400)] <michelled> this is what Bosmon said to me earlier: AntranigBasman: I think there is currently a bug where if you don't have any rsf:ids or cutpoints, it will explode
[14:46:54 EDT(-0400)] <Bosmon> Hello, I am here now
[14:47:15 EDT(-0400)] <Bosmon> anastasiac: if you have rsf:ids, you don't write cutpoints at all
[14:47:56 EDT(-0400)] <Bosmon> And - if you write cutpoints, only those are inspected to turn into rsf:ids
[14:48:04 EDT(-0400)] <Bosmon> One is a direct replacement for the other
[14:48:07 EDT(-0400)] <anastasiac> ok, so if I do have them, no cutpoints necessary, as long as the rsf:ids in the template match the ids in the tree
[14:48:14 EDT(-0400)] <Bosmon> Yes, that is right
[14:48:34 EDT(-0400)] <Bosmon> There's actually nothing to stop you having a "mixed" strategy, with some cutpoints, and some rsf:ids
[14:48:37 EDT(-0400)] <anastasiac> ok, I'll keep trying
[14:48:38 EDT(-0400)] <Bosmon> But I guess it would be a bit silly
[14:48:54 EDT(-0400)] <Bosmon> If it finds an rsf:id in the markup, it will ignore trying to make it match a cutpoint
[14:49:46 EDT(-0400)] <anastasiac> "baselump is undefined" - what does that imply I'm doing wrong?
[14:51:33 EDT(-0400)] <anastasiac> my template is:
[14:51:50 EDT(-0400)] <anastasiac> <tr rsf:id="data-row:">
[14:51:50 EDT(-0400)] <anastasiac> <td rsf:id="name">name here</td>
[14:51:51 EDT(-0400)] <anastasiac> <td rsf:id="val">value here</td>
[14:51:51 EDT(-0400)] <anastasiac> </tr>
[14:52:11 EDT(-0400)] <anastasiac> my tree is:
[14:52:33 EDT(-0400)] <anastasiac> var contentTree = {
[14:52:33 EDT(-0400)] <anastasiac> "data-row:" : [
[14:52:33 EDT(-0400)]

[14:52:33 EDT(-0400)]

[14:53:20 EDT(-0400)] <anastasiac> Bosmon ^
[14:54:05 EDT(-0400)] <Bosmon> Yes, the "baselump is undefined" is exactly what steve got....
[14:54:17 EDT(-0400)] <Bosmon> Can I see what your call to the renderer looks like?
[14:54:31 EDT(-0400)] <anastasiac> fluid.selfRender($(".paged-content"), contentTree);
[14:55:04 EDT(-0400)] <Bosmon> Hmm
[14:55:10 EDT(-0400)] <anastasiac> Hmm
[14:55:14 EDT(-0400)] <Bosmon> And what does the rest of your markup look like?
[14:55:28 EDT(-0400)] <michelled> you could use http://fluid.pastebin.com/
[14:55:42 EDT(-0400)] <anastasiac> That's about it. the rows are in a table body, there's a table head
[14:55:44 EDT(-0400)] <anastasiac> but that's all
[14:56:21 EDT(-0400)] * anastasiac cuts and pastes
[14:57:11 EDT(-0400)] <Bosmon> I guess Colin is in an Uploader Bunker?
[14:57:32 EDT(-0400)] <anastasiac> http://fluid.pastebin.com/m6efef9e
[14:57:45 EDT(-0400)] <anastasiac> dunno where colin is
[14:57:50 EDT(-0400)] <anastasiac> I'm in wisconsin
[14:57:54 EDT(-0400)] <michelled> he's working on his boat
[14:57:59 EDT(-0400)] <Bosmon> aha
[14:58:00 EDT(-0400)] <anastasiac> oh, nice!
[14:58:14 EDT(-0400)] <michelled> he'll be back online later - was in an uploader bunker all morning
[14:58:20 EDT(-0400)] <Bosmon> Hmm, OK
[14:58:35 EDT(-0400)] <Bosmon> I can't see anything wrong with your example, "by eye"
[14:58:49 EDT(-0400)] <Bosmon> So I think the best thing to do would be to import it into a test fixture, and try to make it work
[14:59:14 EDT(-0400)] <Bosmon> Do you think you could add it into the RendererTest.html thing?
[14:59:21 EDT(-0400)] <Bosmon> And I will try and see what is up with it
[14:59:21 EDT(-0400)] <michelled> anastasiac, since this is in the sandbox it would be fine for you to commit it
[14:59:37 EDT(-0400)] <anastasiac> I will just commit what I have - is that ok, Bosmon?
[14:59:41 EDT(-0400)] <Bosmon> Renderer-test.html
[14:59:42 EDT(-0400)] <Bosmon> OK
[14:59:53 EDT(-0400)] <Bosmon> But I think this would make a very good test case
[14:59:56 EDT(-0400)] <Bosmon> Especially since it is failing
[15:00:47 EDT(-0400)] <anastasiac> done: http://source.fluidproject.org/svn/sandbox/pager-rendered/trunk/
[15:07:42 EDT(-0400)] <Bosmon> We still have uses of prototype in the pager!!!!!!
[15:08:00 EDT(-0400)] <Bosmon> Outrageous!!!
[15:08:20 EDT(-0400)] <Bosmon> It doesn't even slightly use the DOM binder....
[15:08:53 EDT(-0400)] <anastasiac> Bosmon - I tried taking out the other call to selfRender() in the code I committed, and it works
[15:08:56 EDT(-0400)] <Bosmon> How did we let this get into the release!
[15:09:26 EDT(-0400)] <anastasiac> Don't worry about the Pager right now - it is very preliminary, and will be re-written
[15:09:37 EDT(-0400)] <Bosmon> ok
[15:09:49 EDT(-0400)] <anastasiac> can I not render two different things, with two different calls to selfRender() in the same page??
[15:10:29 EDT(-0400)] <Bosmon> OK
[15:10:31 EDT(-0400)] <Bosmon> Now I see your problem
[15:10:42 EDT(-0400)] <Bosmon> After the first renderer, you will appreciate that the template has been "destroyed"
[15:10:47 EDT(-0400)] <Bosmon> render
[15:10:53 EDT(-0400)] <Bosmon> I mean, it is no longer there in the document, right?
[15:11:26 EDT(-0400)] <anastasiac> ah!! ok - because it's inside the element that was the root of the first!
[15:11:29 EDT(-0400)] <anastasiac> ok, got it
[15:11:42 EDT(-0400)] <Bosmon> So, for successive calls, you need to use a slightly more "advanced" driver
[15:11:49 EDT(-0400)] <Bosmon> You see that there is a return value from selfRender
[15:12:04 EDT(-0400)] <Bosmon> Which is the "compiled" template structure which it produced just before it snagged it out of the DOM
[15:12:26 EDT(-0400)] <Bosmon> But you should probably use the "more advanced" driver in any case, otherwise it will just be asymmetric
[15:13:06 EDT(-0400)] <Bosmon> Well, I guess we need to flesh out this API a bit
[15:13:28 EDT(-0400)] <Bosmon> The "base driver" is at fluid.renderTemplates = function(templates, tree, opts, fossilsIn) {
[15:13:36 EDT(-0400)] <anastasiac> ok, I'll get to this advanced driver at some point, now that I know it exists
[15:13:45 EDT(-0400)] <Bosmon> So the first argument to renderTemplates can be the templates structure that you got from a previous call to selfRender
[15:14:29 EDT(-0400)] <Bosmon> And the other arguments are just the ones you are familiar with, apart from "fossilsIn" which you can leave empty if you are not doing any data binding
[15:15:38 EDT(-0400)] <michelled> anastasiac, are you trying to do two different calls to selfRender in order to approximate the pluggable nature of rendering the content that is being paged?
[15:16:02 EDT(-0400)] <anastasiac> michelled, yes, that's what I'm experimenting with
[15:16:13 EDT(-0400)] <anastasiac> and it works! Just committed the working version
[15:16:52 EDT(-0400)] <Bosmon> anastasiac: Nice dataset btw
[15:17:01 EDT(-0400)] <anastasiac> thank you
[15:17:13 EDT(-0400)] <anastasiac> what exactly is it, anyway?
[15:17:34 EDT(-0400)] <Bosmon> I just looked at it for the first time
[15:17:39 EDT(-0400)] <Bosmon> Apparently it measures "EQ"
[15:17:44 EDT(-0400)] <Bosmon> "Encephalization Quotient"
[15:17:56 EDT(-0400)] <Bosmon> I found it very fine that CATTT was the universal yardstick for intelligence
[15:18:15 EDT(-0400)] <anastasiac> I suspected it was something along those lines
[15:18:55 EDT(-0400)] <anastasiac> "brain to body mass ratio"
[15:18:59 EDT(-0400)] <anastasiac> http://en.wikipedia.org/wiki/Brain_to_body_mass_ratio
[15:19:20 EDT(-0400)] <Bosmon> OK
[15:20:16 EDT(-0400)] <Bosmon> OK, so I have added this table rendering as a test suite element...
[15:20:19 EDT(-0400)] <Bosmon> We now have TWO TESTS
[15:20:27 EDT(-0400)] <anastasiac> yay!
[15:21:23 EDT(-0400)] * Topic is 'Encephalization Quotient' set by anastasiac on 2008-10-09 15:21:23 EDT(-0400)
[15:22:11 EDT(-0400)] * Topic is ' Encephalization Quotient: CATTT = 1.00' set by Bosmon on 2008-10-09 15:22:11 EDT(-0400)
[15:30:17 EDT(-0400)] <Bosmon> michelled, anastasiac: So, I am racking my brains how to "find room" in the component tree for other things, now we have this "brilliantly condensed" "dehydrated form"
[15:30:37 EDT(-0400)] <Bosmon> My best guess so far is to choose some kind of String that could never possibly be a valid id
[15:30:48 EDT(-0400)] <Bosmon> For example, those beginning "::"
[15:31:03 EDT(-0400)] <michelled> what are you trying to find room for?
[15:31:05 EDT(-0400)] <Bosmon> So, say that you wanted the table cell CATTT to be particularly highlighted by being given a class when it was rendered
[15:31:12 EDT(-0400)] <Bosmon> My proposal looks like this:
[15:31:30 EDT(-0400)]

[15:31:59 EDT(-0400)] <Bosmon> We would have a number of recognised "::" directives that would be "exploded" into more verbose forms
[15:32:01 EDT(-0400)] <anastasiac> interesting
[15:32:37 EDT(-0400)] <Bosmon> But given that we have committed to the "dehydrated form" being as far as possible "pure JSON", our options are really quite constrained in "finding room" for other things in the same structure
[15:32:52 EDT(-0400)] <Bosmon> Ordinarily this bit of the component tree would be "quite big":
[15:33:53 EDT(-0400)]

[15:34:12 EDT(-0400)] <Bosmon> And so there would be room for a "proper name" which in RSF Server would be called "decorators"
[15:34:15 EDT(-0400)] <anastasiac> how would a class fit into this hydrated form?
[15:34:25 EDT(-0400)] <Bosmon> So if you wanted to decorate the row, you would write something like:
[15:34:59 EDT(-0400)]

[15:35:07 EDT(-0400)] <Bosmon> So this is a proper "up front" unconfusable structure
[15:35:25 EDT(-0400)] <Bosmon> In that it is impossible to mix up id names with component tree directives
[15:36:02 EDT(-0400)] <Bosmon> You have to drop into this format, for example, if you are trying to get input from the UI
[15:36:11 EDT(-0400)] <Bosmon> Since otherwise there is no room for all the other field names, etc.
[15:36:22 EDT(-0400)] <Bosmon> Although in theory, we could do something crazy like the same :: trick for those
[15:36:28 EDT(-0400)] <Bosmon> But I think that would be a bit distasteful
[15:36:44 EDT(-0400)] <Bosmon> What do you think?
[15:37:03 EDT(-0400)] <Bosmon> I mean, there are lots of other possible field names, especially when you are dealing with selection controls, etc.
[15:38:04 EDT(-0400)] <anastasiac> interesting...
[15:38:15 EDT(-0400)] <anastasiac> this is intriguing
[15:38:18 EDT(-0400)] <Bosmon> Ha
[15:38:22 EDT(-0400)] <Bosmon> You think that is interesting
[15:38:23 EDT(-0400)] <michelled> I think we are going to create a difficult to use API if we use symbols such as "::" instead of proper names. I mean, I think there are many things that we want to do with decoration
[15:38:31 EDT(-0400)] <Bosmon> How about this:
[15:38:52 EDT(-0400)] <anastasiac> michelled, you're right - I'm worried about it becoming complicated.
[15:39:05 EDT(-0400)] <anastasiac> but the hydrated form of the tree (the alternative) is complicated
[15:39:20 EDT(-0400)] <anastasiac> so I'm not ready to rule out Bosmon's proposal yet
[15:39:33 EDT(-0400)] <michelled> perhaps the decoration comes in elsewhere
[15:39:43 EDT(-0400)] <michelled> like in the cutpoints or other options
[15:39:51 EDT(-0400)] <Bosmon> {"species": "CATT", "score": 1.00 , "::jQuery":, {onclick: function(evt) { alert("I am a CATT!");}},
[15:40:03 EDT(-0400)] <Bosmon> No, it has to come here
[15:40:06 EDT(-0400)] <Bosmon> This is the component tree
[15:40:09 EDT(-0400)] <michelled> I won't pretend to understand cutpoints yet - I'm just suggesting that we may be doing too much in the tree
[15:40:17 EDT(-0400)] <anastasiac> michelled, yes - I was about to look at the baseball table example that 'binds' a data table to the component tree
[15:40:31 EDT(-0400)] <anastasiac> maybe we could similarly 'bind' a decorators table to the component tree?
[15:40:39 EDT(-0400)] <Bosmon> It would be terrible
[15:40:46 EDT(-0400)] <Bosmon> You would never find the components again....
[15:40:46 EDT(-0400)] <anastasiac> (keeping in mind I don't understand this binding yet)
[15:41:05 EDT(-0400)] <Bosmon> Anyway, the components "bind" to data
[15:41:08 EDT(-0400)] <Bosmon> Nothing binds to components
[15:41:20 EDT(-0400)] <Bosmon> The idiom is that after rendering, the component tree can be completely destroyed
[15:41:31 EDT(-0400)] <Bosmon> Leaving behind only pure M and V
[15:41:32 EDT(-0400)] <anastasiac> Bosmon, so it really needs to be a sort of once-through pass, you can't go back over the tree again, right?
[15:41:37 EDT(-0400)] <Bosmon> That is right
[15:41:45 EDT(-0400)] <anastasiac> hmm
[15:41:51 EDT(-0400)] <Bosmon> The component tree is purely a "transfer format"
[15:42:15 EDT(-0400)] <michelled> so what is the component tree supposed to communicate?
[15:42:25 EDT(-0400)] <Bosmon> Anyway, this "jQuery" syntax above is the Holy Grail for a lot of problems that people are reporting with client-side development
[15:42:40 EDT(-0400)] <Bosmon> They keep asking.... "how can I find the stuff I just made, in order to bind things to it - without writing everything twice?"
[15:42:46 EDT(-0400)] <anastasiac> which "jQuery" syntax are you referring to?
[15:42:56 EDT(-0400)] <Bosmon> The one I just wrote up there...
[15:43:03 EDT(-0400)] <Bosmon> {"species": "CATT", "score": 1.00 , "::jQuery":, {onclick: function(evt) { alert("I am a CATT!");}},
[15:43:08 EDT(-0400)] <anastasiac> ok
[15:43:32 EDT(-0400)] <Bosmon> It is Mega-Cool
[15:43:36 EDT(-0400)] <jessm> Bosmon: whatr M and V?
[15:43:41 EDT(-0400)] <Bosmon> Model and View
[15:44:33 EDT(-0400)] <michelled> so in your jQuery syntax there, you are binding an event handler to the row, correct?
[15:44:40 EDT(-0400)] <Bosmon> That's right, yes
[15:44:52 EDT(-0400)] <Bosmon> So we need to find some kind of "reliable" way that people can write something in the component tree, without any chance of confusion with "legitimate" ids
[15:44:53 EDT(-0400)] <jessm> Bosmon: i too wonder ^ so what is the component tree supposed to communicate?
[15:45:16 EDT(-0400)] <Bosmon> The component tree communicates the "function" of an application, separate from all considerations of markup
[15:45:32 EDT(-0400)] <Bosmon> It is what is traditionally called the "controller" layer in the MVC pattern
[15:45:48 EDT(-0400)] <Bosmon> Only it is gigantically more lightweight, given that it consists purely of data
[15:45:52 EDT(-0400)] <Bosmon> And also it does not stick around
[15:46:04 EDT(-0400)] <jessm> a vanishing tree – I like it
[15:46:08 EDT(-0400)] <anastasiac> a controller that consists of data... interesting
[15:46:14 EDT(-0400)] <Bosmon> Yes
[15:46:18 EDT(-0400)] <anastasiac> and non-intuitive
[15:46:24 EDT(-0400)] <jessm> lol
[15:46:33 EDT(-0400)] <Bosmon> glarg
[15:46:40 EDT(-0400)] <anastasiac> narf!
[15:46:42 EDT(-0400)] <Bosmon> everything should consist of data in the end
[15:46:46 EDT(-0400)] <Bosmon> This is our Ultimate Goal
[15:46:47 EDT(-0400)] <Bosmon>
[15:46:58 EDT(-0400)] <Bosmon> We have spent months making sure all our component configuration consists of pure data...
[15:47:07 EDT(-0400)] <Bosmon> Our event handler configuration consists of pure data...
[15:47:17 EDT(-0400)] <anastasiac> oh, I don't have a problem with the component tree being purely data!
[15:47:19 EDT(-0400)] <anastasiac> not at all!
[15:47:21 EDT(-0400)] <Bosmon> ok
[15:47:28 EDT(-0400)] <jessm> Bosmon: you should "glug" more, it'll make you "glarg" less
[15:47:35 EDT(-0400)] <anastasiac> lol
[15:47:56 EDT(-0400)] <Bosmon> So, the "::jQuery" directive, for example, already lets in a stupendous amount of power
[15:48:10 EDT(-0400)] <Bosmon> It lets you say something about what an app is going to do, and yet leave the markup completely up to the user
[15:48:10 EDT(-0400)] <anastasiac> yes, that's not purely data, at all
[15:48:23 EDT(-0400)] <Bosmon> Well, if it didn't have a function pointer, it would be data
[15:48:32 EDT(-0400)] <Bosmon> It is "morally data"
[15:48:41 EDT(-0400)] <anastasiac> yes, but that's my point: by adding code, that's behaviour [15:48:48 EDT(-0400)] <Bosmon> Much the same way we sometimes let people write function pointers for selectors with our DOM binder [15:48:58 EDT(-0400)] <anastasiac> yes [15:49:07 EDT(-0400)] <Bosmon> Ideally we will find more and more declarative ways of writing the things that people would want to do [15:49:19 EDT(-0400)] <Bosmon> For example, the data binder cuts out an awful lot of function pointeryism [15:49:21 EDT(-0400)] <anastasiac> we're certainly going that way! [15:49:35 EDT(-0400)] <Bosmon> But for some things, we still need to let people write genuine function pointers when they need to [15:49:41 EDT(-0400)] <Bosmon> Since some stuff genuinely does do stuff [15:49:51 EDT(-0400)] <Bosmon> That is, stuff, you could not anticipate [15:50:01 EDT(-0400)] * jessm hides her moral data in vanishing trees [15:50:11 EDT(-0400)] <Bosmon> But yes, you can see what the alternative to "::jQuery" is [15:50:21 EDT(-0400)] <Bosmon> People, after they rendered the markup, would then need to hack at it again [15:50:38 EDT(-0400)] <anastasiac> this is interesting [15:50:40 EDT(-0400)] <Bosmon> And find the exact selfsame nodes which they had just issued directives for rendering, and then attach stuff to them [15:50:48 EDT(-0400)] <Bosmon> This is what everyone complains of in the client-side world [15:50:56 EDT(-0400)] <Bosmon> "I want to write my selectors just ONCE" [15:51:03 EDT(-0400)] <anastasiac> this is what fluid components will do [15:51:14 EDT(-0400)] <anastasiac> like the baseball table - you render the table, then make it inline-editable [15:51:20 EDT(-0400)] <Bosmon> Yes [15:51:44 EDT(-0400)] <Bosmon> Well, luckily since our fluid component structure has been made fully declarative [15:51:48 EDT(-0400)] <Bosmon> You can see how easy this will be [15:52:25 EDT(-0400)] <anastasiac> well, wait - the way the baseball table is rendered then made editable - that's not a bad process, is it?? [15:52:51 EDT(-0400)]