fluid-work IRC Logs-2010-06-16

[04:52:45 CDT(-0500)] * thomas____ (~thomasain@213.246.129.247) has joined #fluid-work
[06:59:35 CDT(-0500)] * michelled (~michelled@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[07:30:55 CDT(-0500)] * Justin_o (~Justin@142.150.154.171) has joined #fluid-work
[08:07:53 CDT(-0500)] * kasper (~kasper@189.130.152.145) has joined #fluid-work
[08:08:16 CDT(-0500)] * michelled (~michelled@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[08:10:55 CDT(-0500)] * jessm (~Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined #fluid-work
[08:17:58 CDT(-0500)] * yura_ (~yura@142.150.154.114) has joined #fluid-work
[08:33:12 CDT(-0500)] * colinclark (~colin@bas2-toronto09-1176406399.dsl.bell.ca) has joined #fluid-work
[08:39:31 CDT(-0500)] * clown (~clown@142.150.154.101) has joined #fluid-work
[08:52:47 CDT(-0500)] * anastasiac (~team@142.150.154.193) has joined #fluid-work
[08:54:33 CDT(-0500)] * jhung (~Jon@H25.C204.cci.switchworks.net) has joined #fluid-work
[09:18:42 CDT(-0500)] * Justin_o (~Justin@142.150.154.171) has joined #fluid-work
[09:32:23 CDT(-0500)] <jhung> Justin_o, jameswy - have time to go through rest of Jiras before standup?
[09:32:32 CDT(-0500)] <jameswy> jhung: sure
[09:32:36 CDT(-0500)] <Justin_o> jhung: sure
[09:52:30 CDT(-0500)] <Justin_o> jamon: do you happen to know when the tmp directory in ubuntu 10 gets cleared?
[09:52:46 CDT(-0500)] <jamon> hi Justin_o, not happening on reboot?
[09:53:51 CDT(-0500)] <Justin_o> just wondering... i assumed it would be on reboot... we were just wondering for decapod stuff
[09:54:02 CDT(-0500)] <Justin_o> jamon: ^
[09:56:07 CDT(-0500)] <jamon> Justin_o: best to clean up temp files on exiting
[09:56:29 CDT(-0500)] <Justin_o> jamon: thanks
[10:16:21 CDT(-0500)] * athena (~athena@c-76-121-97-221.hsd1.wa.comcast.net) has joined #fluid-work
[11:07:32 CDT(-0500)] * EricDalquist (~dalquist@2607:f388:e:0:221:9bff:fe37:e768) has joined #fluid-work
[11:18:35 CDT(-0500)] * nickb1 (~nblair@2607:f388:e:0:21a:a0ff:fe9b:9fdf) has joined #fluid-work
[11:20:31 CDT(-0500)] <nickb1> hi - I'm working on using the Fluid renderer currently, and I have a few questions getting started
[11:22:53 CDT(-0500)] <nickb1> here's a screenshot of my current project: https://mywebspace.wisc.edu/npblair/web/temp/bandwidth-screenshot.png
[11:23:23 CDT(-0500)] <nickb1> it's a "bandwidth usage" monitor for our xythos instance; the goal is to have the current activity table update every N seconds
[11:24:06 CDT(-0500)] <nickb1> i've got it rendering the table on the initial page load using the fluid pager; however I can't seem to figure out how to periodically update the table
[11:25:30 CDT(-0500)] <colinclark> Hi nickb1
[11:25:36 CDT(-0500)] <colinclark> Sorry, I'm just catching up with your question
[11:25:55 CDT(-0500)] <nickb1> thanks for taking a look
[11:27:24 CDT(-0500)] <nickb1> i can share the javascript code i've got now - do you have a pastebin or something similar?
[11:28:00 CDT(-0500)] <Justin_o> nickb1: you can use fluid.pastebin.com
[11:28:24 CDT(-0500)] <colinclark> nickb1: Seeing some code would be great
[11:28:54 CDT(-0500)] <nickb1> ok
[11:29:50 CDT(-0500)] <nickb1> http://fluid.pastebin.com/TNPSv0Jk
[11:30:01 CDT(-0500)] <nickb1> includes the javascript within the page and the table
[11:30:53 CDT(-0500)] <nickb1> I can see the repeated calls to the data controller via firebug, and the data is updated
[11:31:21 CDT(-0500)] <nickb1> but perhaps my success handler is doing something wrong by calling fluid.pager every time?
[11:32:00 CDT(-0500)] <nickb1> is there a way to create the pager once and register a listener function to update the data model on json success?
[11:32:39 CDT(-0500)] <colinclark> nickb1: Yeah, that'll be the problem. You don't need to create a whole new Pager to update the model.
[11:33:27 CDT(-0500)] <colinclark> I'm not a super big Pager user, so let me take a few minutes to read through your code and see what we can do to make it work
[11:33:33 CDT(-0500)] <nickb1> ok
[11:33:52 CDT(-0500)] <nickb1> perhaps the pager is overkill as well - i don't think i need to page through the data
[11:34:12 CDT(-0500)] <nickb1> I started looking at just the demo for the renderer: http://fluidproject.org/releases/1.2/demos/renderer/demo.html
[11:36:28 CDT(-0500)] <colinclark> If you don't need to page through the data at all, you're right that the Pager is probably overkill
[11:36:35 CDT(-0500)] <colinclark> Nice if you need lots of paging features
[11:36:55 CDT(-0500)] <colinclark> Otherwise, overkill
[11:40:23 CDT(-0500)] <nickb1> ok, so looking at the renderer's selfRender method
[11:40:50 CDT(-0500)] <nickb1> the second argument is a Renderer Component Tree
[11:41:12 CDT(-0500)] <nickb1> can I pass simply the json results object in? or do I need to convert that similar to the aforementioned demo
[11:41:52 CDT(-0500)] <colinclark> So you need three main things to use the Renderer:
[11:42:02 CDT(-0500)] <colinclark> 1. Some markup that will serve as a template
[11:42:06 CDT(-0500)] <colinclark> 2. Some data you want to render
[11:42:22 CDT(-0500)] <colinclark> 3. The component tree, which is a blob of JSON that defines the instructions on how to render the data into the template.
[11:42:53 CDT(-0500)] <colinclark> In the simplest form, you'll want to put some kind of class names or selectors on the key pieces of markup you'd like to render
[11:43:04 CDT(-0500)] <colinclark> The table row that you want to repeat, as well as the table cells in which you'll put data
[11:44:11 CDT(-0500)] <colinclark> Then you'll want to define some "cutpoints," which basically give unique names to your selectors that you can refer to in the component tree.
[11:44:21 CDT(-0500)] <colinclark> I think that's documented here: http://wiki.fluidproject.org/display/fluid/Renderer+Templates
[11:45:07 CDT(-0500)] <colinclark> In the cut points, you'll have to mark the row that repeats with a colon, for reasons I won't bother to get into
[11:45:13 CDT(-0500)] <colinclark> But in short, colons denote repetition
[11:45:32 CDT(-0500)] <colinclark> And then for a simple table, you'll create a little component tree that looks something like this...
[11:45:39 CDT(-0500)] <colinclark> (let me pastebin it, one sec)
[11:48:59 CDT(-0500)] <colinclark> Here's an example of what a component tree would look like for a table that displays authors--two columns, one for their name, and one for their bio.
[11:49:00 CDT(-0500)] <colinclark> http://fluid.pastebin.com/i4DEKHes
[11:49:24 CDT(-0500)] <colinclark> Now, you're probably not going to want to write the tree out literally, you'll want to have it be data-driven
[11:50:11 CDT(-0500)] <colinclark> So to generate the tree, you'll want to loop through each row in your data and generate each of those rows
[11:50:27 CDT(-0500)] <colinclark> I dunno if this makes much sense, but I could whip you up an example if you want, nickb1
[11:51:32 CDT(-0500)] <nickb1> a short example would help, i'm struggling a little bit yet
[11:51:53 CDT(-0500)] <nickb1> trying to visualize the workflow of the application
[11:52:13 CDT(-0500)] <colinclark> k
[11:52:19 CDT(-0500)] <nickb1> the cutpoints are re-used right? it's basically just a binding between the selectors and the fields in the data model?
[11:52:35 CDT(-0500)] <colinclark> yep, exactly
[11:54:02 CDT(-0500)] <nickb1> so setup cutpoints first. next i'll need a function similar to 'buildLocationsSubtree' in the renderer demo
[11:54:17 CDT(-0500)] <nickb1> right?
[11:54:32 CDT(-0500)] <nickb1> eh, buildCanapeListSubtree I mean
[11:56:07 CDT(-0500)] <colinclark> nickb1: Similar, though you'll notice that the canape component tree is a fair bit more complex because of the checkboxes, etc in there
[11:56:37 CDT(-0500)] * clown (~clown@142.150.154.101) has joined #fluid-work
[11:56:37 CDT(-0500)] <nickb1> and it seems to alter the ths in the table head, which I won't need to do
[12:00:47 CDT(-0500)] <colinclark> right
[12:01:12 CDT(-0500)] <nickb1> I'm stumbling on how the demo actually works, since I don't see "canape-row" as an id in the template table in that demo
[12:01:43 CDT(-0500)]

[12:02:35 CDT(-0500)] <colinclark>
[12:02:40 CDT(-0500)] <colinclark> almost done with an example, which should help, too
[12:03:40 CDT(-0500)] <nickb1> can i skip setting up cutpoints if the markup defines RSF ids?
[12:05:15 CDT(-0500)] <colinclark> You can, if you like putting RSF ids in your markup.
[12:05:25 CDT(-0500)] <colinclark> I always prefer the unobtrusiveness of cutpoints, but they both work.
[12:05:46 CDT(-0500)] <colinclark> Okay, I have an example that I'll pastebin for you
[12:05:58 CDT(-0500)] <nickb1> heh - I take it adding RSF ids is uncommon and setting up the cutpoints is preferred?
[12:06:01 CDT(-0500)] <nickb1> cool
[12:06:41 CDT(-0500)] <colinclark> nickb1: Generally most people use cutpoints, yes. Both are supported, though.
[12:06:48 CDT(-0500)] <colinclark> So here's the markup: http://fluid.pastebin.com/i8ZKa6Fn
[12:07:17 CDT(-0500)] <colinclark> And here's the code: http://fluid.pastebin.com/N7C5bYML
[12:07:40 CDT(-0500)] <colinclark> So, in the example, you'll see those key things...
[12:07:56 CDT(-0500)] <colinclark> We've got a plain old data model. Just JSON, mostly likely the stuff you get sent from the server.
[12:08:15 CDT(-0500)] <nickb1> ok
[12:08:17 CDT(-0500)] <colinclark> We've got (optionally) a cutpoints definition, which just let us unobtrusively give names to things in the template.
[12:08:35 CDT(-0500)] <colinclark> And then I've built this little generateCatComponentTree() function.
[12:08:48 CDT(-0500)] <colinclark> You can see it takes the model as an argument, and returns a fully-baked tree as the result.
[12:09:00 CDT(-0500)] <colinclark> I'm using the fluid.transform() utility function to actually generate the tree
[12:09:10 CDT(-0500)] <colinclark> All transform does is loop through an array, creating a new array as the result.
[12:09:26 CDT(-0500)] <nickb1> this is a great example
[12:09:31 CDT(-0500)] <colinclark> It's just the equivalent of creating your own array, looping through the model, and pushing component tree chunks into it.
[12:09:46 CDT(-0500)] <colinclark> fluid.transform() is a nice little example of how great functional programming in JavaScript can be
[12:09:50 CDT(-0500)] <colinclark> Then finally, I just render the thing.
[12:10:04 CDT(-0500)] <colinclark> Now, in your case, you'll be getting data dynamically from the server via Ajax, on a timer
[12:10:15 CDT(-0500)] <nickb1> to redraw the table - can I simply call renderTable again? or do I need to do something else to destroy the rows in the table added by a previous invocation?
[12:10:31 CDT(-0500)] <colinclark> You'll want to use fluid.reRender() instead of selfRender()
[12:10:36 CDT(-0500)] <nickb1> ah
[12:10:37 CDT(-0500)] <colinclark> This will be faster
[12:10:43 CDT(-0500)] <nickb1> nice
[12:10:55 CDT(-0500)] <colinclark> So selfRender() returns a data structure with the already-parsed templates
[12:11:13 CDT(-0500)] <colinclark> So the first time, you can do var templates = fluid.selfRender()
[12:11:26 CDT(-0500)] <colinclark> And the second time, call fluid.reRender, passing along those templates
[12:11:27 CDT(-0500)] <colinclark> that's it
[12:11:47 CDT(-0500)] <nickb1> what is the 1st argument to rerender (e.g. templates)?
[12:12:01 CDT(-0500)] <nickb1> it appears the last 3 are the same as the 3 arguments for selfRender
[12:12:19 CDT(-0500)] <nickb1> is templates the return value from selfRender?
[12:15:30 CDT(-0500)] <nickb1> it appears so; thank you for the tips, I'll build from this and let you know how it goes
[12:15:40 CDT(-0500)] <colinclark> Lemme grab the docs
[12:15:40 CDT(-0500)] <colinclark> wiki is slow. Do you remember off the top of your head, Justin_o? It must be the templates
[12:15:42 CDT(-0500)] <colinclark> Well, in absence of the docs, there's always the code
[12:15:42 CDT(-0500)] <colinclark> fluid.reRender = function(templates, node, tree, options) {
[12:15:43 CDT(-0500)] <colinclark> So templates, the container of the thing you want rendered (probably the table), the component tree, and options
[12:15:44 CDT(-0500)] <colinclark> I don't think, in many cases, there's any harm in calling selfRender() again, but reRender() will be faster
[12:15:51 CDT(-0500)] <colinclark> yep
[12:15:56 CDT(-0500)] <colinclark> Hope it helps, nickb1
[12:16:15 CDT(-0500)] <Bosmon2> Well, there is an issue that with some content, repeated calls to selfRender() may not be "idempotent"
[12:16:26 CDT(-0500)] <Bosmon2> Some templates render to things that can be used as a template, some do not
[12:16:31 CDT(-0500)] <colinclark> right
[12:16:39 CDT(-0500)] <Bosmon2> It is safer to stick with a sequence of selfRender() + further reRender()
[13:07:12 CDT(-0500)] * EricDalquist (~apollo@static-210-59.vpn.wisc.edu) has joined #fluid-work
[13:07:19 CDT(-0500)] * EricDalquist (~apollo@static-210-59.vpn.wisc.edu) has left #fluid-work
[14:06:28 CDT(-0500)] * colinclark (~colin@bas2-clarkson16-1176020060.dsl.bell.ca) has joined #fluid-work
[14:39:25 CDT(-0500)] * anastasiac (~team@142.150.154.193) has joined #fluid-work
[14:46:43 CDT(-0500)] <nickb1> colinclark: thank you - I've got it working based on your help
[14:46:50 CDT(-0500)] <nickb1> i have one follow up question though
[14:46:54 CDT(-0500)] <colinclark> wow, that's awesome
[14:46:56 CDT(-0500)] <colinclark> glad i could help
[14:47:18 CDT(-0500)] <nickb1> the last thing I need to implement is removal of rows that no longer exist in the data
[14:47:40 CDT(-0500)] <nickb1> it seems the row lingers in the table after it's data disappears from the json data
[14:49:37 CDT(-0500)] <colinclark> oh, strange
[14:49:54 CDT(-0500)] <colinclark> send us some code
[14:50:03 CDT(-0500)] <nickb1> i'll try to craft up an example
[14:50:06 CDT(-0500)] <colinclark> cool
[15:03:45 CDT(-0500)] <nickb1> i take that back - the rows do disappear automatically
[15:03:48 CDT(-0500)] <nickb1> rad!
[15:04:03 CDT(-0500)] <colinclark>
[15:04:07 CDT(-0500)] <nickb1> i had a bug in my dao that returned data that should have expired - fixed now
[15:04:13 CDT(-0500)] <nickb1> thank you again for all the help, this is working great
[15:04:46 CDT(-0500)] <colinclark> awesome!
[15:20:49 CDT(-0500)] * EricDalquist (~dalquist@2607:f388:e:0:221:9bff:fe37:e768) has joined #fluid-work
[15:22:03 CDT(-0500)] * michelled (~michelled@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[15:34:10 CDT(-0500)] * Justin_o (~Justin@142.150.154.171) has left #fluid-work
[15:42:58 CDT(-0500)] * anastasiac (~team@142.150.154.193) has left #fluid-work
[16:53:08 CDT(-0500)] * nickb1 (~nblair@2607:f388:e:0:21a:a0ff:fe9b:9fdf) has left #fluid-work
[17:06:12 CDT(-0500)] * michelled (~michelled@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[18:39:02 CDT(-0500)] * kasper (~kasper@189.188.54.2) has joined #fluid-work
[19:09:01 CDT(-0500)] * colinclark (~colin@bas2-toronto09-1176406399.dsl.bell.ca) has joined #fluid-work