fluid-work IRC Logs-2009-07-23
- Fluid IRC Log Bot
[08:23:30 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work <colinclark> (function ($) )(); <Justin_o> colinclark: when you have something specified in the defaults such as tinyMCE: <Justin_o> and then pass in the options tinyMCE: <colinclark> ; <Justin_o> i seem to be getting back , i wonder if I'm doing something wrong...
[08:32:18 EDT(-0400)] * anastasiac (n=team@142.150.154.189) has joined #fluid-work
[08:35:35 EDT(-0400)] * laurel (n=Laurel@142.150.154.178) has joined #fluid-work
[09:20:40 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined #fluid-work
[09:23:54 EDT(-0400)] * jsilvaa (n=jsilva@142.150.82.73) has joined #fluid-work
[09:27:54 EDT(-0400)] * yura (n=yura@142.150.82.114) has joined #fluid-work
[09:30:06 EDT(-0400)] * alisonbenjamin (n=alisonbe@142.150.154.101) has joined #fluid-work
[09:51:59 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined #fluid-work
[09:53:42 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176130925.dsl.bell.ca) has joined #fluid-work
[09:55:13 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176130925.dsl.bell.ca) has joined #fluid-work
[09:55:38 EDT(-0400)] <colinclark> anastasiac, Justin_o: hey
[09:55:47 EDT(-0400)] <Justin_o> colinclark: hello
[09:56:07 EDT(-0400)] <Justin_o> colinclark: anastasiac is on a call
[09:56:11 EDT(-0400)] <colinclark> k
[09:56:28 EDT(-0400)] <colinclark> I think I've fixed the failing daily Uploader server build.
[09:56:46 EDT(-0400)] <Justin_o> really... that's good... what was the problem
[09:56:48 EDT(-0400)] <colinclark> That code depends on the Sakai master maven file to build itself...
[09:56:59 EDT(-0400)] <colinclark> The error message was actually fairly explanatory...
[09:57:12 EDT(-0400)] <colinclark> Our build script was depending on version "M2" of Sakai's master build.
[09:57:33 EDT(-0400)] <colinclark> They upgraded their version number to something a bit more sensible, so Maven was failing, unable to find it.
[09:57:46 EDT(-0400)] <colinclark> I updated our pom to the correct version--"2.7.0-SNAPSHOT"
[09:57:54 EDT(-0400)] <colinclark> This'll probably change in the future as Sakai updates their build.
[09:58:20 EDT(-0400)] <Justin_o> ah so it is something that we'll have to keep updating.... is there a way around that
[09:58:24 EDT(-0400)] <colinclark> I'm tempted to grab a copy of the master folder and commit it directly alongside the image-gallery infrastructure directory.
[09:58:33 EDT(-0400)] <colinclark> Then we can basically freeze it where it is now.
[09:58:50 EDT(-0400)] <Justin_o> right... because we don't need the latest version
[09:58:58 EDT(-0400)] <colinclark> yep
[09:59:10 EDT(-0400)] <colinclark> ...if it ain't broke...
[09:59:20 EDT(-0400)] <colinclark> perhaps i'll just go ahead and do that now
[09:59:45 EDT(-0400)] <Justin_o> that will save us a headache in the future when we have forgotten about this
[09:59:53 EDT(-0400)] <colinclark> Yep
[10:00:03 EDT(-0400)] <colinclark> Right now we pull in master directly from Sakai's repo as an external
[10:00:09 EDT(-0400)] <colinclark> Meaning it's changing underneath us.
[10:00:21 EDT(-0400)] <colinclark> Honestly, I still really want to just port this thing to Kettle and be done with all the complex dependencies.
[10:00:57 EDT(-0400)] <colinclark> Now that Berkeley has abandoned the code base, it's just unnecessary for our purposes. Originally, it was cool because UCB was building a whole new Sakai tool around Fluid components. But then they dropped it for various reasons.
[10:01:09 EDT(-0400)] <colinclark> That's the history of this Image Gallery 2 thing that we use for testing our Uploader.
[10:01:27 EDT(-0400)] <Justin_o> oh i see...
[10:01:32 EDT(-0400)] <colinclark> Whereas we could do something super-simple with Kettle that let you just upload file and then see the results.
[10:02:17 EDT(-0400)] <Justin_o> That would be nice then it could also serve as a simple kettle demo
[10:05:39 EDT(-0400)] <colinclark> exactly
[10:05:46 EDT(-0400)] <colinclark> something to put on our list for some day 
[10:07:30 EDT(-0400)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[10:10:49 EDT(-0400)] * Topic is 'Proposal for Engage's Services Layer Technologies. Please read it and share your thoughts! http://bit.ly/1MncEf' set by colinclark on 2009-07-23 10:10:49 EDT(-0400)
[10:11:14 EDT(-0400)] * colinclark wonders if that was subtle enough.
[10:11:16 EDT(-0400)] <colinclark> 
[10:13:49 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined #fluid-work
[10:37:48 EDT(-0400)] * yura (n=yura@142.150.82.114) has joined #fluid-work
[10:45:53 EDT(-0400)] <anastasiac> colinclark, just caught up on your fix to the Uploader server build - thanks! good catch. I should have pondered the error message more closely...
[10:46:05 EDT(-0400)] <colinclark> anastasiac: cool
[10:46:26 EDT(-0400)] <colinclark> I just Googled the error message, and a little write-up by Anthony Whyte about something indirectly related was enough to trigger it all.
[10:46:41 EDT(-0400)] <colinclark> I'm just in the process of "freezing" master into our repository now... so we never have to do this again.
[10:46:54 EDT(-0400)] <anastasiac> yes, good idea
[10:59:36 EDT(-0400)] * everettz (n=chatzill@bas4-ottawa23-1177561437.dsl.bell.ca) has joined #fluid-work
[11:00:16 EDT(-0400)] <everettz> colinclark: Can you point me to resources for a11y and JQuery UI?
[11:00:57 EDT(-0400)] <colinclark> everettz: I hear you've caught the jQuery bug.
[11:01:03 EDT(-0400)] <colinclark> Here are a couple of starting points:
[11:01:04 EDT(-0400)] <everettz> e.g. how accessible different widgets are currently. I may need to work on improving JQuery UI accessibility
[11:01:13 EDT(-0400)] <colinclark> http://fluidproject.org/blog/2009/07/09/keyboard-accessibility-for-jquery-and-infusion/
[11:01:21 EDT(-0400)] <colinclark> That's an overview of keyboard navigation in jQuery.
[11:02:09 EDT(-0400)] <colinclark> Here's a thread on the jQuery-a11y where a few of these questions come up: http://groups.google.com/group/jquery-a11y/browse_thread/thread/8ae6368f18c83628#
[11:02:23 EDT(-0400)] <everettz> yep, I was avoiding it, but d7 has JQuery UI as a core module and uses some inaccessible widgets (drag-and-drop).
[11:02:56 EDT(-0400)] <colinclark> This Paciello Group blog has a list of the widgets that are currently accessible in jQuery UI: http://www.paciellogroup.com/blog/?p=313
[11:03:33 EDT(-0400)] <everettz> you have just saved me much work.
[11:03:38 EDT(-0400)] <colinclark> Drag and drop is indeed inaccessible in jQuery UI. I don't know that anyone has immediately plans to add ARIA or keyboard support to it. As you know, it's a hard problem and something we struggled with for the Reorderer.
[11:03:58 EDT(-0400)] <colinclark> At this point, I honestly just think people should use Reorderer instead of jQuery UI drag and drop, though I imagine very few do at this point.
[11:03:58 EDT(-0400)] <everettz> I have plans
[11:04:02 EDT(-0400)] <colinclark> Awesome.
[11:04:05 EDT(-0400)] <colinclark> Glad I could help.
[11:04:16 EDT(-0400)] <colinclark> Oh, one other thing, everettz
[11:04:34 EDT(-0400)] <colinclark> Alison is working on a patch that adds ARIA support to the jQuery UI Slider.
[11:04:42 EDT(-0400)] <colinclark> That's coming very soon.
[11:04:45 EDT(-0400)] <everettz> Only palnning because it will be easier to convince the d7 community to improve JQuery UI a11y than to rip out the current drag-n-drop functionality and replace it with something else.
[11:04:56 EDT(-0400)] <colinclark> yep, understandable
[11:05:27 EDT(-0400)] <everettz> yes, I think I've tested her slider
[11:05:31 EDT(-0400)] <colinclark> cool
[11:05:47 EDT(-0400)] <everettz> alright, off to bang my head against a wall. Thanks again.
[11:06:08 EDT(-0400)] * everettz (n=chatzill@bas4-ottawa23-1177561437.dsl.bell.ca) has left #fluid-work
[11:15:11 EDT(-0400)] * clown (n=clown@129.33.193.22) has joined #fluid-work
[11:15:21 EDT(-0400)] * clown (n=clown@129.33.193.22) has left #fluid-work
[11:17:12 EDT(-0400)] <Justin_o> colinclark: yura has a fix for that tinyMCE inline edit issue
[11:17:42 EDT(-0400)] <colinclark> Justin_o, yura !
[11:17:42 EDT(-0400)] <colinclark> cool
[11:18:30 EDT(-0400)] <Justin_o> colinclark: one question... are we still planning on distributing the jQuery.tinyMCE plugin
[11:18:42 EDT(-0400)] <colinclark> i guess it depends on what the fix looks like
[11:18:53 EDT(-0400)] <colinclark> ideally, we'd be able to roll the fix into the plugin
[11:19:43 EDT(-0400)] <Justin_o> yura: maybe you could tell colinclark about the fix, and if it is possible to move it into the plugin as well
[11:20:45 EDT(-0400)] <yura> well the problem with the plugin was that it was priming the editor to simple theme once, so it would fail if the theme was different for one of the editors on the page
[11:20:55 EDT(-0400)] <colinclark> yep
[11:21:37 EDT(-0400)] <yura> so, to leave it in the plugin we would have to call the "priming" function for each editor when we know the theme
[11:22:04 EDT(-0400)] <colinclark> do you have a patch or anything i can see?
[11:22:18 EDT(-0400)] <colinclark> it sounds to me like you've found a way to prime tiny on a per-editor basis
[11:22:39 EDT(-0400)] <colinclark> whereas, when i slapped together that plugin, i was under the impression that tiny needed to be primed immediately--like within the head if possible
[11:22:39 EDT(-0400)] <yura> one sec, ill find the issue
[11:23:06 EDT(-0400)] <yura> http://issues.fluidproject.org/browse/FLUID-3054
[11:23:30 EDT(-0400)] <yura> the patch primes it in fluid.initEditor.tinyMCE
[11:24:24 EDT(-0400)] <yura> but Im sure
[11:24:33 EDT(-0400)] <yura> it could address to the plugin
[11:24:44 EDT(-0400)] <colinclark> ok, this is great
[11:24:46 EDT(-0400)] <colinclark> nice work, yura
[11:24:54 EDT(-0400)] <colinclark> try this, for curiosity's sake
[11:25:06 EDT(-0400)] <colinclark> change the api for the plugin to take an options object
[11:25:10 EDT(-0400)] <colinclark> containing the settings for tinymce
[11:25:25 EDT(-0400)] <yura> ya i was thinking to try that too
[11:25:28 EDT(-0400)] <colinclark> then init tiny within the call to $.tinymce
[11:25:35 EDT(-0400)] <colinclark> this plugin isn't very important
[11:25:38 EDT(-0400)] <colinclark> so we could just toss it
[11:25:50 EDT(-0400)] <colinclark> but it is nice to have some little useful jquery things people can use without all of infusion
[11:25:59 EDT(-0400)] <colinclark> and when i looked for a good tinymce plugin for jquery, they were all broken
[11:26:11 EDT(-0400)] <colinclark> so try moving the code there, and then we'll be all set
[11:26:20 EDT(-0400)] <colinclark> if it doesn't seem sensible, or you can't get it to work, we'll just toss the whole plugin
[11:26:24 EDT(-0400)] <colinclark> i'm definitely not wedded to it
[11:26:31 EDT(-0400)] <colinclark> especially since it does so little 
[11:27:26 EDT(-0400)] <yura> great, ill try then
[11:31:39 EDT(-0400)] <yura> yes it works
[11:37:03 EDT(-0400)] <yura> colinclark: Justin_o: quick question though, the plugin is wrapped into anonymous function that's being executed, since it only contains a definition of another function, does it have to be excuted?
[11:49:10 EDT(-0400)] <colinclark> yura: Do you mean the main closure?
[11:49:19 EDT(-0400)]
[11:49:31 EDT(-0400)] <yura> yes, I mean if it has to be executed
[11:55:02 EDT(-0400)] * yura (n=yura@142.150.82.114) has joined #fluid-work
[11:58:41 EDT(-0400)] * michelled_ (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[12:06:39 EDT(-0400)] <colinclark> yura: Yep, it should still be executed. It gives us a way of safely aliasing jQuery and also a private space to grow into. At the moment, the code seems so simple that it's probably not necessary, but we're better to follow the standard jQuery plugin pattern in case it does grow larger in the future.
[12:07:06 EDT(-0400)] <yura> ok
[12:07:08 EDT(-0400)] <yura> thanks
[12:26:08 EDT(-0400)] <yura> Justin_o: hey Justin, could you please review my updated patch : http://issues.fluidproject.org/browse/FLUID-3054
[12:26:26 EDT(-0400)] <Justin_o> yura sure
[12:31:01 EDT(-0400)] <Justin_o> yura: not sure if you still need to have the tinyMCE init inside of an if statement, now that you have to explicitly run the call $.tinymce for it to run
[12:37:48 EDT(-0400)] <yura> Justin_o: well it has to be primed for every editor, so I m pretty sure it still has to stay, I tried to remove it and it will fail on first try
[12:40:22 EDT(-0400)] <Justin_o> i mean in the plugin i think you can just do the init of tinyMCE the way you have it, instead of keeping the if(typeOf(tinyMCE) !== undefined
[12:41:05 EDT(-0400)] <Justin_o> that may have actually been more confusing... let me try again
[12:42:20 EDT(-0400)] <yura> so you are saying if statement is unnecessary ?
[12:42:27 EDT(-0400)] <Justin_o> yes
[12:43:13 EDT(-0400)] <Justin_o> before the $.fn.tinymce wasn't around the init function, so it had to make sure it was there before running.
[12:43:27 EDT(-0400)] <Justin_o> but now the user has to explicitly call it to do the priming
[12:43:31 EDT(-0400)] <colinclark> Justin_o: yep, that's a good point
[12:43:45 EDT(-0400)] <yura> oh right I understand now
[12:43:51 EDT(-0400)] <colinclark> we can now safely assume that if someone's going to use this function, they will have linked to TinyMCE as a dependency.
[12:44:14 EDT(-0400)] <colinclark> Whereas before, it assumed TinyMCE was present, even before someone bothered to invoke the plugin.
[12:49:29 EDT(-0400)] <yura> Justin_o: ok, I reattached the updated patch to the jura
[12:49:34 EDT(-0400)] <yura> jira*
[12:55:34 EDT(-0400)] <Justin_o> yura: i'm taking a look
[12:56:40 EDT(-0400)] <yura> Justin_o: thanks
[12:59:46 EDT(-0400)] <Justin_o> yura: it looks good
[13:00:05 EDT(-0400)] <Justin_o> i'm going to commit it unless you or colinclark have any other changes you'd like to make
[13:00:35 EDT(-0400)] <colinclark> gimme one more sec to review it
[13:00:45 EDT(-0400)] <Justin_o> colinclark: sure
[13:03:38 EDT(-0400)] <colinclark> hmm, i'm not sure this is quite right.
[13:03:40 EDT(-0400)] <colinclark> it's very close
[13:04:12 EDT(-0400)] <colinclark> check out the implementation of fluid.inlineEdit.tinyMCE.editModeRenderer
[13:05:27 EDT(-0400)] <colinclark> So to things come up:
[13:05:51 EDT(-0400)] <colinclark> 1. The options that we're passing to the TinyMCE plugin are the overall InlineEditor options, rather than the ones specifically destined for TinyMCE.
[13:06:17 EDT(-0400)] <colinclark> 2. We're already trying to prime TinyMCE even later in the game, perhaps making the call to $.tinymce completely irrelevant.
[13:06:45 EDT(-0400)] <colinclark> What happens if we just get rid of the line we added to fluid.inlineEdit.tinyMCE() where we call the plugin?
[13:06:49 EDT(-0400)] <colinclark> I would imagine it would still work?
[13:06:53 EDT(-0400)] <colinclark> Justin_o and yura: ?
[13:07:46 EDT(-0400)] <Justin_o> colinclark: I'll give it a test, but i think that we may get the case where it opens and closes... one second though and i'll let you know
[13:08:33 EDT(-0400)] <yura> ya that;s what happens
[13:08:42 EDT(-0400)] <colinclark> ok, so now i'm completely confused
[13:08:49 EDT(-0400)] <Justin_o> yep it opens and closes...
[13:09:04 EDT(-0400)] <colinclark> ok, so I think we're going to have to go a little deeper still.
[13:09:10 EDT(-0400)] <Justin_o> i wonder if we have to do it for each one or just for each type once..
[13:09:11 EDT(-0400)] <colinclark> or i'm completely missing something
[13:10:37 EDT(-0400)] <colinclark> Justin_o: Can you elaborate?
[13:10:39 EDT(-0400)] <Justin_o> colinclark: the other day when yura and I were looking at it... i believe it creates a tinyMCE that has not settings to start with if you just load tinyMCE from the CDN. The priming adds in the mode and theme which causes the settings to apapear
[13:11:14 EDT(-0400)] <yura> exactly , and it seems that it needs to be primed for each editor
[13:11:56 EDT(-0400)] <Justin_o> colinclark: in regards to my previous comment i was just playing with it and it seems to load the additional editors okay after one with the same style has been loaded... but i didn't really test it enough to be definitive on this
[13:14:58 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[13:15:35 EDT(-0400)] <yura> so it will also work if you dont call $.tinymce at all but you add same tinyMCE.init for the advanced them in the original plugin
[13:16:26 EDT(-0400)] <yura> so i guess priming just just the style seems to work
[13:18:45 EDT(-0400)] <colinclark> sorry, just catching up
[13:20:13 EDT(-0400)] <colinclark> i'm confused now
[13:20:31 EDT(-0400)] <colinclark> should we hop into breeze for a couple minutes and chat about it?
[13:20:37 EDT(-0400)] <yura> sure
[13:20:56 EDT(-0400)] <Justin_o> sure
[13:46:03 EDT(-0400)] * laurel (n=Laurel@142.150.154.178) has joined #fluid-work
[13:49:40 EDT(-0400)] <Justin_o> yura: any luck... currently I'm getting a broken inlineEdit when i call tinyMCE.init before returning inlineEditor in fluid.inlineEdit.tinyMCE
[13:50:58 EDT(-0400)] <yura> same thing, I just get an empty text box
[13:51:07 EDT(-0400)] <yura> Justin_o: ^
[13:51:48 EDT(-0400)] <colinclark> ah, yes
[13:51:51 EDT(-0400)] <colinclark> this is really interesting
[13:51:56 EDT(-0400)] <colinclark> so i think i could explain it
[13:52:14 EDT(-0400)] <colinclark> if you put back in the second to call to tinymce.init (in editModeRenderer), does it work?
[13:52:33 EDT(-0400)] <yura> it works if I add back the init in editModeRenderer
[13:52:44 EDT(-0400)] <yura> yes
[13:54:26 EDT(-0400)] <colinclark> ok
[13:54:26 EDT(-0400)] <colinclark> so
[13:54:28 EDT(-0400)] <colinclark> tinymce sucks
[13:54:29 EDT(-0400)] <colinclark>
[13:54:39 EDT(-0400)] <colinclark> it looks like we need to call init twice
[13:54:43 EDT(-0400)] <colinclark> we have been all along
[13:54:56 EDT(-0400)] <colinclark> and basically, if i remember correctly...
[13:55:09 EDT(-0400)] <colinclark> by default, tinymce goes wondering around the page when you call init() on it
[13:55:20 EDT(-0400)] <colinclark> and it looks for textareas (they need to have ids)
[13:55:29 EDT(-0400)] <colinclark> and it turns them "magically" into tinymce editors
[13:55:42 EDT(-0400)] <colinclark> so we have this problem that, upon creation of an inline editor, the text area doesn't yet exist
[13:56:23 EDT(-0400)] <colinclark> so it looks like we have to "prime" tiny, then run it again for each inline editor when its edit view is created
[13:56:57 EDT(-0400)] <colinclark> so it seems we're probably calling init() too frequently, but this at least works.
[13:58:26 EDT(-0400)] <colinclark> yura, Justin_o: I have no idea if I'm making any sense, or even correct.
[13:59:08 EDT(-0400)] <yura> yes, this seems to be the most appropriate way to prime it without the plugin
[14:00:31 EDT(-0400)] <colinclark> so, we're probably still priming it too frequently...
[14:00:52 EDT(-0400)] <colinclark> in that we could probably get away with calling init() once per configuration as early as possible (say, in the head)
[14:01:07 EDT(-0400)] <colinclark> but that early in the game, how could we know what sorts of tinymce configurations are on the page?
[14:04:09 EDT(-0400)] <Justin_o> this is tricky....
[14:06:31 EDT(-0400)] <colinclark> Assuming we just can't know, and we'll have to call init() more often than is necessary...
[14:06:38 EDT(-0400)] <colinclark> does what we have now work correctly?
[14:07:29 EDT(-0400)] <yura> yes, it seems to work
[14:09:39 EDT(-0400)] <colinclark> I guess this is at least an improvement.
[14:09:56 EDT(-0400)] <colinclark> Hey Justin_o, I guess my biggest curiosity would be if this has any sort of impact on performance, etc
[14:10:09 EDT(-0400)] <colinclark> IE 6 is always a nice way to check that out.
[14:10:26 EDT(-0400)] <Justin_o> ah sure... i can run this and check it out...
[14:10:32 EDT(-0400)] <colinclark> I'm thinking about susahosh's use case, where he may have dozens of elements that are editable
[14:10:57 EDT(-0400)] <colinclark> any while he'd only need to call it once to prime the page, we'd actually end up calling it dozens of times
[14:11:10 EDT(-0400)] <colinclark> i can live with it for now; it's a hard problem
[14:11:14 EDT(-0400)] <Justin_o> and if he is initing on each click it would be quite a lot
[14:11:22 EDT(-0400)] <colinclark> yep
[14:11:41 EDT(-0400)] <colinclark> might also be interesting to profile TinyMCE.init() in Firebug and see how deep and long an operation it is
[14:11:48 EDT(-0400)] <colinclark> obviously, run once, it'll be pretty trivial
[14:11:59 EDT(-0400)] <colinclark> but you can imagine what its impact could be by looking at it a bit
[14:15:50 EDT(-0400)] <Justin_o> okay... so i have reverted my code base to try out the current method which works fairly quick... i'm going to try this new method we discussed now
[14:16:02 EDT(-0400)] <colinclark> ok, cool
[14:16:05 EDT(-0400)] <colinclark> On another note, Justin_o, I think we should setup our new build server so that its local Maven repository is dropped on a regular basis. Perhaps even nighly, though this would significantly slow the time to do a build down.
[14:16:58 EDT(-0400)] <colinclark> But I can't shake this feeling that a lot of the mysteriousness of our Maven builds would go away if we weren't caching all our dependencies. If something critical changed, like this versioning of Sakai's master pom, things would just explicitly die.
[14:17:38 EDT(-0400)] <Justin_o> okay... i see
[14:18:39 EDT(-0400)] <Justin_o> i was playing with hudson a bit today but didn't really get to deep into it. I just setup a build using our ant script in the build-scripts directory
[14:19:02 EDT(-0400)] <colinclark> ah, cool
[14:19:06 EDT(-0400)] <colinclark> how did it go?
[14:23:50 EDT(-0400)] <Justin_o> it built successfully i wasn't quite sure where it was putting the file though so i coudn't see it, but i could view the console logs so it looked like it worked fine...
[14:25:45 EDT(-0400)] <EricDalquist> when our bamboo instance was working one of our nightly builds used a fresh maven repository
[14:25:56 EDT(-0400)] <EricDalquist> I think we did it via a maven option
[14:27:16 EDT(-0400)] <EricDalquist> so the bamboo Maven goal we had it running was "install -Dmaven.repo.local=local-repository"
[14:27:26 EDT(-0400)] <EricDalquist> which placed the maven repository in the temp build directory bamboo creates
[14:27:46 EDT(-0400)] <Justin_o> yura: when you were following along for this new method we were going to try... did it open the editor for you properly... i'm getting an empty text field
[14:27:56 EDT(-0400)] <Justin_o> sorry... textarea
[14:28:26 EDT(-0400)] <yura> really ?
[14:28:33 EDT(-0400)] <yura> it seems to be working for me
[14:28:43 EDT(-0400)] <Justin_o> i think i must have messed up the defaults 
[14:28:57 EDT(-0400)] <yura> did you leave tinyMCE.init(options); in fluid.inlineEdit.tinyMCE.editModeRenderer ?
[14:29:13 EDT(-0400)] <yura> i moved defaultoptions to fluid.defaults as well
[14:29:31 EDT(-0400)] <yura> and vat options = ... should look like this : var options = $.extend(true, fluid.defaults("fluid.inlineEdit.tinyMCE").tinyMCE, that.options.tinyMCE);
[14:31:51 EDT(-0400)] <colinclark> yura: you should be able to toss that line
[14:31:58 EDT(-0400)] <yura> Justin_o: it works but I am getting an error when opening other than the first editor
[14:32:08 EDT(-0400)] <colinclark> since the options will already be merged for you by the framework
[14:32:23 EDT(-0400)] <Justin_o> hmm... i had tried just assigning it to that.options.tinyMCE
[14:32:25 EDT(-0400)] <yura> oh ok , let me try
[14:35:02 EDT(-0400)]
[14:35:27 EDT(-0400)]
[14:35:49 EDT(-0400)] <Justin_o> what should options.tinyMCE contain?
[14:36:06 EDT(-0400)] <colinclark> hmm
[14:36:08 EDT(-0400)] <colinclark> good question
[14:36:16 EDT(-0400)] <colinclark> should merge the values
[14:36:27 EDT(-0400)] <colinclark> so i would expect this:
[14:36:44 EDT(-0400)]
[14:37:44 EDT(-0400)]
[14:39:10 EDT(-0400)] <colinclark> show me what you've got
[14:39:16 EDT(-0400)] <colinclark> pastebin is probably easiest
[14:41:07 EDT(-0400)] <Justin_o> http://fluid.pastebin.com/m70a34379
[14:43:07 EDT(-0400)] <colinclark> how are you specifying the width option?
[14:45:35 EDT(-0400)] <Justin_o> oh that is on the inlineEdit quickstart
[14:45:59 EDT(-0400)] <Justin_o> http://source.fluidproject.org/svn/fluid/infusion/trunk/src/webapp/standalone-demos/quick-start-examples/inlineEdit/js/InlineEdit-example.js
[14:46:25 EDT(-0400)] <colinclark> Justin_o: Ok
[14:46:46 EDT(-0400)] <colinclark> So you're saying that your options, after merging, are only showing the width property?
[14:48:31 EDT(-0400)] <Justin_o> seems to be... I'm getting just an empty text area... i tried doing a console log and it didn't show the mode or the theme
[14:59:28 EDT(-0400)] <colinclark> i'm baffled
[15:00:40 EDT(-0400)] <colinclark> Justin_o: ah
[15:00:43 EDT(-0400)] <colinclark> interesting
[15:00:48 EDT(-0400)] <colinclark> let me read through the code a bit more clearly
[15:01:17 EDT(-0400)] * yura (n=yura@142.150.82.114) has joined #fluid-work
[15:01:34 EDT(-0400)] <colinclark> i can't quite tell what antranig was doing with this component
[15:01:41 EDT(-0400)] <Justin_o> okay.... i've just been struggling with my debuggers to verify that it is being overwritten... and it is...
[15:01:50 EDT(-0400)] <colinclark> if you notice, there is another attempt at options merging in configureInlineEdit()
[15:02:21 EDT(-0400)] <colinclark> which makes sense
[15:02:22 EDT(-0400)] <Justin_o> the assembleOptions function
[15:02:29 EDT(-0400)] <colinclark> yep
[15:02:49 EDT(-0400)] <colinclark> can you do some debugger tracing?
[15:03:02 EDT(-0400)] <colinclark> check out what the options values are after line 26?
[15:05:12 EDT(-0400)] <Justin_o> colinclark: for tinyMCE it is just the width
[15:05:48 EDT(-0400)] <colinclark> ok, and using firebug's little hover-y feature...
[15:06:03 EDT(-0400)] <colinclark> what are the values for fluid.defaults(configurationName) and options on line 25?
[15:06:14 EDT(-0400)] <Justin_o> my firebug isn't working for me at the moment... it won't seem to break anywhere... so i'm using safari
[15:06:32 EDT(-0400)] <colinclark> yack
[15:07:46 EDT(-0400)] <Justin_o> configurationName: "fluid.inlineEdit.tinyMCE"
[15:08:10 EDT(-0400)] * yura (n=yura@142.150.82.114) has joined #fluid-work
[15:09:19 EDT(-0400)] <colinclark> but no value for the call to fluid.defaults() i guess
[15:09:27 EDT(-0400)] <colinclark> you can actually go hacking into the code...
[15:10:43 EDT(-0400)] <colinclark> temporarily rewrite it to assign the call to fluid.defaults() to a variable
[15:10:57 EDT(-0400)] <Justin_o> ah okay... good idea
[15:15:34 EDT(-0400)] <Justin_o> okay.... tinyMCE in the call to fluid.defaults has mode and theme
[15:17:52 EDT(-0400)] <colinclark> Justin_o: i'm doing a few things at once, so i'm gonna be slow to respond
[15:17:55 EDT(-0400)] <colinclark> but i will
[15:18:13 EDT(-0400)] <Justin_o> no problem... i'm actually going to head home now and do standup from there...
[15:18:40 EDT(-0400)] <yura> hey Justin_o I was retarting, so did you manage to get it run without fail?
[15:18:44 EDT(-0400)] <colinclark> ok
[15:19:06 EDT(-0400)] <Justin_o> yura: not yet i didn't
[15:20:19 EDT(-0400)] <colinclark> Justin_o, anastasiac: Uploader build should now be good and steady... no longer master from Sakai's (changing) repository, etc.
[15:20:33 EDT(-0400)] <Justin_o> colinclark: thanks
[15:20:40 EDT(-0400)] <Justin_o> so no more broken builds
[15:20:51 EDT(-0400)] <colinclark> hopefully not. we'll find out tomorrow morning
[15:22:09 EDT(-0400)] <Justin_o> i'll look forward to not having a build failure
[15:22:18 EDT(-0400)] <Justin_o> i'll be back online in a bit
[15:22:42 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has left #fluid-work
[15:57:57 EDT(-0400)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[16:04:44 EDT(-0400)] <colinclark> yura: Victory!
[16:05:01 EDT(-0400)] <colinclark> I have no idea if my changes have caused side effects, but I'll slap up a patch for you to review.
[16:05:30 EDT(-0400)] <yura> great
[16:05:49 EDT(-0400)] <yura> so what was the problem then?
[16:05:51 EDT(-0400)] <colinclark> Just one minor change to what Justin had in the pastebin... we merge options ahead of time--those specific to the TinyMCE version of InlineEdit before actually calling fluid.inlineEdit(), which makes sense...
[16:06:27 EDT(-0400)] <colinclark> but it was using $.extend() and it was doing a shallow copy, which is inconsistent with the semantics of how options are merged.... so we'll have to dome some fairly detailed QA, I think.
[16:06:36 EDT(-0400)] <colinclark> anyway, i'll just make a patch
[16:06:48 EDT(-0400)] <colinclark> code is worth a thousand words
[16:09:59 EDT(-0400)] <colinclark> yura: http://issues.fluidproject.org/browse/FLUID-3054
[16:11:52 EDT(-0400)] <yura> so you specify extend to be recursive
[16:12:28 EDT(-0400)] <colinclark> yura: yep, the first argument to extend()
[16:12:35 EDT(-0400)] <colinclark> I'm sort of thinking about it now...
[16:12:43 EDT(-0400)] <colinclark> So, hopefully this will make sense if I think out loud.
[16:13:02 EDT(-0400)] <colinclark> So fluid.inlineEdit.tinyMCE() isn't really a component in itself...
[16:13:07 EDT(-0400)] <colinclark> but users need not be aware of that.
[16:13:34 EDT(-0400)] <colinclark> This is a classic case where we've avoided the extra cruft of object inheritance by just making things configurable.
[16:13:58 EDT(-0400)] <colinclark> So inlineEdit.tinyMCE() is just a set of default options that extend the underlying component's default options.
[16:14:32 EDT(-0400)] <colinclark> So then, whatever means we use to merge options for that thing should be semantically identical to our component options merging policy...
[16:14:38 EDT(-0400)] <colinclark> which is implemented in fluid.mergeComponentOptions().
[16:15:00 EDT(-0400)] <colinclark> Interestingly, mergeComponentOptions() no longer uses $.extend() under the covers...
[16:15:17 EDT(-0400)] <colinclark> it used to, but subtle requirements emerged that required us to write our own implementation.
[16:15:49 EDT(-0400)] <colinclark> So, in order to genuinely merge options correctly, it seems we should always just use mergeComponentOptions(), rather than $.extend().
[16:15:58 EDT(-0400)] <colinclark> michelled: You don't happen to be around and paying attention, do you?
[16:16:18 EDT(-0400)] <michelled> I am around but haven't been paying attention - let me catch up
[16:16:52 EDT(-0400)] <yura> ok makes sense
[16:16:58 EDT(-0400)] <colinclark> basically, my thinking out loud process started when yura said "so you specify extend to be recurse"
[16:17:44 EDT(-0400)] <colinclark> yura: So, assuming michelled also thinks we're sane, I think we should probably replace $.extend() with fluid.mergeComponentOptions() on line 26.
[16:18:11 EDT(-0400)] <yura> yes, agreed
[16:18:16 EDT(-0400)] <colinclark> It'll be slightly inconvenient, since mergeComponentOptions expects to merge those options and place them at the "options" property of a "that"
[16:18:30 EDT(-0400)] <colinclark> and we don't yet have a "that," so we'll have to fake it
[16:18:51 EDT(-0400)] <yura> also, quick clarification : when editModeRenderer is called that.options.tinyMCE is already merged ?
[16:19:06 EDT(-0400)] <colinclark> yura: Yep, exactly
[16:19:25 EDT(-0400)] <yura> colinclark: ok
[16:19:30 EDT(-0400)] <colinclark> basically, a component gets its options all set up for it by the framework upon instantiation
[16:20:36 EDT(-0400)] * michelled thinks this makes sense but has gone to look at the code
[16:21:16 EDT(-0400)] <yura> would javascript allow that : var assembleOptions = fluid.mergeComponentOptions(assembleOptions, fluid.defaults(configurationName), options) ?
[16:23:23 EDT(-0400)] <colinclark> yura: unfortunately not
[16:23:27 EDT(-0400)] <colinclark> but we could just do this:
[16:23:56 EDT(-0400)] <colinclark> var optionsHolder = {};
[16:24:24 EDT(-0400)] <colinclark> fluid.mergeComponentOptions(optionsHolder, configurationName, options);
[16:24:37 EDT(-0400)] <colinclark> and then optionsHolder.options will contain the merged options
[16:24:44 EDT(-0400)] <colinclark> slightly annoying, but not the end of the world
[16:24:56 EDT(-0400)] * justin_o (n=jmo@CPE001b63f2cc0e-CM0011aec4b062.cpe.net.cable.rogers.com) has joined #fluid-work
[16:25:04 EDT(-0400)] <yura> ya
[16:25:39 EDT(-0400)] <colinclark> or we could use fluid.merge directly...
[16:25:58 EDT(-0400)] <colinclark> but it would essentially involve using half the implementation of mergeComponentOptions()
[16:26:19 EDT(-0400)] <colinclark> this is one of those cases where in any other language, you'd break mergeComponentOptions() up into two different functional calls...
[16:26:30 EDT(-0400)] <colinclark> but the cost of a JavaScript function invocation is pretty high.
[16:26:59 EDT(-0400)] <colinclark> justin_o: new patch on FLUID-3054
[16:27:08 EDT(-0400)] <colinclark> I think you found a bug.
[16:27:37 EDT(-0400)] <justin_o> colinclark: i'm just getting caught up on the logs
[16:27:48 EDT(-0400)] * alisonbenjamin (n=alisonbe@user129-142.wireless.utoronto.ca) has joined #fluid-work
[16:29:53 EDT(-0400)] <yura> colinclark: so configureInlineEdit would look like smth like this :
[16:29:53 EDT(-0400)] <yura> var defaults = fluid.defaults(configurationName);
[16:29:53 EDT(-0400)] <yura> var assembleOptions = fluid.merge(defaults? defaults.mergePolicy: null, {}, defaults, options);
[16:29:53 EDT(-0400)] <yura> return fluid.inlineEdit(container, assembleOptions);
[16:29:53 EDT(-0400)] <yura> ?
[16:30:23 EDT(-0400)] <colinclark> yura: yep
[16:32:17 EDT(-0400)] <yura> colinclark: so there's no need in plugin anymore ?
[16:32:33 EDT(-0400)] <colinclark> yura: Well, it seems we don't need it anymore
[16:32:40 EDT(-0400)] <justin_o> this is all pretty interesting
[17:05:35 EDT(-0400)] * anastasiac (n=team@142.150.154.189) has left #fluid-work
[17:22:58 EDT(-0400)] * justin_o (n=jmo@CPE001b63f2cc0e-CM0011aec4b062.cpe.net.cable.rogers.com) has left #fluid-work