fluid-work IRC Logs-2010-06-09

[00:53:34 CDT(-0500)] * Bosmon4 (~a@c-67-176-80-187.hsd1.co.comcast.net) has joined #fluid-work
[03:52:07 CDT(-0500)] * denbuzze (~anonymous@ginger.caret.cam.ac.uk) has joined #fluid-work
[04:36:49 CDT(-0500)] * denbuzze (~anonymous@ginger.caret.cam.ac.uk) has joined #fluid-work
[07:56:21 CDT(-0500)] * Justin_o (~Justin@142.150.154.171) has joined #fluid-work
[08:12:16 CDT(-0500)] * jessm (~Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined #fluid-work
[08:12:18 CDT(-0500)] * kasper (~kasper@189.130.79.156) has joined #fluid-work
[08:13:17 CDT(-0500)] * anastasiac (~team@142.150.154.193) has joined #fluid-work
[08:24:10 CDT(-0500)] * yura_ (~yura@142.150.154.114) has joined #fluid-work
[08:34:08 CDT(-0500)] * colinclark (~colin@bas2-toronto09-1176406399.dsl.bell.ca) has joined #fluid-work
[08:35:59 CDT(-0500)] <colinclark> Morning, Justin_o
[08:36:17 CDT(-0500)] <Justin_o> colinclark: hello
[08:36:32 CDT(-0500)] <colinclark> Last night I got the first part of a two-part bug fixed in the Decapod server
[08:36:57 CDT(-0500)] <Justin_o> colinclark: really... that's good... i guess it had to do with pathing
[08:37:20 CDT(-0500)] <colinclark> Yep
[08:37:44 CDT(-0500)] <colinclark> It now no longer requires you to adjust the configuration to some absolute path on your system just to get the thing to work
[08:37:55 CDT(-0500)] <colinclark> The second half of the issue is to get rid of hardcoded paths in the code
[08:38:17 CDT(-0500)] <Justin_o> ah i see... that's good... so now the the setup is just download and run the install script
[08:38:29 CDT(-0500)] <colinclark> yep
[08:38:43 CDT(-0500)] <colinclark> I verified that this is indeed the case by switching back to VMWare yesterday
[08:39:01 CDT(-0500)] <colinclark> I hit a pretty remarkable problem with Virtual Box yesterday that I hope I can't recreate in VMWare
[08:39:35 CDT(-0500)] <Justin_o> colinclark: what happened?
[08:39:42 CDT(-0500)] <colinclark> So, we take a couple pictures, stitch them together into some kind of ridiculous 30 megapixel image, and then send the, full size, back to the browser
[08:39:53 CDT(-0500)] <colinclark> Firefox was just crawling, trying to draw the image on screen
[08:39:54 CDT(-0500)] <Justin_o> yep
[08:40:27 CDT(-0500)] <colinclark> X ran at nearly 100% of CPU while I watched the image draw painstakingly, line by line
[08:40:46 CDT(-0500)] <colinclark> So I guess I can only assume that other people use Virtual Box for something, and that this is maybe a bug in the Mac version or something
[08:40:54 CDT(-0500)] <colinclark> But it certainly made Decapod unworkable
[08:41:11 CDT(-0500)] <colinclark> It appears to be something like 2-3x slower in general than VMWare, unfortunately
[08:41:45 CDT(-0500)] <Justin_o> colinclark: that's unfortunate... i can try it on the vista machine later if you like
[08:41:52 CDT(-0500)] <colinclark> I'd be pretty curious
[08:41:56 CDT(-0500)] <colinclark> But it's not a huge priority
[08:42:10 CDT(-0500)] <colinclark> So the next step is to take the hardcoded paths out of the server code itself, for Capture.html
[08:42:26 CDT(-0500)] <colinclark> I don't quite know why it's like this in the first place, but it should be a relatively easy thing to do
[08:42:38 CDT(-0500)] <colinclark> If we've got all that pathing information already defined in the config, I assume we can read it back out again
[08:42:55 CDT(-0500)] <colinclark> Or, better yet, replace the code that loads Capture.html from the file systems and returns it as a response
[08:43:02 CDT(-0500)] <colinclark> Instead redirecting to the actual HTML page in the first place
[08:47:07 CDT(-0500)] <Justin_o> colinclark: okay
[08:47:11 CDT(-0500)] <Justin_o> makes sense...
[08:49:18 CDT(-0500)] <Justin_o> so i was thinking about my next steps... I talked with jameswy, he and jonathan have wireframes and storycards going for the callibration. Do you think it makes more sense for me to start getting some of the calibration pages ready, with assumptions about how it will communicate with the server... or to help you get the server ready for the ui first.
[08:49:49 CDT(-0500)] <Justin_o> colinclark: ^
[08:50:11 CDT(-0500)] <colinclark> Go for the UI, it's a clear path forward
[08:50:20 CDT(-0500)] <colinclark> Since you already know the language and how to build components, etc.
[08:50:55 CDT(-0500)] <Justin_o> true... thanks... i think i'll start in on that today
[08:55:46 CDT(-0500)] <colinclark> sounds great
[08:57:08 CDT(-0500)] <Justin_o> colinclark: if you need to check something into the googlecode site you should do it asap, it will go read only at 10am today
[08:57:17 CDT(-0500)] <colinclark> ack
[08:57:17 CDT(-0500)] <colinclark> ok
[08:57:33 CDT(-0500)] <colinclark> well, thank goodness for bitbucket
[08:58:06 CDT(-0500)] <Justin_o> yes.. it is convenient that we have two public repos for these
[08:59:28 CDT(-0500)] <Justin_o> colinclark: just to double check... i should be doing development using the default repo from googlecode?
[08:59:38 CDT(-0500)] <colinclark> yep
[08:59:50 CDT(-0500)] <colinclark> although, if you want my changes, clone server from my bit bucket
[09:00:02 CDT(-0500)] <colinclark> my changes should allow you to run the servers without having to move UI around
[09:00:07 CDT(-0500)] <colinclark> Lemme grab you a URL
[09:00:35 CDT(-0500)] <colinclark> http://www.bitbucket.org/colinbdclark/decapod-server
[09:01:01 CDT(-0500)] <Justin_o> colinclark: thanks
[09:01:23 CDT(-0500)] <colinclark> It all seems to work, but I'd hoped you would try it before I commit it to the master
[09:01:41 CDT(-0500)] <Justin_o> colinclark: sure i'll give it a try
[09:02:45 CDT(-0500)] <Justin_o> colinclark: we should also probably have some way of properly stopping the server
[09:03:04 CDT(-0500)] <Justin_o> i seem to always have to kill the process
[09:04:25 CDT(-0500)] <colinclark> I'll look into it
[09:05:03 CDT(-0500)] <Justin_o> thanks...
[09:10:47 CDT(-0500)] <Justin_o> colinclark: do i still start the server with "python dserver.py"
[09:10:53 CDT(-0500)] <colinclark> yep
[09:10:59 CDT(-0500)] <Justin_o> okay... i'll give a try now
[09:11:12 CDT(-0500)] <colinclark> lacking cameras last night at home, i didn't actually test dserver
[09:11:16 CDT(-0500)] <colinclark> But mockserver worked
[09:11:26 CDT(-0500)] <colinclark> Now all we need to do is get rid of mockserver
[09:11:34 CDT(-0500)] <Justin_o> i forgot to pull the cameras out, i'm going to dig them out of the drawer...
[09:11:39 CDT(-0500)] <Justin_o> yes... that would be good
[09:19:48 CDT(-0500)] <Justin_o> colinclark: looks like dserver.py is still working
[09:22:38 CDT(-0500)] <colinclark>
[09:26:20 CDT(-0500)] * colinclark_ (~colin@bas2-toronto09-1176406399.dsl.bell.ca) has joined #fluid-work
[09:49:33 CDT(-0500)] * michelled (~michelled@142.150.154.101) has joined #fluid-work
[09:51:53 CDT(-0500)] * denbuzze (~anonymous@ginger.caret.cam.ac.uk) has joined #fluid-work
[09:58:21 CDT(-0500)] * colinclark (~colin@bas2-toronto09-1176406399.dsl.bell.ca) has joined #fluid-work
[10:03:28 CDT(-0500)] * athena (~athena@c-76-121-97-221.hsd1.wa.comcast.net) has joined #fluid-work
[10:06:49 CDT(-0500)] <athena> good morning - anyone around that might be able to give me some renderer/pager-related advice?
[10:21:33 CDT(-0500)] * anastasiac (~team@142.150.154.193) has joined #fluid-work
[10:25:30 CDT(-0500)] <jessm> athena: colin will be around soon and Bos and he were working together yesterday – not sure if Bos will pop in
[10:25:41 CDT(-0500)] <athena> thanks jessm
[10:25:59 CDT(-0500)] <athena> i know anastasiac said it should work, but i think i may need a few pointers on how to really get it set up
[10:33:40 CDT(-0500)] <athena> woah.
[10:33:56 CDT(-0500)] <athena> i guess i'm all set!
[10:34:24 CDT(-0500)] <athena> for the record you guys get major point for that just working out of the box on the first try
[10:34:58 CDT(-0500)] <athena> i mean, i know you said it'd probably work, but that's pretty amazing that it was that easy and i don't see any issues, given that it sounds like it hadn't been tested before
[10:40:19 CDT(-0500)] * croby (~croby@c-67-171-37-218.hsd1.wa.comcast.net) has joined #fluid-work
[10:42:09 CDT(-0500)] * colinclark (~colin@142.150.154.101) has joined #fluid-work
[10:44:24 CDT(-0500)] * clown (~clown@142.150.154.101) has joined #fluid-work
[11:03:23 CDT(-0500)] <athena> is it possible to map cutpoints into the pager instead of using rsf:id attributes?
[11:16:41 CDT(-0500)] * EricDalquist (~dalquist@2607:f388:e:0:221:9bff:fe37:e768) has joined #fluid-work
[11:25:50 CDT(-0500)] <colinclark> athena: sorry, missed your message and am in a meeting
[11:25:58 CDT(-0500)] <colinclark> will ping you when i'm done, but the answer is yes, I think so
[11:25:58 CDT(-0500)] <athena> no rush
[11:26:01 CDT(-0500)] <athena> thanks!
[11:26:09 CDT(-0500)] <athena> we can catch up later
[11:55:51 CDT(-0500)] <croby> did the save widget data function make it into the sakai.api.Widgets api yet? I can't seem to find it in sakai_magic.js
[11:56:14 CDT(-0500)] <croby> nevermind, just found it
[12:07:42 CDT(-0500)] * Bosmon2 (~a@c-67-176-80-187.hsd1.co.comcast.net) has joined #fluid-work
[12:08:11 CDT(-0500)] <Bosmon2> Gah... even the clipboard is empty
[12:08:15 CDT(-0500)] <Bosmon2> Stupid crappy Flash app
[12:08:34 CDT(-0500)] <colinclark> So, michelled, you had wanted to talk about something to do with decorators...
[12:08:35 CDT(-0500)] <Bosmon2> I had just typed, "The only changes to the renderer were slight refactorings to support the functions in RendererUtilities"
[12:08:43 CDT(-0500)] <colinclark> Something from CSpace
[12:08:48 CDT(-0500)] <Bosmon2> I don't think we will make any substantive changes to the renderer until after the next Infusion release
[12:08:54 CDT(-0500)] <Bosmon2> Although we might deprecate a few features in this release
[12:08:57 CDT(-0500)] <colinclark> That seems reasonable, Bosmon2
[12:09:01 CDT(-0500)] <Bosmon2> For example, the use of "dehydrated trees"
[12:09:29 CDT(-0500)] <Bosmon2> So that we can remove them in the following release
[12:09:29 CDT(-0500)] <Justin_o> Bosmon2: doesn't any of our code use dehydrated trees, that you know of
[12:09:45 CDT(-0500)] <Bosmon2> Justin_o: The only use of dehydrated trees I believe is just in test cases
[12:09:53 CDT(-0500)] <Justin_o> Bosmon2: okay... thanks
[12:10:02 CDT(-0500)] <yura_> yesterday we tried to sketch the repeatable decorator for cspace. We also looked at the way another way one of the decorators was implemented (NumberPatternChooser)
[12:10:13 CDT(-0500)] <Bosmon2> ok, yes, we should talk about this
[12:10:37 CDT(-0500)] <yura_> it has a public function:
[12:10:37 CDT(-0500)] <yura_> cspace.numberPatternChooser.getDecoratorOptions = function (parentComponent) {
[12:10:37 CDT(-0500)] <yura_> return {
[12:10:37 CDT(-0500)] <yura_> baseUrl: parentComponent.dataContext.options.baseUrl,
[12:10:37 CDT(-0500)] <yura_> applier: parentComponent.applier
[12:10:38 CDT(-0500)] <yura_> };
[12:10:38 CDT(-0500)] <yura_> };
[12:10:39 CDT(-0500)] <Bosmon2> If it makes sense, you should try to fit the syntax of the decorator into the pattern established for the "expanders"
[12:10:42 CDT(-0500)] <Bosmon2> Ah yes, that
[12:10:51 CDT(-0500)] <anastasiac> Justin_o, Bosmon2: FYI the branch has one failing test for inline edit that is NOT failing in the 1.2 release - something about a "duckMap"
[12:10:51 CDT(-0500)] <Bosmon2> Well, that we can't really resolve without "true final IoC"
[12:11:10 CDT(-0500)] <Bosmon2> anastasiac: The branch is not in a running condition right now
[12:11:15 CDT(-0500)] <anastasiac>
[12:11:35 CDT(-0500)] <Bosmon2> yura_: So the "getDecoratorOptions" scheme is a fine stopgap for this functionality until the next Infusion release
[12:11:49 CDT(-0500)] <yura_> so here this function is being executed in the cspace renderer when we find a decorator we are asking if it has "getDecoratorOptions"
[12:11:59 CDT(-0500)] <Bosmon2> I don't think we are expecting "true final IoC" for a month absolute minimum.. probably more realistically 2 months
[12:12:11 CDT(-0500)] <yura_> and pass that (parent componeent) to it
[12:12:44 CDT(-0500)] <Bosmon2> We might be able to improve getDecoratorOptions a little once 3658 is merged in, since it could then make use of "context references"
[12:13:09 CDT(-0500)] <Bosmon2> For example we could write these expressions as "${{that}.dataContext.options.baseUrl}" etc.
[12:13:27 CDT(-0500)] <yura_> so in order to avoid building it's own cutpoints and componenttree for repeatable component one of the things that we inject into its options is a uispec
[12:13:36 CDT(-0500)] <yura_> of the parent component
[12:13:46 CDT(-0500)] <Bosmon2> yura_ - can you paste an example?
[12:13:50 CDT(-0500)] <yura_> yes
[12:13:58 CDT(-0500)] <yura_> cspace.repeatable.getDecoratorOptions = function (parentComponent) {
[12:13:59 CDT(-0500)] <yura_> return {
[12:13:59 CDT(-0500)] <yura_> applier: parentComponent.applier,
[12:13:59 CDT(-0500)] <yura_> uispec: parentComponent.uispec
[12:13:59 CDT(-0500)] <yura_> };
[12:13:59 CDT(-0500)] <yura_> };
[12:14:12 CDT(-0500)] <yura_> this is what repeatable gets added into the options
[12:14:17 CDT(-0500)] <Bosmon2> ok
[12:14:22 CDT(-0500)] <Bosmon2> And what use does it make of the uispec?
[12:14:33 CDT(-0500)] <yura_> let me show the options that are in the uispec for this decorator
[12:14:43 CDT(-0500)] <yura_> ".csc-object-description-color-repeated-container": {
[12:14:43 CDT(-0500)] <yura_> "decorators": [{
[12:14:43 CDT(-0500)] <yura_> "type": "fluid",
[12:14:43 CDT(-0500)] <yura_> "func": "cspace.repeatable",
[12:14:43 CDT(-0500)] <yura_> "options": {
[12:14:44 CDT(-0500)] <yura_> "elPath": "fields.color",
[12:14:44 CDT(-0500)] <yura_> "uispecElPath": ".csc-object-description-color-row:"
[12:14:45 CDT(-0500)] <yura_> }
[12:14:45 CDT(-0500)] <yura_> }]
[12:14:46 CDT(-0500)] <yura_> },
[12:15:14 CDT(-0500)] <Bosmon2> Seems sort of worrying
[12:15:19 CDT(-0500)] <Bosmon2> Aren't you injecting "the entire" uispec?
[12:15:37 CDT(-0500)] <yura_> no, the uispec of a parent
[12:15:57 CDT(-0500)] <Bosmon2> How does the parent get its uispec?
[12:15:59 CDT(-0500)] <yura_> so in our sketch it was the recordEditor's uispec
[12:16:10 CDT(-0500)] <yura_> from its parent component
[12:16:14 CDT(-0500)] <Bosmon2> Still, at least, it is the uispec for more than just the decorator
[12:16:19 CDT(-0500)] <yura_> yes
[12:16:28 CDT(-0500)] <Bosmon2> How is the decorator to find the section of the uispec that is relevant to it?
[12:16:42 CDT(-0500)] <yura_> "uispecElPath": ".csc-object-description-color-row:"
[12:17:03 CDT(-0500)] <yura_> this will point to a block for smth that's repeated
[12:17:14 CDT(-0500)] <Bosmon2> I see... a reference out of the UI spec to another part of itself
[12:17:15 CDT(-0500)] <yura_> with whatever children, etc. insid
[12:17:28 CDT(-0500)] <yura_> yes
[12:17:33 CDT(-0500)] <Bosmon2> This is generally a bad idea
[12:18:11 CDT(-0500)] <Bosmon2> For a few reasons...
[12:18:35 CDT(-0500)] <Bosmon2> It will make the uispec somewhat brittle, since sections cannot be relocated without looking at them in detail
[12:18:42 CDT(-0500)] <Bosmon2> And more problematically, there will be "expansion order issues"
[12:19:03 CDT(-0500)] <Bosmon2> What occurs when the expansion of the uispec reaches ".csc-object-description-color-row:" in its own right?
[12:19:23 CDT(-0500)] <Bosmon2> And what occurs if this happens before, or after, the expansion of ".csc-object-description-color-repeated-container"?
[12:19:58 CDT(-0500)] <yura_> well
[12:20:04 CDT(-0500)] <yura_> it will do the right thing
[12:20:09 CDT(-0500)] <Bosmon2> hahha
[12:20:26 CDT(-0500)] <yura_> expand it as if it doesnt know about the decorator
[12:20:39 CDT(-0500)] <Bosmon2> Yes
[12:20:44 CDT(-0500)] <Bosmon2> What if it tries to expand the decorator first?
[12:21:11 CDT(-0500)] <yura_> it's fine the decorator doesn't render anything unless we update the model by repeating
[12:22:59 CDT(-0500)] <anastasiac> Bosmon2, "expanders" are not required for everything, are they?
[12:23:47 CDT(-0500)] <anastasiac> our decorator's reference to elsewhere in the uispec isn't actually "used" until the decorating component is instantiated, which is well past when the expanders do their work
[12:24:30 CDT(-0500)] <colinclark> such odd use of "quotation marks"
[12:24:38 CDT(-0500)] <michelled> you know, I was just beginning to grok this but I'm confused again. can we step back and talk about the goal and the issues we are addressing?
[12:25:16 CDT(-0500)] <anastasiac> colinclark, do you have something "against" quotation marks? :-P
[12:25:30 CDT(-0500)] <michelled> so, we have the functional requirement of repeatability. it boils down to a + near a field or set of fields and when it is clicked it adds an empty field or set of fields
[12:25:37 CDT(-0500)] <michelled> am I right so far yura_ ?
[12:25:56 CDT(-0500)] <yura_> yes
[12:25:59 CDT(-0500)] * anastasiac could be asking stupid questions because she doesn't fully understand Bosmon's expanders yet
[12:26:59 CDT(-0500)] * colinclark is hearing stomachs grumbling
[12:27:06 CDT(-0500)] <colinclark> But this conversation is huge
[12:27:13 CDT(-0500)] <michelled> it is - and interesting
[12:27:14 CDT(-0500)] <colinclark> Bosmon2: What's your sked like today?
[12:27:17 CDT(-0500)] <Bosmon2> Well, it's not strictly a matter of "using" expanders, or not...
[12:27:29 CDT(-0500)] <Bosmon2> But rather at least of taking on board the lessons that were learned from implementing them
[12:27:36 CDT(-0500)] <colinclark>
[12:28:11 CDT(-0500)] <michelled> Bosmon2: do you have time later today to continue this conversation?
[12:28:18 CDT(-0500)] <Bosmon2> So... the risk of "references outside expanded material" are i) brittleness of the resulting structure, but more seriously ii) issues caused by the fact that processing of the tree is essentially unordered with respect to siblings
[12:28:23 CDT(-0500)] <Bosmon2> Yes, I should be free at about 3pm your time
[12:28:40 CDT(-0500)] <Bosmon2> So, there are no guarantees in terms of when the members of a JSON structure are visited during iteration
[12:28:54 CDT(-0500)] <Bosmon2> We already had our share of hilarious issues caused by this in Engage wrt. constructing Couch keys
[12:29:08 CDT(-0500)] <Bosmon2> When we found that there were pieces of code that would "mysteriously work for a long time" and then "unexpectedly break"
[12:30:44 CDT(-0500)] <michelled> that's the worst type of bug - especially when tests are spotty
[12:31:37 CDT(-0500)] <colinclark> it came as something of a surprise to us
[13:22:59 CDT(-0500)] * croby (~croby@c-67-171-37-218.hsd1.wa.comcast.net) has left #fluid-work
[13:44:40 CDT(-0500)] * michelled (~michelled@142.150.154.101) has joined #fluid-work
[13:44:40 CDT(-0500)] * croby (~croby@c-67-171-37-218.hsd1.wa.comcast.net) has joined #fluid-work
[13:44:54 CDT(-0500)] <croby> does Fluid by default do something to file input boxes?
[13:45:21 CDT(-0500)] <croby> i'm having trouble with integrating the jquery multifile plugin on Sakai (which uses fluid)
[14:01:39 CDT(-0500)] * kasper (~kasper@189.130.79.156) has joined #fluid-work
[14:11:03 CDT(-0500)] <jessm> croby: did you find the answer?
[14:11:14 CDT(-0500)] <jessm> Justin_o: do you know? ^^
[14:13:19 CDT(-0500)] * colinclark (~colin@142.150.154.101) has joined #fluid-work
[14:15:03 CDT(-0500)] <croby> jessm: i did, it wasn't realted to fluid at all
[14:15:11 CDT(-0500)] <croby> that i could tell
[14:15:13 CDT(-0500)] <croby> thanks though!
[14:15:22 CDT(-0500)] <jessm> croby: cool! glad it worked itself out
[14:19:41 CDT(-0500)] <michelled> yura_: did you want to continue explaining the repeatable fields issue?
[14:20:03 CDT(-0500)] <yura_> yes sure. Bosmon2, are you in the channel right now?
[14:20:06 CDT(-0500)] * Bosmon (~Bosmon@eccr224-158-dhcp.colorado.edu) has joined #fluid-work
[14:20:13 CDT(-0500)] <Bosmon> I seem to be here
[14:20:15 CDT(-0500)] <Bosmon> Do I?
[14:20:21 CDT(-0500)] <Bosmon> Wow... I am unnumbered
[14:20:21 CDT(-0500)] <yura_> yes
[14:21:39 CDT(-0500)] <yura_> so I guess the above examples show how the component decorator was sketched
[14:22:14 CDT(-0500)] <Bosmon> OK
[14:22:47 CDT(-0500)] <yura_> as Michelle mentioned the functionality that we need is the ability to click on plus button and add new rows of some arbitrary data
[14:23:29 CDT(-0500)] <Bosmon> So, I am just debating with Colin, "how good we need to make this feature"
[14:23:46 CDT(-0500)] <Bosmon> As I have outlined, there are a number of strategic weaknesses with this approach you have sketched....
[14:23:58 CDT(-0500)] <Bosmon> That is, it will be hard to build any further features on this base
[14:24:21 CDT(-0500)] <Bosmon> For example, considering the fatal issue... "What if there are more of your 'decorators' attached in the uispec material referenced from your EL path"?
[14:24:21 CDT(-0500)] <colinclark> My comment was that we're best to sketch out what would be ideal, and then scale it back to what can be immediately accomplished. Take a small step towards our goal, in other words.
[14:26:18 CDT(-0500)] <michelled> so yura_, what is it about the repeatable fields use case that makes it different from our other decorators?
[14:26:56 CDT(-0500)] <Bosmon> The thing that makes it different is that this "decorator" is actually a "consumer" of component tree
[14:27:02 CDT(-0500)] <Bosmon> That is, morally, it is actually an "expander"
[14:27:29 CDT(-0500)] <yura_> yes, the difference is that we actually tried not to provide the component with knowledge of its own components tree, cutpoints etc
[14:27:46 CDT(-0500)] <Bosmon> And once I complete the infrastructure for "expanders" it will most likely become one...
[14:28:28 CDT(-0500)] <Bosmon> Now, once the "decorator" has responsibility for consuming and processing parts of component tree, we end up in the realm of "order of interaction" problems
[14:28:38 CDT(-0500)] <Bosmon> As soon as there is ever another decorator of this kind, all hell breaks loose
[14:30:32 CDT(-0500)] <yura_> Bosmon would you make an example of how it would break?
[14:31:08 CDT(-0500)] <yura_> also the component is not exactly an expander, i think, it has only one expander-like function (when rendering), but it does more than that
[14:31:39 CDT(-0500)] <Bosmon> Well, think about the material referenced through the uiSpecElPath
[14:31:50 CDT(-0500)] <Bosmon> What happens if this material contains some decorators - in the "new sense"
[14:32:08 CDT(-0500)] <Bosmon> Or requires any of the other processing that is required by the "UISpec" pipeline
[14:33:18 CDT(-0500)] <anastasiac> yura_, one example of a decorator inside the material referenced through the uispecelpath would be the autocomplete decorator
[14:33:42 CDT(-0500)] <yura_> Bosmon, i m wondering if that would break though
[14:34:33 CDT(-0500)] <anastasiac> Bosmon, our uispecs won't be modified, ever.
[14:35:04 CDT(-0500)] <anastasiac> the expansion process happens happens as part of the conversion from proto-tree to component tree, doesn't it?
[14:35:28 CDT(-0500)] <anastasiac> wouldn't the original uispec remain untouched?
[14:35:43 CDT(-0500)] * anastasiac could be completely misunderstanding, so please be patient with stupid questions
[14:37:20 CDT(-0500)] <michelled> yura_: is there a patch of your sketch somewhere?
[14:37:35 CDT(-0500)] <yura_> yes one sec
[14:37:46 CDT(-0500)] <yura_> http://issues.collectionspace.org/browse/CSPACE-1278
[14:37:51 CDT(-0500)] <yura_> it has a patch attached
[14:44:28 CDT(-0500)] <michelled> so we won't be able to pass the applier as an option. is there a reason it is done that way?
[14:45:19 CDT(-0500)] <anastasiac> michelled, currently the applier is supplied to the decorator through the mock-IoC of the ...getDecoratorOptions() function
[14:45:32 CDT(-0500)] <anastasiac> When that was originally designed, it was only options that were an issue
[14:45:57 CDT(-0500)] <anastasiac> so yura_ passed the applier as an option because options were the only option available
[14:46:02 CDT(-0500)] <anastasiac> does that make sense?
[14:46:23 CDT(-0500)] <Bosmon> anastasia - YOU are processing the uispec - by turning it into a prototree
[14:46:30 CDT(-0500)] <Bosmon> I can only try repeating my question
[14:46:49 CDT(-0500)] <anastasiac> Bosmon, yes, we are. But we are not actually modifying the original uispec, we are creating a new object
[14:46:51 CDT(-0500)] <Bosmon> What if there were more of your decorators inside the material referenced by the repeater decorator?
[14:47:34 CDT(-0500)] <Bosmon> So - look through your file, "Renderer.js" - for all of the workflow which you apply to a "uispec"...
[14:47:41 CDT(-0500)] <michelled> anastasiac: we can also pass args to a renderer decorator, can't we?
[14:48:22 CDT(-0500)] <anastasiac> michelled, yes - I believe that args is an alternative to options. That was one thing we considered - modifying getDecoratorOptions to getDecoratorArgs
[14:48:30 CDT(-0500)] <anastasiac> but we haven't yet fully thought that through
[14:50:12 CDT(-0500)] <anastasiac> Bosmon, I don't suppose there's any way to update the renderer's autobinding after something is rendered, is there? Say, if we were to manipulate the DOM to add some new input fields?
[14:50:53 CDT(-0500)] <anastasiac> (to be clear: I mean without re-rendering)
[14:54:29 CDT(-0500)] <Bosmon> Why would you want to do this?
[14:54:51 CDT(-0500)] <anastasiac> If we could do that, this whole issue of how to re-use the uispec would be moot, because we wouldn't
[14:55:48 CDT(-0500)] <anastasiac> I imagine it's not at all feasible, I'm just throwing wild ideas around, just in case
[14:56:06 CDT(-0500)] <michelled> anastasiac: currently is the strategy to modify the model by adding a new empty field and then use the uispec and the model to render the section of the page?
[14:56:39 CDT(-0500)] <anastasiac> michelled, yes: that's the strategy
[15:00:59 CDT(-0500)] <michelled> ok, so before we broke for lunch we were stepping back to try to see the bigger picture.
[15:01:08 CDT(-0500)] <michelled> at the risk of repetition, lets do that again
[15:01:11 CDT(-0500)] <michelled> I said: we have the functional requirement of repeatability. it boils down to a + near a field or set of fields and when it is clicked it adds an empty field or set of fields
[15:02:33 CDT(-0500)] <michelled> what's interesting about this use case is that the repeater doesn't know what it's repeating. it could be a single field, it could be a group of fields it could be a field that is already decorated like an autocomplete
[15:02:45 CDT(-0500)] <michelled> that right so far anastasiac and yura_ ?
[15:02:55 CDT(-0500)] <anastasiac> yes
[15:02:56 CDT(-0500)] <yura_> yes
[15:03:37 CDT(-0500)] <michelled> so the sketch you made envisioned the repeater as a renderer decorator - yes?
[15:03:51 CDT(-0500)] <yura_> yes
[15:04:17 CDT(-0500)] <Bosmon> We should interject here that this is not "simply" a renderer decorator
[15:04:40 CDT(-0500)] <Bosmon> But one that is particularly honoured by the workflow in Renderer.js as part of the pipeline of interpreting "ui specs" into "protocomponent trees"
[15:05:43 CDT(-0500)] <michelled> yes - this particular renderer decorators ingests a ui spec and takes it through the same phases as other cspace components that understand ui specs
[15:05:52 CDT(-0500)] <anastasiac> Bosmon, I don't know that the Repeater is part of the pipeline, but rather that it has it's own independent pipeline that would be executed later, in response to the 'add' button
[15:06:22 CDT(-0500)] <anastasiac> at initial rendering of the entire page, the Repeater's rendering process would not happen at all
[15:07:56 CDT(-0500)] <michelled> so the repeater's job is to listen to a click on the add button and then modify the model to include a new empty field (or group of fields or autocomplete etc) and rerender that part of the page
[15:09:07 CDT(-0500)] <yura_> michelled: also the functionality related to primary field selection and deletion of the repeated fields
[15:09:39 CDT(-0500)] <michelled> right - make sense Bosmon?
[15:12:03 CDT(-0500)] <Bosmon> Sorry, sec
[15:25:52 CDT(-0500)] <Bosmon> Hopefully Colin is working through his "meta-explanation" with you now
[15:27:25 CDT(-0500)] <michelled> no, he's working on decapod
[15:28:16 CDT(-0500)] <Bosmon> oh dear
[15:28:36 CDT(-0500)] <colinclark> I'm here, I'm here
[15:28:46 CDT(-0500)] <michelled> two and a half cats are important
[15:28:47 CDT(-0500)] <colinclark> I had suggested to Bosmon that perhaps we need to have a bit of a meta conversation
[15:28:50 CDT(-0500)] <colinclark> To talk about talking
[15:29:03 CDT(-0500)] <colinclark> But then you guys were chatting amongst yourselves so I didn't want to disrupt things
[15:29:13 CDT(-0500)] <colinclark> Ok, if you'll humour me for a moment
[15:29:14 CDT(-0500)] <colinclark> ...
[15:29:30 CDT(-0500)] <colinclark> My father once said this kind of "process talk" was somewhat awkward socially
[15:29:37 CDT(-0500)] <colinclark> But he's kind an awkward guy himself
[15:29:39 CDT(-0500)] <colinclark> I digress
[15:29:42 CDT(-0500)] <michelled> lol
[15:29:54 CDT(-0500)] <colinclark> So, from afar, this conversation seems a bit stuck
[15:30:11 CDT(-0500)] <colinclark> I really like how michelled has reiterated the end goal
[15:30:17 CDT(-0500)] <colinclark> I think, so far, that seems pretty clear to me
[15:30:33 CDT(-0500)] <colinclark> Is it clear to you, Bosmon, anastasiac, and yura, too?
[15:30:43 CDT(-0500)] <Bosmon> yes, it is clear
[15:30:43 CDT(-0500)] <anastasiac> es
[15:30:53 CDT(-0500)] <yura_> yep
[15:30:58 CDT(-0500)] <colinclark> Ok
[15:31:04 CDT(-0500)] <colinclark> So we have a sketch of an implementation
[15:31:30 CDT(-0500)] <colinclark> Don't know what the merits of implementation are myself, because I haven't been closely enough involved
[15:31:47 CDT(-0500)] <colinclark> But then, I think I hear Bosmon asking some questions about the strategy
[15:32:03 CDT(-0500)] <colinclark> And not feeling satisfied that he was getting any real answers to the questions
[15:32:14 CDT(-0500)] <colinclark> Which I might interpret as being confusion about the nature of the questions?
[15:32:54 CDT(-0500)] <colinclark> So, I'm wondering, if we encounter some of these questions that don't quite seem clear, if we could try to clarify and elaborate on them
[15:33:09 CDT(-0500)] <colinclark> Rather than not answering them, or perhaps feeling frustrated that they don't make sense
[15:33:46 CDT(-0500)] <colinclark> So, let's see if we can figure out what a next step is
[15:33:53 CDT(-0500)] <colinclark> So we've got an implementation sketch
[15:34:21 CDT(-0500)] <colinclark> And I guess, in part, it hinges on the idea that we store references in the prototree to other parts of the prototree
[15:34:37 CDT(-0500)] <colinclark> And then divide up portions of the prototree and hand it off to components in order to know what to do when rendering
[15:35:28 CDT(-0500)] <michelled> it slightly more complicated in that the parts that we are handing off don't get rendered by the decorator in the original rendering of the page
[15:35:42 CDT(-0500)] <michelled> the parent does that original rendering
[15:35:54 CDT(-0500)] <colinclark> So then, I heard Bosmon express some concern about these references within the prototree, and asked a question about how this approach might scale with multiple decorators referenced inside the repeator decorator
[15:36:08 CDT(-0500)] <colinclark> I'm not sure I saw answer to the question, or even if the question was fully understood
[15:36:13 CDT(-0500)] <Bosmon> I think another thing that is confusing this discussion is mixed language concerning timelines....
[15:36:23 CDT(-0500)] <Bosmon> People talk about "rendering" as if it is "already happening"
[15:37:36 CDT(-0500)] <anastasiac> Bosmon, could you give an example of what you mean by 'People talk about "rendering" as if it is "already happening"'?
[15:38:08 CDT(-0500)] <anastasiac> and Bosmon, could you explain a bit why you view decorators inside the repeated stuff as a problem? What is it you envision happening?
[15:38:45 CDT(-0500)] <anastasiac> I think I don't understand the 'expansion' process enough to understand your concerns
[15:38:58 CDT(-0500)] <Bosmon> Well, the fact that we are talking about "rendering" already is already a little confusing
[15:39:10 CDT(-0500)] <Bosmon> Since everything that should be at issue right now should be just focused on the component tree
[15:39:54 CDT(-0500)] <anastasiac> Bosmon, I just want to make sure one thing is clear, to start:
[15:40:26 CDT(-0500)] <anastasiac> Right now, a separate component (call the RecordEditor) renders the whole page. Completely. Full rendering, with a call to either selfRender or reRender
[15:40:40 CDT(-0500)] <Bosmon> yes
[15:40:42 CDT(-0500)] <anastasiac> then, at a later time, we want the Repeatable component to render a portion of the page
[15:40:57 CDT(-0500)] <anastasiac> so maybe that's where the talk of 'already rendered' is coming from?
[15:41:00 CDT(-0500)] <Bosmon> I see
[15:41:32 CDT(-0500)] <Bosmon> Now, are you not planning for the "repeatable" section of the page to be already "correctly rendered" at the time when the main page is rendered?
[15:42:04 CDT(-0500)] <anastasiac> Bosmon, we expect the RecordEditor to correctly render the repeated part as part of the normal course of rendering the entire page. This, in fact, already works
[15:42:24 CDT(-0500)] * clown_ (~clown@142.150.154.101) has joined #fluid-work
[15:42:46 CDT(-0500)] * michelled_ (~michelled@142.150.154.101) has joined #fluid-work
[15:43:05 CDT(-0500)] <Bosmon> And as for my other question, perhaps it will clarify things if I paste this code here:
[15:43:22 CDT(-0500)] <anastasiac> Bosmon, can you also remind us of what the other question was?
[15:43:23 CDT(-0500)] <Bosmon> buildProtoTree: function (uispec, that) {
[15:43:23 CDT(-0500)] <Bosmon> var protoTree = {};
[15:43:23 CDT(-0500)] <Bosmon> fluid.model.copyModel(protoTree, uispec);
[15:43:23 CDT(-0500)] <Bosmon> for (var key in protoTree) {
[15:43:24 CDT(-0500)] * colinclark_ (~colin@142.150.154.101) has joined #fluid-work
[15:43:41 CDT(-0500)] <Bosmon> So, you can see here that there is a PROCESS which is being applied to the uispec to build the protoTree
[15:43:48 CDT(-0500)] <anastasiac> right...
[15:44:03 CDT(-0500)] <Bosmon> Now, you in your "sketch implementation" have designed an element which contains a reference from one part of the uispec to antoher
[15:44:10 CDT(-0500)] <anastasiac> right...
[15:44:22 CDT(-0500)] <Bosmon> So clearly, "a something" is happening to the uispec in order to interpret it
[15:44:34 CDT(-0500)] <Bosmon> But the ordering of these operations applied to different parts of the uispec is not defined
[15:45:15 CDT(-0500)] <Bosmon> So
[15:45:19 CDT(-0500)] <anastasiac> ok, I'm not sure what you're thinking of when you say '"a something" is happening to the uispec in order to interpret it' but just to be clear: the reference from one part of the uispec to another will be used on the original uispec, not on the prototree
[15:45:48 CDT(-0500)] * michelled (~michelled@142.150.154.141) has joined #fluid-work
[15:45:50 CDT(-0500)] <Bosmon> Let's imagine that the part of the tree referenced via your EL expression ALSO contains a reference to what we could call a "UIspec decorator" - which requires to be acted on by this line:
[15:45:57 CDT(-0500)] <Bosmon> if (fluid.getGlobalValue(dec.func + ".getDecoratorOptions")) {
[15:46:13 CDT(-0500)] <Bosmon> Or, on the other hand, requires the "model-directed expansion" from lower down
[15:46:59 CDT(-0500)] * anastasiac thinks she just might be starting to see the light Bosmon is trying to shed, but she's not sure, so she's going to keep listening until she is
[15:47:29 CDT(-0500)] <Bosmon> Well... I was sort of running to a close
[15:47:58 CDT(-0500)] <Bosmon> You have an "operation" defined which expands uispec to prototree form
[15:48:14 CDT(-0500)] <Bosmon> This operation processes the uispec ONCE, and also in an undefined order
[15:48:43 CDT(-0500)] <Bosmon> This implies that holding references from one part of the uispec to the other is untenable
[15:48:51 CDT(-0500)] <Bosmon> I think I remember explaining this kind of decision to you last Friday
[15:49:04 CDT(-0500)] <Bosmon> And I remember you said that it "all seemed perfectly obvious, in retrospect"
[15:49:43 CDT(-0500)] <anastasiac> Bosmon, your fear that holding a reference from one part to another is untenable seems to stem from the fact that the uispec will be changed by the process, and will therefor not be stable - is this correct?
[15:49:55 CDT(-0500)] <Bosmon> No
[15:50:04 CDT(-0500)] <anastasiac> so why is it untenable?
[15:51:03 CDT(-0500)] <Bosmon> Because the expansion process happens just ONCE, and in an undefined order
[15:51:31 CDT(-0500)] <anastasiac> I'm sorry, maybe I'm thick-headed (ok, well, I am), but I'm not understanding why this makes it untenable
[15:52:12 CDT(-0500)] <Bosmon> Well.... think about what is at the END of the EL reference into the uispec
[15:52:18 CDT(-0500)] <Bosmon> And what it means
[15:52:40 CDT(-0500)] <Bosmon> What are you going to do with what is at the end of that reference?
[15:52:41 CDT(-0500)] <anastasiac> thinking: what is at the end of the EL reference into the spec is the UISpec snippet for what we want repeated
[15:52:50 CDT(-0500)] <Bosmon> Yes
[15:52:54 CDT(-0500)] <Bosmon> And who is going to consume that snippet?
[15:52:55 CDT(-0500)] <anastasiac> we are going to use that to re-render that portion of the interface
[15:53:04 CDT(-0500)] <anastasiac> the Repeatable component
[15:53:06 CDT(-0500)] <Bosmon> ok
[15:53:14 CDT(-0500)] <Bosmon> And how is it going to do that?
[15:53:34 CDT(-0500)] <Bosmon> bearing in mind that a big part of the reason where we came in the door was reducing dependencies on the Repeatable component
[15:53:39 CDT(-0500)] <anastasiac> using the same process everything else uses: convert the uispec into a prototree, expand that, render it
[15:54:00 CDT(-0500)] <Bosmon> So - this means that the Repeatable "component" is going to have a dependency on the entire Collectionspace infrastructure?
[15:54:11 CDT(-0500)] <Bosmon> And so can't be used outside the domain where "uispecs" have any meaning?
[15:54:48 CDT(-0500)] <anastasiac> I might not be understanding your question, but just about everything in CSpace requires an understanding of uispecs
[15:55:03 CDT(-0500)] <Bosmon> None of the components you have implemented do
[15:55:06 CDT(-0500)] <Bosmon> Or at least I hope they don't
[15:55:13 CDT(-0500)] <anastasiac> they pretty much all do
[15:55:19 CDT(-0500)] <Bosmon> As I had understood it so far, they are all "perfectly normal renderer components"
[15:55:27 CDT(-0500)] <Bosmon> Is that really true...?
[15:55:32 CDT(-0500)] <anastasiac> ah, ok, so that might be a source of disconnect
[15:55:49 CDT(-0500)] <anastasiac> yes, most of the cspace component work with a uispec for their own area of screen real-estate
[15:55:54 CDT(-0500)] <Bosmon> Yes
[15:56:05 CDT(-0500)] <Bosmon> but as I had understood it," work with" simply meant "specified in terms of"
[15:56:13 CDT(-0500)] <anastasiac> rendered using
[15:56:17 CDT(-0500)] <Bosmon> Are you telling me that they have a run-time dependency on uispecs in order to function?
[15:56:36 CDT(-0500)] <anastasiac> basically, yes
[15:56:39 CDT(-0500)] <Bosmon>
[15:56:45 CDT(-0500)] <Bosmon> Excuse me whilst I nip out and shoot myself
[15:56:58 CDT(-0500)] <anastasiac>
[15:57:42 CDT(-0500)] <Bosmon> Could I ask we speculate why we didn't take the opportunity to invent a selection of components that might be useful to other users of Infusion?
[15:59:24 CDT(-0500)] <michelled> I would guess it was a resource issue
[15:59:40 CDT(-0500)] <michelled> meaning there were tight time constraints and not enough resources
[16:01:06 CDT(-0500)] <colinclark> I don't know if we can make much progress speculating on why things are the way they are right now
[16:01:09 CDT(-0500)] <colinclark> That's another conversation
[16:01:55 CDT(-0500)] <colinclark> Let's focus on our previously-stated "meta goal" of determining a vision and then making a practical first step towards it
[16:03:09 CDT(-0500)] <Bosmon> Well
[16:03:15 CDT(-0500)] <Bosmon> The two issues aren't entirely decoupled
[16:03:25 CDT(-0500)] <Bosmon> Since "where we want to go today" depends quite a lot on where we are
[16:04:09 CDT(-0500)] <Bosmon> I was assuming that there were "components" defined within CollectionSpace that could somehow be "rescued"
[16:04:20 CDT(-0500)] <Bosmon> At least, without rewriting them very significantly
[16:04:44 CDT(-0500)] <michelled> unfortunately I don't think that is currently true
[16:04:54 CDT(-0500)] <Bosmon> Anyway, I assume that our "vision" is to have something like the "Repeatable" component that we are talking about, that can be used outside of CollectionSpace
[16:05:12 CDT(-0500)] <michelled> that would be cool
[16:05:22 CDT(-0500)] <colinclark> 'twould
[16:10:50 CDT(-0500)] <anastasiac> Bosmon, we're just having a little verbal discussion about how this would look if it was a fluid component and not a cspace component
[16:10:55 CDT(-0500)] <anastasiac> sorry, we shouldn't do that verbally
[16:11:03 CDT(-0500)] <anastasiac> what I'm wondering about that case is this:
[16:12:01 CDT(-0500)] <anastasiac> while this might not happen in other (i.e. non-cspace) contexts, what will happen in cspace is that the Repeatable component will be applied to markup that has already been autobound to a model using the renderer's autobinding
[16:12:38 CDT(-0500)] <anastasiac> I might be chasing shadows, but I'm wondering what will happen when the Repeatable component re-renders a portion of the ui, and then autobinds that to a portion of the model
[16:12:51 CDT(-0500)] <anastasiac> of course, as I type this, it sounds less and less like a problem to me
[16:13:09 CDT(-0500)] * clown_ (~clown@142.150.154.101) has joined #fluid-work
[16:13:12 CDT(-0500)] <anastasiac> but of course, I tend to ramble about things before I've thought them throught
[16:13:20 CDT(-0500)] <anastasiac> and I probably shouldn't do that
[16:13:26 CDT(-0500)] <Bosmon> Well... it may expose a bug in the renderer
[16:13:29 CDT(-0500)] * colinclark_ (~colin@142.150.154.101) has joined #fluid-work
[16:13:31 CDT(-0500)] <Bosmon> But if it does, we should then fix that
[16:13:41 CDT(-0500)] <anastasiac> or it might just work fine (fingers crossed)
[16:15:34 CDT(-0500)] <michelled> seems like through our rambling through this issue we have come up with a goal that wasn't originally thought of: to build a general 'Repeatable' component. I'm really excited about this
[16:16:06 CDT(-0500)] <anastasiac> so michelled, yura_: it sounds like our next step is to restart this process with this new goal in mind
[16:16:15 CDT(-0500)] <michelled> how about we break now and pick this up tomorrow - I think the sketching will look quite different and it will be so much easier to write tests for it
[16:16:53 CDT(-0500)] <yura_> michelled: sounds good
[16:19:42 CDT(-0500)] <anastasiac> so for the record (i.e. for the logbot, so that I can re-read this tomorrow):
[16:20:57 CDT(-0500)] <anastasiac> yura_ just voiced a concern about ensuring that the repeater adjusts the same model that the rest of the page is bound to - that would require that it work with the applier, we can't pass appliers as options to components, they have to be first-class parameters to the creator function
[16:21:40 CDT(-0500)] <anastasiac> and using the renderer decorators "args" parameter requires an explicit statement of the container, which doesn't work so well inside a repeated field (as we learned with our autocomplete component)
[16:27:24 CDT(-0500)] * Bosmon4 (~a@ucb-np1-136.colorado.edu) has joined #fluid-work
[16:32:13 CDT(-0500)] * Justin_o (~Justin@142.150.154.171) has left #fluid-work
[17:11:46 CDT(-0500)] * anastasiac (~team@142.150.154.193) has left #fluid-work
[17:24:15 CDT(-0500)] * elicochran (~elicochra@dhcp-169-229-212-15.LIPS.Berkeley.EDU) has joined #fluid-work
[17:50:29 CDT(-0500)] * athena (~athena@174-31-228-55.tukw.qwest.net) has joined #fluid-work
[17:52:17 CDT(-0500)] <athena> so colinclark, did you have any thoughts about using cutpoints w/ the pager?
[17:54:30 CDT(-0500)] <colinclark> oh, wow
[17:54:33 CDT(-0500)] <colinclark> totally slipped my mind
[17:57:27 CDT(-0500)] <colinclark> ok, so you're trying to customize the pager without putting rsf:ids on the markup?
[18:04:45 CDT(-0500)] <Bosmon> Hi athena - you would customise cutpoints using the "renderOptions" structure in the options
[18:05:11 CDT(-0500)] <athena> oops yes, sorry - would like to use css classes rather than fsf:ids
[18:05:17 CDT(-0500)] <athena> thanks!
[18:05:23 CDT(-0500)] <Bosmon> You can see a small example of the pager customising its own cutpoints on line 137 - although this is for the instance of the renderer used for page links, rather than the main table body
[18:05:30 CDT(-0500)] <athena> i'm transitioning some markup that's already using the renderer to use the pager
[18:05:31 CDT(-0500)] <Bosmon> But you can customise the main table body renderer in just the same way
[18:05:46 CDT(-0500)] <athena> line 137 of the pager code, i assume?
[18:06:35 CDT(-0500)] <athena> i have to say that i'm just so impressed that it was so easy to switch over to using non-table markup in the render-driven pager
[18:06:42 CDT(-0500)] <athena> i was kinda worried it wouldn't work or would be confusing
[18:09:39 CDT(-0500)] * jessm_ (~Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined #fluid-work
[18:46:08 CDT(-0500)] * Bosmon2 (~a@c-67-176-80-187.hsd1.co.comcast.net) has joined #fluid-work
[23:55:33 CDT(-0500)] * athena (~athena@c-76-121-97-221.hsd1.wa.comcast.net) has joined #fluid-work