fluid-work IRC Logs-2009-10-01

Owned by Fluid IRC Log Bot
Last updated: Oct 01, 2009Version comment
16 min read

[07:27:52 EDT(-0400)] * heidi_ (n=thesumme@bas5-oshawa95-1176457717.dsl.bell.ca) has joined #fluid-work
[08:28:37 EDT(-0400)] * laurel (n=Laurel@142.150.154.178) has joined #fluid-work
[08:32:11 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[08:45:03 EDT(-0400)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[08:54:21 EDT(-0400)] * Bosmo1 (n=Bosmon@c-24-8-184-141.hsd1.co.comcast.net) has joined #fluid-work
[08:54:49 EDT(-0400)] <Bosmo1> Hello, am I here?
[08:55:04 EDT(-0400)] <Justin_o> Bosmo1: yes
[08:55:14 EDT(-0400)] <Bosmo1> Justin_o: did you happen to still have the sample code around that provoked FLUID-2980?
[08:55:37 EDT(-0400)] <Justin_o> Bosmo1: hello... i was just reading your comment on the jira
[08:58:28 EDT(-0400)] <Justin_o> Bosmo1: I've left some code commented out that uses it
[08:58:40 EDT(-0400)] <Bosmo1> ah cool
[08:58:53 EDT(-0400)] <Justin_o> if you go to the engage space in svn and look in components>browse>js>browse.js
[08:58:59 EDT(-0400)] <Bosmo1> thanks
[08:59:30 EDT(-0400)] <Justin_o> i've implemented a work around so you might have to ditch some of that code to see it working... please let me know if it was just my use of the code... i could have done something in correct
[09:15:29 EDT(-0400)] * anastasiac (n=team@142.150.154.189) has joined #fluid-work
[09:20:19 EDT(-0400)] * yura (n=yura@142.150.82.120) has joined #fluid-work
[09:26:53 EDT(-0400)] * jamon (i=jamon@mantis.openject.com) has joined #fluid-work
[09:39:44 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.164) has joined #fluid-work
[09:54:28 EDT(-0400)] * EricDalquist (n=EricDalq@static-210-59.vpn.wisc.edu) has joined #fluid-work
[09:55:11 EDT(-0400)] * clown (n=clown@142.150.154.101) has joined #fluid-work
[10:12:55 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined #fluid-work
[10:15:29 EDT(-0400)] * athena (i=4824784e@gateway/web/freenode/x-xedtqwckbqzojznv) has joined #fluid-work
[10:20:52 EDT(-0400)] <fj4000> jessm: ping
[10:23:38 EDT(-0400)] <jessm> fj4000: pong
[10:23:57 EDT(-0400)] <fj4000> any hope for 3218 getting into bug parade?
[10:26:22 EDT(-0400)] <jessm> fj4000: it's a style change to the iphone theme?
[10:26:51 EDT(-0400)] <fj4000> its a style change to Tags and Description components when using the (default) iphone theme
[10:27:07 EDT(-0400)] <fj4000> they otherwise have no basic styles
[10:28:11 EDT(-0400)] <jessm> fj4000: my sense is that we have a lot of unresolved issues still for Bug parade and that this one might be better kept for after release – what are your thoughts? I'm working on an assumption that the status of issues in the emails i'm sending out reflects the actual status of work – in other words, there seems like a lot of work already on bug parade
[10:28:51 EDT(-0400)] <jessm> what's your sense?
[10:29:56 EDT(-0400)] <fj4000> ok...but the work for this issue is already complete (so it would just need to be committed and reviewed)....so im not sure if there is any real benefit to not including it (tongue)
[10:30:42 EDT(-0400)] <jessm> fj4000: doh, just reading that email (smile)
[10:30:47 EDT(-0400)] <fj4000> (tongue)
[10:30:58 EDT(-0400)] <jessm> fj4000: i'll add it – sorry for my long-windedness (smile)
[10:31:04 EDT(-0400)] <fj4000> noooooooo problem
[10:31:18 EDT(-0400)] <fj4000> Justin_o said he could review it asap
[10:31:52 EDT(-0400)] <jessm> fj4000: so, i'm adding FLUID-3218 and putting it up for review
[10:32:10 EDT(-0400)] <fj4000> i just need to commit it, then I could ping the list for review
[10:32:18 EDT(-0400)] <fj4000> but please add it, yes
[10:35:33 EDT(-0400)] <jessm> fj4000: oops, just sent it out for in review – no biggie
[10:35:41 EDT(-0400)] <fj4000> jessm: so im going to commit my work for 3218 then
[10:35:48 EDT(-0400)] <jessm> fj4000: roger that
[10:37:14 EDT(-0400)] <fj4000> ok, Justin_o its ready for review if you are!
[10:40:05 EDT(-0400)] <Justin_o> fj4000: okay
[10:40:28 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[10:50:36 EDT(-0400)] * jgarciavila (n=quassel@213.96.26.120) has joined #fluid-work
[10:51:13 EDT(-0400)] <michelled> colinclark, Bosmo1, Justin_o, yura: did you want to have that kettle conversation today?
[10:51:28 EDT(-0400)] <colinclark> Which Kettle conversation in particular?
[10:51:44 EDT(-0400)] <michelled> a general overview
[10:52:14 EDT(-0400)] <colinclark> I'm wondering if it's something we need? Or whether we're in decent shape to keep-as jessm would say-"making sausage."
[10:52:22 EDT(-0400)] <michelled> I thought I'd figured out what I needed yesterday but it's not working
[10:52:23 EDT(-0400)] <colinclark> Veggie sausage, in my case. (tongue)
[10:52:30 EDT(-0400)] <colinclark> michelled: What's up?
[10:52:58 EDT(-0400)] <colinclark> We can screenshare if it would be easier for you to explain that way
[10:52:58 EDT(-0400)] <jgarciavila> 3121
[10:54:23 EDT(-0400)] <michelled> colinclark, yes, that would be good
[10:54:34 EDT(-0400)] <michelled> jgarciavila is just asking me about the 3121 issue
[10:54:42 EDT(-0400)] <colinclark> ok
[10:54:48 EDT(-0400)] <michelled> colinclark, do you know how he can reproduce the error?
[10:54:51 EDT(-0400)] <colinclark> call me whenever you're ready to chat, michelled
[10:56:11 EDT(-0400)] <colinclark> jgarciavila, michelled: Here's a key part of the bug report from Chris Hubick...
[10:56:16 EDT(-0400)] <colinclark> "Yet if I call fluid.reorderLayout = function(container, userOptions) to create my reorderer, supplying the first argument as a selector string, when the reorder later tries to create the model to serialize and post to my afterMoveCallbackUrl, it will explode inside fluid.getId = function (element) because fluid.moduleLayout.layoutToIds = function(idLayout) used to create the model calls fluid.getId(idLayout.container) when the idLayout.container va
[10:56:16 EDT(-0400)] <colinclark> been initialized to the given selector string, and not an element as required by getId."
[10:56:20 EDT(-0400)] <colinclark> That's in the JIRA.
[10:56:32 EDT(-0400)] <jgarciavila> I read that at the jira post
[10:56:50 EDT(-0400)] <colinclark> So we'll have to create a test page that creates a Layout Reorderer using a selector
[10:57:17 EDT(-0400)] <jgarciavila> Have we got some test who could reproduce this bug?. It so, could you address to file (files) involved?
[10:57:24 EDT(-0400)] <colinclark> And then it looks like we should get the error when the afterMove event is fired.
[10:57:39 EDT(-0400)] <colinclark> jgarciavila: We don't have a test to reproduce it. We'll need to create one.
[10:57:59 EDT(-0400)] <colinclark> You should be able to use the Layout Reorderer demo as a base for creating a simple test page.
[10:58:12 EDT(-0400)] <jgarciavila> that sounds great, i'll do that.
[10:58:32 EDT(-0400)] <colinclark> http://build.fluidproject.org/infusion/demos/reorderer/layoutReorderer/demo.html
[10:58:43 EDT(-0400)] <colinclark> That source code is also the demos/ folder in the Infusion source tree
[10:58:58 EDT(-0400)] <colinclark> It looks like you'll have to specify an afterMoveCallbackUrl property to make it all happen
[10:59:10 EDT(-0400)] <colinclark> thanks jgarciavila!
[10:59:18 EDT(-0400)] <colinclark> Sorry we don't have a test case for this already
[10:59:18 EDT(-0400)] <jgarciavila> thanks
[10:59:24 EDT(-0400)] <colinclark> It's a fairly new bug
[11:00:33 EDT(-0400)] <jgarciavila> no problem.
[11:01:35 EDT(-0400)] <jgarciavila> today i posted the patch to the patch for my first jira. Aptana placed tabs (i have changed Aptana configuration to place spaces).
[11:02:51 EDT(-0400)] <jgarciavila> colin, is there any reason to use iso-8859-1? Why don't we generalize utf-8 charset usage?
[11:06:27 EDT(-0400)] <colinclark> jgarciavila: So your latest FLUID-3197 patch has tabs in it, rather than spaces?
[11:08:05 EDT(-0400)] <jgarciavila> no. spaces like the rest of the javascript includes.
[11:08:39 EDT(-0400)] <colinclark> ah, great
[11:09:11 EDT(-0400)] <jgarciavila> did you read my question about charset?
[11:09:41 EDT(-0400)] <colinclark> yes
[11:09:43 EDT(-0400)] <colinclark> hang on one sec, sorry
[11:09:47 EDT(-0400)] <colinclark> i'm slightly distracted
[11:09:49 EDT(-0400)] <colinclark> (smile)
[11:10:17 EDT(-0400)] <jgarciavila> no problem.
[11:10:33 EDT(-0400)] <laurel> fyi - I put this page on the wiki this week, which is some hints about aptana settings http://wiki.fluidproject.org/display/fluid/Aptana+%28Eclipse%29+settings+for+coding+conventions
[11:10:43 EDT(-0400)] <jgarciavila> thanks
[11:10:52 EDT(-0400)] <laurel> we could add to it for things like char encoding
[11:11:39 EDT(-0400)] <laurel> i always find it hard to remember where to find those aptana settings on a re-install of aptana (which happens way too often in my life)
[11:12:05 EDT(-0400)] <colinclark> ok, jgarciavila, sorry about that
[11:12:22 EDT(-0400)] <colinclark> So your charset question: you're specifically referring to HTML pages, right?
[11:12:34 EDT(-0400)] <jgarciavila> encodings can become a problem when you peek data from remote systems? and also in multi-languaje webapps too.
[11:12:41 EDT(-0400)] <colinclark> For sure
[11:12:59 EDT(-0400)] <jgarciavila> yes, pages, data, xml, etc...
[11:13:26 EDT(-0400)] <colinclark> It seems that many of our HTML pages are indeed declared as UTF-8, but some aren't.
[11:13:41 EDT(-0400)] <colinclark> I'm wondering if perhaps someone's default settings are for ISO-8859-1?
[11:14:04 EDT(-0400)] <colinclark> I don't see any reason why everything shouldn't be encoded as UTF-8, but let me think about it for a minute.
[11:14:07 EDT(-0400)] <jgarciavila> aptana: window > preferences > General > Workspace (encoding)
[11:14:15 EDT(-0400)] <colinclark> Good to know
[11:14:18 EDT(-0400)] <colinclark> fj4000: Can you do me a favour
[11:14:28 EDT(-0400)] <fj4000> yesssssssssssss
[11:14:35 EDT(-0400)] <colinclark> Can you go into your Aptana settings as jgarciavila mentioned.
[11:14:41 EDT(-0400)] <colinclark> And tell me what encoding you've got set?
[11:14:44 EDT(-0400)] <fj4000> ok
[11:16:17 EDT(-0400)] <jgarciavila> mine other (UTF-8). Most of the demo pages have ... <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
[11:17:33 EDT(-0400)] <jgarciavila> old linux and unixes used this encoding as the default installation one. But html5 specifitacion recomends UTF-8 or microsoft ones [cp-1252]. The other are optional.
[11:17:34 EDT(-0400)] <fj4000> encoding = UTF-8
[11:17:37 EDT(-0400)] <colinclark> jgarciavila: Yeah, that's interesting... fj4000 created most of them.
[11:17:42 EDT(-0400)] <fj4000> line delimiters = UNIX
[11:18:03 EDT(-0400)] <colinclark> My encoding is set to UTF-8, and I haven't adjust the defaults.
[11:18:19 EDT(-0400)] <jgarciavila> Newer ones use UTF-8 as the default.
[11:18:39 EDT(-0400)] <colinclark> I went and looked at several of the component pages, and they're correctly set to UTF-8, jgarciavila.
[11:19:07 EDT(-0400)] <colinclark> There must be another setting
[11:19:39 EDT(-0400)] <colinclark> It looks like there's a template for new HTML files that is defaulting to ISO-8859-1
[11:19:48 EDT(-0400)] <jgarciavila> I was talking about the demo pages
[11:19:57 EDT(-0400)] <jgarciavila> fluid-all/infusion/src/webapp/demos/fss/mobile/demo.html for an example
[11:20:06 EDT(-0400)] <colinclark> jgarciavila: Ah! fj4000 just pointed it out to me.
[11:21:19 EDT(-0400)] <colinclark> one sec, sorry
[11:21:48 EDT(-0400)] <colinclark> So the default template for HTML files in Aptana looks like this:
[11:23:08 EDT(-0400)] <colinclark> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
[11:23:52 EDT(-0400)] <colinclark> So we all need to go into the Aptana > Editors > HTML preference and change the default template to charset=UTF-8
[11:24:26 EDT(-0400)] <jgarciavila> i suppose that it is an old template
[11:27:26 EDT(-0400)] <colinclark> yeah
[11:27:42 EDT(-0400)] <colinclark> HTML 3.2 didn't support UTF-8, but anything beyond does.
[11:27:51 EDT(-0400)] <jgarciavila> fixed in my aptana
[11:28:38 EDT(-0400)] <colinclark> I'm updating Laurel's page to include these instructions
[11:30:01 EDT(-0400)] <jgarciavila> great
[11:31:20 EDT(-0400)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[11:32:09 EDT(-0400)] * EricDalquist1 (n=EricDalq@static-210-59.vpn.wisc.edu) has joined #fluid-work
[11:44:14 EDT(-0400)] * elicochran (n=elicochr@dhcp-169-229-212-36.LIPS.Berkeley.EDU) has joined #fluid-work
[11:49:55 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[11:50:46 EDT(-0400)] <jessm> fj4000: i think the email i sent was based on an older email you sent, so i believe 3218 has been appropriately added to bug parade
[11:50:48 EDT(-0400)] <jessm> tell me if not
[11:51:29 EDT(-0400)] <colinclark> jgarciavila: You were asking about xml2json in Connect?
[11:51:35 EDT(-0400)] <colinclark> Do you want to ask your question again here?
[11:51:45 EDT(-0400)] <jgarciavila> yes. in kettle?
[11:52:12 EDT(-0400)] <colinclark> I'm trying to remember... was xml2json the plugin that David Trelles was examining?
[11:52:17 EDT(-0400)] <colinclark> We did a large comparison of techinques.
[11:52:38 EDT(-0400)] <colinclark> In the end, we settled on a Java-based XML Pull Parser that is as fast as anything we've seen in any language.
[11:52:50 EDT(-0400)] <jgarciavila> I've seen it as source inside kettle code.
[11:52:52 EDT(-0400)] <colinclark> yura uses it for importing XML data from McCord into Couch DB in JSON format
[11:53:10 EDT(-0400)] <colinclark> jgarciavila: Cool. It's there for the comparison pages. We'll remove some of that cruft for this Engage 0.1 release.
[11:53:30 EDT(-0400)] <jgarciavila> Does support xms namespaces?
[11:53:38 EDT(-0400)] <jgarciavila> Does support xml schema namespaces?
[11:53:40 EDT(-0400)] <colinclark> In Engage 0.3, we'll polish up our Import code a fair bit and build a Web-based UI for it, so museums can easily upload their data files and get them into Engage.
[11:53:50 EDT(-0400)] <colinclark> jgarciavila: I assume so, but I don't know. Perhaps yura or Bosmo1 know.
[11:54:36 EDT(-0400)] <jgarciavila> Did you considered xml data as data model (for the components)?
[11:57:01 EDT(-0400)] <Justin_o> jessm, colinclark: just realized that the 12th is a holiday any issues with making a slight change to release... so instead of 12 to 14, we make it 13 to 15
[11:57:46 EDT(-0400)] <jgarciavila> colin: working on my first assigned task i noticed that sometimes (depending on how fast the browser parser the ajax response) tabs where displayed in wrong other.
[11:58:15 EDT(-0400)] <jessm> Justin_o: the date changes looks good
[11:58:31 EDT(-0400)] <jgarciavila> colin: other times (in debug with aptana) there where tabs that did not loaded fine.
[12:00:50 EDT(-0400)] <Justin_o> jessm thanks... i'll send out an update to fluid-work
[12:04:23 EDT(-0400)] <colinclark> hey jgarciavila, sorry, I was distracted again. Just catching up.
[12:09:53 EDT(-0400)] <jgarciavila> colin: no problem.
[12:11:31 EDT(-0400)] <jgarciavila> colin: the way that demo pages used to load ajax resources is the "standart" ?
[12:13:41 EDT(-0400)] <jgarciavila> colin: I say that because i've seen this problem previously with more that one asynchrous ajax call in parallel. Sometimes you get failures. and i used to play with retries.
[12:15:08 EDT(-0400)] * hubick (n=hubick@cs14.pc.athabascau.ca) has joined #fluid-work
[12:16:41 EDT(-0400)] <hubick> jgarciavila: let me know if you need any clarification on #FLUID-3121 (which I reported)
[12:20:12 EDT(-0400)] <jgarciavila> hi hubick. today collin told me to create a page for reproduce the problem and latter fix it. And maybe also create a test too. (smile)
[12:22:08 EDT(-0400)] <colinclark> hubick: It should be as simple as creating a Layout Reorderer, specifying its container as a selector, and also specifying an afterMoveCallbackUrl. At that point, when the Reorderer tries to post back to the server, it'll explode.
[12:22:18 EDT(-0400)] <hubick> jgarciavila: i got the email from the issue being assigned. I tried to be exhaustively clear in the description (smile) I don't know if you need a callback URL, you should just be able to call fluid.moduleLayout.layoutToIds and have it explode
[12:22:32 EDT(-0400)] <colinclark> hubick: Your report was awesomely exhaustive.
[12:22:52 EDT(-0400)] <jgarciavila> yes
[12:23:25 EDT(-0400)] <hubick> my only worry would be that, supplying afterMoveCallbackUrl would require a server for it to call
[12:23:34 EDT(-0400)] <hubick> it should explode before that
[12:23:47 EDT(-0400)] <colinclark> yep, you're right. even a file:// url should work for that
[12:24:00 EDT(-0400)] <hubick> but if you want a test case which should work when the problem is fixed, having something for it to post to would be hard
[12:24:20 EDT(-0400)] <hubick> colinclark: ahh, it will post to a file url?
[12:24:26 EDT(-0400)] <colinclark> yeah, it'll post
[12:24:34 EDT(-0400)] <colinclark> it won't actually do anything, though (wink)
[12:24:51 EDT(-0400)] <hubick> It' won't?? FLUID SUCKS.
[12:24:56 EDT(-0400)] <colinclark> lol
[12:24:59 EDT(-0400)] <hubick> heh
[12:25:22 EDT(-0400)] <hubick> no, that's cool that it's smart enough to do that, makes test cases easier
[12:25:44 EDT(-0400)] <hubick> I actually just finished implementing the server side of my reorderer last night!
[12:26:04 EDT(-0400)] <hubick> finding a Java JSON parser wasn't hard
[12:26:40 EDT(-0400)] <hubick> it was determining the algorithm needed to compare the model the DB had with what I got from the JSON... ie figuring out "what happened"
[12:26:44 EDT(-0400)] <jgarciavila> bye
[12:27:59 EDT(-0400)] <hubick> after some thought, i determined that the way to tell what moved was just look at each item in the model, and if both neighbors had changed, that was the thing which moved.
[12:29:21 EDT(-0400)] * jgarciavila (n=quassel@213.96.26.120) has joined #fluid-work
[12:31:53 EDT(-0400)] <colinclark> makes sense
[12:32:25 EDT(-0400)] <Justin_o> jessm: just a quick update... I've code reviewed and tested FLUID-3218 for fj4000. There is a minor issue with how one of the styles used by description is displayed. So I've reopened FLUID-3218 and commented on it. I'll re-review it after fj4000 makes another fix for this.
[12:32:46 EDT(-0400)] <fj4000> thanks Justin_o
[12:35:55 EDT(-0400)] <jessm> Justin_o: thanks
[13:04:38 EDT(-0400)] <Bosmo1> I just wanted to paste a few bits from a recent private chat to Justin about my work on FLUID-2980 here to immortalise them
[13:04:45 EDT(-0400)] <colinclark> ok
[13:05:16 EDT(-0400)] <Bosmo1> As you may recall, this is an issue relating to failure to honour "fluid" decorators under some conditions, which turned out to be the cases where the renderer is invoked recursively
[13:05:51 EDT(-0400)] <Bosmo1> This is now possible, not to say almost certain to occur, now we have a richer and richer set of components which not only invoke other components but also render markup using the renderer with which to attach them
[13:06:16 EDT(-0400)] <Bosmo1> And this turns out to be related to work that needed to be done anyway under FLUID-2962 to make the renderer ready for use on the server-side -
[13:07:01 EDT(-0400)] <Bosmo1> It was "well-known" that the renderer code was not re-entrant, but in a single-threaded, non-recursive client world of 2008 (practically in the last century) we were much more concerned about performance (tongue)
[13:07:43 EDT(-0400)] <Bosmo1> So, I am refactoring fluidRenderer.js to include a "giant stateful closure" surrounding the main renderer invocation, but this is a little awkward in a few unexpected ways:
[13:08:04 EDT(-0400)] <Bosmo1> (17:58:21) Antranig: I guess we never documented the contract for "fluid.renderTemplates"
[13:08:04 EDT(-0400)] <Bosmo1> (17:58:25) Antranig: Which is just as well (tongue)
[13:08:04 EDT(-0400)] <Bosmo1> (17:58:32) Justin Obara: (tongue)
[13:08:04 EDT(-0400)] <Bosmo1> (17:59:05) Antranig: Ah, it seems we did...
[13:08:04 EDT(-0400)] <Bosmo1> (17:59:07) Antranig: That is awkward
[13:08:05 EDT(-0400)] <Bosmo1> (18:00:04) Justin Obara: oh ... so this would involve an api change, and the api has been documented... that may be problematic
[13:08:08 EDT(-0400)] <Bosmo1> (18:00:08) Justin Obara: for this release anyways
[13:08:10 EDT(-0400)] <Bosmo1> (18:00:10) Antranig: Yes
[13:08:17 EDT(-0400)] <Bosmo1> (18:00:21) Antranig: I will see if I can think of a way of fixing the issue whilst remaining compatible...
[13:08:17 EDT(-0400)] <Bosmo1> (18:00:49) Antranig: But the renderTemplates API was clearly always crap anyway
[13:08:17 EDT(-0400)] <Bosmo1> (18:00:56) Antranig: I mean, look at the "fossilsIn" parameter (tongue)
[13:08:18 EDT(-0400)] <Bosmo1> (18:01:49) Justin Obara: (smile) this sounds a bit like it is leading towards that refactoring of renderer, although i guess that was more about component trees
[13:08:21 EDT(-0400)] <Bosmo1> (18:02:13) Antranig: Well... it is sort of unclear whether the renderer should actually be turned into a "that"
[13:08:24 EDT(-0400)] <Bosmo1> (18:02:22) Antranig: But it was actually written some time before we learned of "that-ism"
[13:08:26 EDT(-0400)] <Bosmo1> (18:02:38) Antranig: And also at a time when we were far more obsessed by performance on crappy browsers than we are now
[13:08:29 EDT(-0400)] <Bosmo1> (18:02:44) Antranig: Not that we don't still have a JIRA open about IE6 (tongue)
[13:09:04 EDT(-0400)] <Bosmo1> As it turns out, fluid.renderTemplates is sort of dangerously functionally incomplete, as well as being a crap API
[13:09:24 EDT(-0400)] <Bosmo1> Since as it stands, if you use it, there is no way to get the processing of decorators honoured - it was also an API written before the time we had any decorators
[13:09:48 EDT(-0400)] <Bosmo1> Now, decorator processing is also a highly interesting forward-looking issue, since in different contexts, the actual mechanism of honouring them may well be extremely different
[13:10:13 EDT(-0400)] <Bosmo1> The current implementation can only deal with the most "simple-minded" case, that is, when the markup rendered by the renderer has been dumped directly into the current document
[13:10:29 EDT(-0400)] <colinclark> Bosmo1: I still fear that we're not in a position to break APIs in this release. Especially this late in the game.
[13:10:47 EDT(-0400)] <colinclark> So assuming you decide that it's the only way to fix the issue, what's the consequence of not fixing it?
[13:10:50 EDT(-0400)] <Bosmo1> Now, the API contract of the other renderer driving methods is clearly capable of a little more than that already now, given there is an options parameter which allows you to specify an alternate document
[13:11:12 EDT(-0400)] <Bosmo1> But as it stands, that configuratoin would not be honoured by the default decorator mechanism
[13:11:18 EDT(-0400)] <colinclark> I'm looking for something along the spectrum of inconvenience and doom.
[13:11:33 EDT(-0400)] <Bosmo1> Looking further ahead on the server, you can imagine even more interesting and productive ways of honouring decorators
[13:11:46 EDT(-0400)] <Bosmo1> We always imagined a scheme for somehow "bottling" them and squirting them onto the client to be later honoured there
[13:11:58 EDT(-0400)] <Bosmo1> Anyway, yes, I am trying to see if I can think of a "useful" point on this spectrum
[13:12:28 EDT(-0400)] <Bosmo1> And think of a way of resolving our immediate problems without painting ourselves further into a corner with respect to future API design
[13:12:42 EDT(-0400)] <Bosmo1> We can't really change the return type of fluid.renderTemplates
[13:13:11 EDT(-0400)] <colinclark> Yeah
[13:13:25 EDT(-0400)] <Bosmo1> Unfortunately it needs to continue to return a string....
[13:14:43 EDT(-0400)] <Bosmo1> ok
[13:14:48 EDT(-0400)] <Bosmo1> I think I have an idea..
[13:19:07 EDT(-0400)] <colinclark> ok
[13:20:20 EDT(-0400)] <Bosmo1> Gah
[13:20:34 EDT(-0400)] <Bosmo1> It is quite ridiculous the stuff we wrote, before we had a Framework (tongue)
[13:24:47 EDT(-0400)] <Bosmo1> OK
[13:24:54 EDT(-0400)] <Bosmo1> I think I have done it... all the tests seem to pass...
[13:25:10 EDT(-0400)] <Bosmo1> It would make a pretty ridiculous patch, so I am thinking I might just commit it?
[13:44:18 EDT(-0400)] <colinclark> Bosmo1: Yeah, go ahead and commit it
[13:44:25 EDT(-0400)] <colinclark> I'll review it later today or tomorrow morning
[13:49:42 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined #fluid-work
[13:55:36 EDT(-0400)] <Bosmo1> Cool thanks
[14:21:56 EDT(-0400)] <laurel> colinclark, jessm: I've just finished checking in the fixes for the code reviews for 3157. I think I've touched every issue discussed yesterday in the review.
[14:22:12 EDT(-0400)] <colinclark> laurel: Excellent. I'll add it to my list of reviews
[14:30:14 EDT(-0400)] <athena> Bosmo1: i made a ticket for that issue i'd emailed you about: http://issues.fluidproject.org/browse/FLUID-3219
[14:38:38 EDT(-0400)] <laurel> fj4000: I posted a patch for build.properties in http://issues.fluidproject.org/browse/FLUID-3215 - this contains the small text changes you requested for the builder
[14:38:57 EDT(-0400)] <fj4000> thanks so much
[15:06:43 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[15:09:19 EDT(-0400)] <yura> jessm: hi Jess, i think this one is good for review
[15:09:20 EDT(-0400)] <yura> http://issues.fluidproject.org/browse/ENGAGE-91
[15:09:32 EDT(-0400)] <jessm> yura: ok, thanks
[16:01:17 EDT(-0400)] <fj4000> Hey everyone: could someone review my commit for 3202? Its for testing the demo portal ajax calls when running in FF and off the local filesystem
[16:01:17 EDT(-0400)] <anastasiac> Justin_o, jessm: I've just resolved FLUID-3209, the new Renderer portal demo. Colin reviewed an earlier revision, but it might benefit from one last review before being closed.
[16:02:01 EDT(-0400)] <anastasiac> fj4000, when and if 3209 gets closed, the demo portal could probably be updated to point to the new renderer demo
[16:02:14 EDT(-0400)] <fj4000> jessm: I've resolved 3202, will review anastasiac's commit
[16:02:34 EDT(-0400)] <fj4000> looking for a review as well
[16:02:37 EDT(-0400)] <jessm> so, 3202 is reviewed and closed?
[16:03:00 EDT(-0400)] <fj4000> no, i just resolved it - hopefully someone could review and close it?
[16:03:33 EDT(-0400)] <jessm> k
[16:03:36 EDT(-0400)] <fj4000> anastasiac: i'll scratch your back and you could do mine? (wink)
[16:03:58 EDT(-0400)] <anastasiac> fj4000, I'll have a look
[16:04:05 EDT(-0400)] <fj4000> thanks
[16:05:00 EDT(-0400)] <jessm> Justin_o: have a look at the latest email – tell me what you think re: it's near end of day Thursday
[16:07:56 EDT(-0400)] <anastasiac> fj4000, what's a good way to replicate 3202?
[16:08:19 EDT(-0400)] <fj4000> using FF 3+, view the uploader demo or the ui options demo
[16:08:28 EDT(-0400)] <fj4000> oh
[16:08:57 EDT(-0400)] <anastasiac> ah - check it out to a new folder...
[16:08:59 EDT(-0400)] <fj4000> and ensure you havent turned off the same orgin policy wrning
[16:09:07 EDT(-0400)] <fj4000> sure
[16:09:15 EDT(-0400)] <anastasiac> how do you "turn of the same origin policy warning?
[16:09:24 EDT(-0400)] <fj4000> excelllent (wink)
[16:09:53 EDT(-0400)] <fj4000> http://kb.mozillazine.org/Security.fileuri.strict_origin_policy
[16:10:01 EDT(-0400)] <fj4000> this needs to be set to TRUE
[16:10:07 EDT(-0400)] <fj4000> as is the default
[16:14:58 EDT(-0400)] <fj4000> anastasiac: commented on 3209
[16:15:26 EDT(-0400)] <anastasiac> fj4000, I'm sorry - I'm doing a few things at once - could you translate that link into something I can understand? I vaguely remember that I have to go to some weird 'about' page, or something?
[16:15:34 EDT(-0400)] <fj4000> ?
[16:15:39 EDT(-0400)] <fj4000> you mean the comment?
[16:15:54 EDT(-0400)] <fj4000> or the security stuff?
[16:16:30 EDT(-0400)] <anastasiac> what do I have to do to set or unset my browser?
[16:17:02 EDT(-0400)] <fj4000> for the security thing, type about:config in FF
[16:17:10 EDT(-0400)] <fj4000> then look for the field called
[16:17:19 EDT(-0400)] <fj4000> security.fileuri.strict_origin_policy
[16:17:28 EDT(-0400)] <fj4000> make sure its set to TRUE
[16:17:33 EDT(-0400)] <anastasiac> ah!
[16:17:37 EDT(-0400)] <anastasiac> right! thanks so much
[16:17:39 EDT(-0400)] <fj4000> (smile)
[16:19:39 EDT(-0400)] <fj4000> anastasiac: ping
[16:19:53 EDT(-0400)] * anastasiac is freaked out
[16:20:09 EDT(-0400)] <fj4000> did you swallow the red pill?
[16:20:20 EDT(-0400)] <jessm> don't cut the blue wire!
[16:20:37 EDT(-0400)] <anastasiac> oh, I am way down the rabbit hole...
[16:20:44 EDT(-0400)] <anastasiac> I'm going to quit and return...
[16:20:47 EDT(-0400)] * anastasiac (n=team@142.150.154.189) has left #fluid-work
[16:20:58 EDT(-0400)] * anastasiac (n=team@142.150.154.189) has joined #fluid-work
[16:21:15 EDT(-0400)] <anastasiac> note to all: don't click on that "about" link fj4000 posted!!
[16:21:54 EDT(-0400)] <fj4000> http://www.yooouuutuuube.com/v/?rows=18&amp;cols=18&amp;id=pAwR6w2TgxY&amp;startZoom=1
[16:22:03 EDT(-0400)] <fj4000> enjoy that one folks
[16:24:13 EDT(-0400)] <jessm> fj4000: it's 3-d
[16:24:14 EDT(-0400)] <jessm> cool
[16:25:36 EDT(-0400)] <anastasiac> so the fix to 3202 doesn't work in my 3.0.14 firefox... sorry...
[16:25:46 EDT(-0400)] <anastasiac> fj4000, jessm: ^
[16:26:00 EDT(-0400)] <fj4000> yeah, it seems 3 handles everything differently from 3.5
[16:26:04 EDT(-0400)] <fj4000> this is nutz
[16:26:22 EDT(-0400)] <fj4000> ok, so the bug should be reopened
[16:27:20 EDT(-0400)] <fj4000> another bit of bliss: http://www.yooouuutuuube.com/v/?rows=18&amp;cols=18&amp;id=pAwR6w2TgxY&amp;startZoom=1
[16:27:25 EDT(-0400)] <fj4000> ach!!
[16:27:27 EDT(-0400)] <fj4000> wrong link
[16:28:24 EDT(-0400)] <fj4000> http://www.albinoblacksheep.com/flash/llama
[16:28:31 EDT(-0400)] <fj4000> thats the one
[16:36:37 EDT(-0400)] <fj4000> ok anastasiac, i committed the fixes
[16:36:46 EDT(-0400)] <fj4000> pls have a look and close it if you're happy
[16:36:59 EDT(-0400)] <fj4000> or, if you're happy and you know it, you can just clap your hands
[16:37:00 EDT(-0400)] <anastasiac> will do - I renamed that data file, please have another look at 3209
[16:37:09 EDT(-0400)] <fj4000> ok
[16:40:19 EDT(-0400)] <fj4000> 3209 looks great - but if your pretty printing function moved to the JS file, i think it would be better
[16:43:55 EDT(-0400)] <fj4000> once the include path is fixed, it should be good to go
[16:44:59 EDT(-0400)] <anastasiac> fj4000, try an update on 3209 again. I've moved the code out of the data file, and fixed that bad path
[16:45:18 EDT(-0400)] <fj4000> ok
[16:46:18 EDT(-0400)] <fj4000> looks great, i think i can close it
[16:47:53 EDT(-0400)] <anastasiac> ok, Justin_o and jessm, I've reviewed FLUID-3202, and it looks good. I've closed it.
[16:49:37 EDT(-0400)] <fj4000> jessm: 3209 reviewed and closed
[16:49:50 EDT(-0400)] <fj4000> anastasiac: thanks
[16:49:59 EDT(-0400)] <anastasiac> np
[16:53:31 EDT(-0400)] * laurel (n=Laurel@142.150.154.178) has left #fluid-work
[17:02:40 EDT(-0400)] * anastasiac (n=team@142.150.154.189) has left #fluid-work
[17:46:24 EDT(-0400)] * clown (n=clown@142.150.154.101) has left #fluid-work
[17:57:44 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[20:32:59 EDT(-0400)] * Bosmon (n=Bosmon@rtr-trident.wireless.indra.com) has joined #fluid-work
[23:13:12 EDT(-0400)] * jamon (i=jamon@mantis.openject.com) has joined #fluid-work