fluid-work IRC Logs-2009-12-17

[04:10:32 EST(-0500)] * sveto (n=sveto@95.111.16.213) has joined #fluid-work
[04:13:32 EST(-0500)] * Bosmon2 (n=amb26fre@97-118-7-119.hlrn.qwest.net) has joined #fluid-work
[04:14:49 EST(-0500)] * sveto_ (n=sveto@62.44.108.2) has joined #fluid-work
[04:19:31 EST(-0500)] * sveto (n=sveto@95.111.16.213) has joined #fluid-work
[05:03:14 EST(-0500)] * sveto (n=sveto@95.111.16.213) has joined #fluid-work
[06:25:31 EST(-0500)] * sveto (n=sveto@95.111.16.213) has left #fluid-work
[06:55:55 EST(-0500)] * boyan1 (n=boyan@95.111.16.213) has joined #fluid-work
[07:02:17 EST(-0500)] * joan2 (n=jgarci@173.Red-88-21-180.staticIP.rima-tde.net) has joined #fluid-work
[07:02:26 EST(-0500)] * joan2 (n=jgarci@173.Red-88-21-180.staticIP.rima-tde.net) has left #fluid-work
[08:02:42 EST(-0500)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[08:27:31 EST(-0500)] * apetro (n=apetro@64.134.234.118) has joined #fluid-work
[08:28:59 EST(-0500)] * laurel1 (n=Laurel@142.150.154.178) has joined #fluid-work
[08:40:08 EST(-0500)] * sveto (n=sveto@95.111.16.213) has joined #fluid-work
[08:55:18 EST(-0500)] * anastasiac (n=team@142.150.154.189) has joined #fluid-work
[09:11:24 EST(-0500)] * jimeng (n=jimeng@adsl-68-79-92-158.dsl.sfldmi.ameritech.net) has joined #fluid-work
[09:12:39 EST(-0500)] * jameswy (n=jameswy@142.150.154.196) has joined #fluid-work
[09:12:48 EST(-0500)] <jimeng> I come bearing holiday cheeriness and questions about the fluid renderer.
[09:13:51 EST(-0500)] * yura (n=yura@142.150.154.170) has joined #fluid-work
[09:14:37 EST(-0500)] <Justin_o> jimeng: Happy Holidays, not sure I can help with your question, but I can give it a try
[09:14:57 EST(-0500)] <jimeng> Thanks, Justin.
[09:16:08 EST(-0500)] <jimeng> We are rendering a table and we need to insert two kinds of rows. One type has six columns and the other has a column that spans six columns.
[09:16:38 EST(-0500)] <jimeng> The rows generally alternate
[09:17:44 EST(-0500)] <Justin_o> hmm... interesting..
[09:17:48 EST(-0500)] <jimeng> We have a row of each type in the template and then we add components to the component tree to represent each row.
[09:18:25 EST(-0500)] <jimeng> But when it is rendered, all of one type of row gets rendered first and then all of the other type of row gets rendered
[09:18:36 EST(-0500)] <jimeng> Instead of alternating
[09:18:49 EST(-0500)] <Justin_o> jimeng: do you have any code that you could show me?
[09:18:57 EST(-0500)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined #fluid-work
[09:20:13 EST(-0500)] <jimeng> Give me a couple minutes
[09:21:27 EST(-0500)] <Justin_o> jimeng: sure
[09:24:00 EST(-0500)] <sveto> Hi, Justin_o, I'm having two different problems with my collection view and for at least one of them I'm out of ideas
[09:24:31 EST(-0500)] <Justin_o> sveto: hello.. sorry i haven't had a chance to look over your code yet... but what seems to be the problem that you are having
[09:24:33 EST(-0500)] <jimeng> Here's a snippet from the template: http://pastie.org/747140
[09:27:40 EST(-0500)] <jimeng> Here's the rendering code: http://pastie.org/747144
[09:28:10 EST(-0500)] <jimeng> That is preceded by some code to build the component tree
[09:29:35 EST(-0500)] <sveto> Justin_o: the first one is that in the reorderer I try to have selectables differ from movables (movables are <li>s and selectables are <a>s nested inside the <li>s). so I get a client side exception - "thatReorderer.activeItem is undefined" at line 359 of Reorderer.js... I tried to trace the problem and the only thing I understood is that for some reason the click event associated with the selectable is not invoked (which if it was would cause a focus eve
[09:29:35 EST(-0500)] <sveto> thatReorderer.activeItem will have a valid value. I'll wait till you finish with jimeng (smile)
[09:29:47 EST(-0500)] <jimeng> The important part is that in building the component tree, we alternate adding rows on the two types. I'll send a snippet showing how each type is added
[09:29:47 EST(-0500)] <Justin_o> jimeng: actually do you have that bit that generates the component tree
[09:31:27 EST(-0500)] <Justin_o> jimeng, sveto: I have to got to some mandatory training at the moment, but I think it should be done in a half hour or less....
[09:32:39 EST(-0500)] <jimeng> The code to build the component tree: http://pastie.org/747151
[09:33:02 EST(-0500)] <jimeng> Thanks, Justin. Will be back shortly
[09:33:03 EST(-0500)] * apetro (n=apetro@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[09:42:06 EST(-0500)] <jimeng> There's a lot of irrelevant detail in the convertResourceItem() function. The key thing is that the convertTree() function returns an array of objects. That's the component tree. If I look at that array in firebug, I see that the objects alternate.
[09:42:08 EST(-0500)] <jimeng> [Object ID=resource-item: decorators=Object children=[8], Object ID=resource-item-desc: decorators=Object, Object ID=resource-item: decorators=Object children=[8], 43 more... 0=Object 1=Object 2=Object 3=Object 4=Object 5=Object]
[09:42:51 EST(-0500)] <jimeng> The first one has an ID of "resource-item:" and the next one has an ID of "resource-item-desc:".
[09:43:02 EST(-0500)] <jimeng> And they keep alternating like that
[09:44:13 EST(-0500)] <jimeng> But when the page is rendered, the "resource-item:" rows all come first and the "resource-item-desc:" rows come last.
[09:44:28 EST(-0500)] * michelled (n=michelle@142.150.154.193) has joined #fluid-work
[09:58:52 EST(-0500)] * colinclark (n=colin@142.150.154.130) has joined #fluid-work
[10:04:17 EST(-0500)] * fj4000 (n=Jacob@142.150.154.164) has joined #fluid-work
[10:08:39 EST(-0500)] * clown (n=clown@142.150.154.101) has joined #fluid-work
[10:12:43 EST(-0500)] * apetro_ (n=apetro@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[10:16:03 EST(-0500)] * athena (n=athena@adsl-75-58-124-106.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[10:20:19 EST(-0500)] <Justin_o> jimeng: hmm... i'm thinking about this and i think this may be expected behaviour.. basically the position in the tree isn't necessarily important if they are on the same level (depth). the ":" is specifying that the element is repeating inside of the container in the order that is specified in the template
[10:20:56 EST(-0500)] <Justin_o> I think what you need is something above the two table rows that would repeat and the table rows themselves wouldn't
[10:21:04 EST(-0500)] <Justin_o> not sure how this would work with a table though
[10:23:18 EST(-0500)] <jimeng> Here's another possibility: Maybe the template has a row with seven td elements – six for the six-column row and one for the one column row. Then the rows are rendered with children matching either the six columns or the one column
[10:23:45 EST(-0500)] <jimeng> I will try that and see if it works
[10:29:51 EST(-0500)] <Justin_o> jimeng: also wondering what you are using the table for. if it is just for visual effect or something we may be able to do it with some other markup...
[10:32:31 EST(-0500)] * colinclark_ (n=colin@142.150.154.101) has joined #fluid-work
[10:32:35 EST(-0500)] <laurel1> Justin_o: http://issues.fluidproject.org/browse/FLUID-3429 - line 104 end tag for </a> is not there
[10:35:18 EST(-0500)] <Justin_o> michelled: http://issues.fluidproject.org/browse/FLUID-3438
[10:35:27 EST(-0500)] <Justin_o> That's the unit test bug thing
[10:35:48 EST(-0500)] <michelled> thx
[10:50:31 EST(-0500)] <jimeng> justin_o: The approach I mentioned above works
[10:50:43 EST(-0500)] <Justin_o> jimeng: okay... great.. glad it worked
[10:51:25 EST(-0500)] <jimeng> justin_o: We are using a table partly for visual effect, but also because the data is tabular
[10:51:53 EST(-0500)] <jimeng> But we are breaking the tabular nature of it by adding descriptions in separate rows
[10:52:26 EST(-0500)] <jimeng> I will mention that to Gonzalo, who designed the page
[10:54:50 EST(-0500)] <Justin_o> jimeng: okay... thanks... let me know if you come across anything else
[10:54:57 EST(-0500)] <Justin_o> sveto: sorry... what was your question again
[10:55:06 EST(-0500)] <jimeng> Thanks for your help
[10:55:36 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:55:53 EST(-0500)] * andreauoc (n=carlos@120.Red-213-96-26.staticIP.rima-tde.net) has joined #fluid-work
[10:56:09 EST(-0500)] <sveto> Justin_o: no problem - I was asking if it is possible (and if there are such test scenarios) to separate the movables from the selectables in reorderer
[10:56:54 EST(-0500)] <sveto> I ran into a problem that the selected item is not getting the focus and causing an error in Reorderer.js
[10:57:00 EST(-0500)] <Justin_o> sveto: hmm... you should be able to have selectables that aren't movable, but i don't think the inverse is true
[10:57:33 EST(-0500)] <sveto> well that's what I'm trying to do - have the lis movable and the as selectable
[10:58:01 EST(-0500)] <sveto> ah, you mean that the lis should be selectables too?
[10:58:44 EST(-0500)] <sveto> that's what I'm trying to avoid - it makes an ugly selection box stay around the li once moving is done
[11:00:00 EST(-0500)] <Justin_o> hmm.... so what are you trying to move again... can you send me a screen shot or something to help me visualize it
[11:00:07 EST(-0500)] <Justin_o> sveto: ^
[11:02:06 EST(-0500)] <sveto> Justin_o: just a second
[11:03:58 EST(-0500)] <sveto> Justin_o: sent it over the icq
[11:04:31 EST(-0500)] <sveto> you can see that there is a selection box around the first artifact, the one that has just been moved
[11:09:27 EST(-0500)] <Justin_o> fj4000: jameswy found this issue, and it is now a blocker for the release, http://issues.fluidproject.org/browse/FLUID-3440
[11:10:51 EST(-0500)] <jessm> Justin_o: fj4000: jameswy: really?
[11:11:16 EST(-0500)] <jameswy> Apparently so.
[11:11:41 EST(-0500)] <jameswy> fj4000 already fixed it though. Just needs to commit it.
[11:12:29 EST(-0500)] <fj4000> already done (smile)
[11:12:35 EST(-0500)] <jessm> jameswy: fj4000: cool
[11:13:23 EST(-0500)] <Justin_o> sveto: so i'm looking at the screenshot... so what you want is focus to only be on the thumbnail?
[11:15:57 EST(-0500)] <sveto> Justin_o: yes
[11:16:18 EST(-0500)] <Justin_o> fj4000: do you have any thoughts about this issue that sveto is having
[11:16:37 EST(-0500)] <fj4000> this is for the iphone, right?
[11:16:48 EST(-0500)] <Justin_o> fj4000: it is for fluid engage
[11:17:01 EST(-0500)] <fj4000> :focus isnt used on that platform anyways
[11:17:37 EST(-0500)] <fj4000> so you'll need to use a class name (which I think you will get anyways when you use the reorderer) on your dragging element, and use that to reference the thumbnail within it
[11:18:28 EST(-0500)] <Justin_o> fj4000, sveto: just checked in with jameswy. So we will have a desktop version of this that will use a grid but will probably look a bit different. So i'm not sure if this will be an issue there or not
[11:19:06 EST(-0500)] <fj4000> either way, your class name on the dragging element can be used to change the style of the thumbnail too
[11:19:33 EST(-0500)] <fj4000> so lets say your draggable el is called ".drag" and the thumbnail within it is ".thumb"
[11:19:40 EST(-0500)] <fj4000> you could say
[11:19:50 EST(-0500)]

<fj4000> .drag

Unknown macro: {outline}

[11:20:07 EST(-0500)]

<fj4000> and .drag .thumb

Unknown macro: {outline}

[11:20:16 EST(-0500)] <sveto> fj4000: thanks, I'll try it now
[11:20:41 EST(-0500)] <fj4000> cool, please let me know if it works
[11:24:46 EST(-0500)] <sveto> fj4000: it worked, but unveiled a problem with the thumbs - they seem to be cropped, this way the outline is shown on only 3 of the sides...
[11:25:07 EST(-0500)] <sveto> fj4000: but for now this solves my problem
[11:26:23 EST(-0500)] <fj4000> the thumbnails need to be handled with max-height and max-width, I think
[11:26:41 EST(-0500)] <fj4000> while this wont work on IE6, at least the effect will be there for all the other browsers
[11:26:58 EST(-0500)] <fj4000> so IE6 wont get much, but other browsers will have a nice effect
[11:29:14 EST(-0500)] * elicochran (n=elicochr@dhcp-169-229-212-53.LIPS.Berkeley.EDU) has joined #fluid-work
[11:48:44 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[11:53:31 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[11:56:31 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[11:57:25 EST(-0500)] * apetro- (n=apetro@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[11:59:12 EST(-0500)] * apetro-_ (n=apetro@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[12:04:15 EST(-0500)] * apetro-- (n=apetro@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[12:05:48 EST(-0500)] <Justin_o> michelled: could you please review FLUID-3438
[12:08:06 EST(-0500)] * boyan1 (n=boyan@95.111.16.213) has joined #fluid-work
[12:18:56 EST(-0500)] * sveto (n=sveto@95.111.16.213) has left #fluid-work
[12:20:32 EST(-0500)] <colinclark> jameswy: I was just wandering through JIRA. You filed this one: http://issues.fluidproject.org/browse/FLUID-3433
[12:20:53 EST(-0500)] <colinclark> Can you elaborate on it? It has no description, so I wasn't sure what your rationale was. It sounds like a nice idea, but I'm not entirely sure why. (wink)
[12:52:28 EST(-0500)] <andreauoc> hey... i just had some problems with the connection here & got kicked out of the developer's meeting... could anybody tell me the link to the couchdb server in order to replicate and import it on my computer pls?
[12:55:05 EST(-0500)] <laurel1> Justin_o: http://issues.fluidproject.org/browse/FLUID-3424 - alison thought we should fix the alt test and validation errors before release...this fell off the radar late last week
[12:55:28 EST(-0500)] <laurel1> text not test
[12:55:48 EST(-0500)] <Justin_o> andreauoc: http://titan.atrc.utoronto.ca:5984/_utils/
[12:55:50 EST(-0500)] <colinclark> yura: When you get a chance, can you respond to andreauoc's question? I know you're in a meeting at the moment.
[12:55:57 EST(-0500)] <colinclark> ah, thanks, Justin_o
[12:56:20 EST(-0500)] <andreauoc> thanks a lot justin
[12:56:39 EST(-0500)] <laurel1> fj4000: did you fix this?
[12:56:40 EST(-0500)] <laurel1> http://issues.fluidproject.org/browse/FLUID-3254
[12:57:00 EST(-0500)] <yura> hi andrea, this is the link: http://titan.atrc.utoronto.ca:5984/ , for ui version http://titan.atrc.utoronto.ca:5984/_utils
[12:57:46 EST(-0500)] <yura> andreauoc: tools->replicator will be useful
[12:57:46 EST(-0500)] <andreauoc> thanks yura
[12:57:52 EST(-0500)] <yura> andreauoc: np
[12:59:02 EST(-0500)] <Justin_o> laurel1: hmm.. i think the alt tags may be the biggest issue.
[12:59:17 EST(-0500)] <laurel1> i agree
[13:01:09 EST(-0500)] <jameswy> colinclark: Ah, yes. So, the problem as I see is that I download two completely different builds of Infusion for whatever reason, but both are downloaded as "infusion-1.1.2.zip". So, on my end, days later, I'm trying to find my Fluid Infusion download, but I see two files that are similarly named (infusion-1.1.2.zip, infusion-1.1.2 (2).zip), and from where I'm standing, they should be exactly the same file that I just accidentally downloaded twice.
[13:03:20 EST(-0500)] <colinclark> jameswy: Good description. Can you imagine a naming scheme that would be informative?
[13:03:37 EST(-0500)] <michelled> Justin_o: 3438 is reviewed and closed
[13:05:18 EST(-0500)] <jameswy> colinclark: Not off the top of my head, (smile). I'll think about it!
[13:05:43 EST(-0500)] <colinclark> jameswy: thanks. if anything comes to you, just comment on the JIRA. I'll update it with your comment here
[13:13:10 EST(-0500)] <jameswy> colinclark: Will do.
[13:20:31 EST(-0500)] <Justin_o> colinclark and others: seems we have a problem with the buttons but only in NVDA
[13:20:54 EST(-0500)] <Justin_o> basically there is a span inside that holds the text, but this text isn't read by NVDA, but is by JAWS
[13:39:17 EST(-0500)] <Justin_o> laurel1: http://www.weba11y.com/Examples/connectionsInvite.html
[14:18:24 EST(-0500)] * clown (n=clown@142.150.154.101) has left #fluid-work
[14:39:58 EST(-0500)] <Justin_o> jamon: do you know if anything strange is happening to the server where the infusion builder is being built
[14:40:19 EST(-0500)] <Justin_o> i'm noticing periodically that we are getting the wrong set of data back from the server and a php error
[14:40:27 EST(-0500)] <Justin_o> also got a 404 error once
[14:51:46 EST(-0500)] <jamon> Justin_o: looking at the log i see this:
[14:51:47 EST(-0500)] <jamon> [Thu Dec 17 14:50:02 2009] [error] [client 142.150.154.101] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace
[14:52:02 EST(-0500)] <jamon> looks like there's an htaccess redirect or something that is failing
[14:52:33 EST(-0500)] * anastasiac (n=team@142.150.154.189) has left #fluid-work
[14:53:31 EST(-0500)] <Justin_o> jamon: thanks... i'll have to check in with colin and laurel about that
[14:53:41 EST(-0500)] <jamon> ok cool Justin_o
[15:37:16 EST(-0500)] * Lee_bee (n=UXExpert@d142-058-198-190.surrey.sfu.ca) has joined #fluid-work
[16:27:55 EST(-0500)] * apetro_ (n=apetro@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[16:43:41 EST(-0500)] * Lee_bee (n=UXExpert@d142-058-198-190.surrey.sfu.ca) has joined #fluid-work
[16:54:22 EST(-0500)] * Bosmon (n=Bosmon@eccr224-158-dhcp.colorado.edu) has joined #fluid-work
[18:50:58 EST(-0500)] * Lee_bee (n=UXExpert@d142-058-198-190.surrey.sfu.ca) has joined #fluid-work
[21:39:37 EST(-0500)] * yura (n=yura@bas3-toronto06-2925099889.dsl.bell.ca) has joined #fluid-work
[22:42:50 EST(-0500)] * elicochran (n=elicochr@adsl-70-137-166-175.dsl.snfc21.sbcglobal.net) has joined #fluid-work