fluid-work IRC Logs-2011-07-27

[08:40:00 CDT(-0500)] <cindyli> michelled: with the merge of project repo, the ui options setting on theme (colour & contrast) is no longer working
[08:40:11 CDT(-0500)] <cindyli> seems related to the merge of !important
[08:41:06 CDT(-0500)] <cindyli> michelled: do i need to execute or run certain script to bring back the "theme" adjustment?
[08:45:42 CDT(-0500)] <michelled> cindyli: yes, you need to run a build locally when you are working on UIO
[08:46:19 CDT(-0500)] <michelled> fluid-everyone: this is good information for everyone. Now that the !important work is in we have a build process which creates the stylesheet required for UIO.
[08:46:40 CDT(-0500)] <michelled> if you are working on UIO you need to run a build locally so that you have the correct stylesheets in the correct place
[08:46:58 CDT(-0500)] <michelled> to run the build, take a look at the build readme file in the build scripts directory
[08:48:06 CDT(-0500)] <cindyli> michelled: i don't see a readme fie in "buld-scripts" directory
[08:48:17 CDT(-0500)] <cindyli> ah, my bad. "build-README.txt
[08:48:49 CDT(-0500)] <michelled> https://github.com/fluid-project/infusion/blob/master/build-scripts/build-README.txt
[09:06:53 CDT(-0500)] <michelled> fluid-everyone: if you get this error when you run the build: org.mozilla.javascript.EcmaError: EvalError: Function "eval" must be called directly, and not by way of a function of another name.
[09:07:05 CDT(-0500)] <michelled> it's because the wrong version of rhino is being used
[09:07:42 CDT(-0500)] <michelled> the correct version is included in the build-scripts directory but you'll need to ensure that ant uses it
[09:13:08 CDT(-0500)] <anastasiac> harriswong, Justin_o, have you seen this one? With the new generated UIO stylesheets, applying an actual theme causes the slider horizontal lines to disappear. Is this a known thing?
[09:13:52 CDT(-0500)] <harriswong> anastasiac, justin_o: i wonder if that's similar to http://issues.fluidproject.org/browse/FLUID-4359
[09:15:32 CDT(-0500)] <anastasiac> harriswong, I'm not sure but I don't think so. For me, the text looks fine, but the line is just not there at all.
[09:16:20 CDT(-0500)] <Justin_o> anastasiac: hmm.. we'll take a look at that.. haven't seen it before.. but i haven't yet got the new setup running
[09:18:11 CDT(-0500)] <harriswong> justin_o, anastasiac: and i don't know if it's just my browser.. i just did a fetch on upstream master, my UIO colour & contrast don't work anymore... does anyone happen to have the same issue too?
[09:22:56 CDT(-0500)] <Justin_o> harriswong: you have to run a build now to get the correct css files
[09:23:14 CDT(-0500)] <harriswong> ic.
[09:26:17 CDT(-0500)] <huslage> does anyone know who could do an informal accessibility survey of Ushahidi?
[09:46:54 CDT(-0500)] <greggy1> huslage: I might be able to. What is Ushahidi
[09:47:19 CDT(-0500)] <huslage> ushahidi is a crowdsourced mapping platform
[09:47:40 CDT(-0500)] <huslage> an active instance is at: trunk.ushahidi.com
[09:48:00 CDT(-0500)] <huslage> the map is an obvious issue, but there are ways to get reports and stuff without the map
[09:49:02 CDT(-0500)] <greggy1> huslage: we generally charge for this type of work. It would be a little more complex that a typical web app.
[09:49:16 CDT(-0500)] <huslage> how much?
[10:55:48 CDT(-0500)] <michelled> colinclark: we just realized that we aren't quite done with the importance work
[10:55:56 CDT(-0500)] <colinclark> ok
[10:55:59 CDT(-0500)] <colinclark> how come?
[10:56:13 CDT(-0500)] <michelled> the urls in the stylesheet that point to images haven't been altered
[10:56:28 CDT(-0500)] <michelled> we could either fix those urls in the build process or copy over the images
[11:44:21 CDT(-0500)] <michelled> harriswong: any luck hunting down the test failures?
[11:47:44 CDT(-0500)] <michelled> harriswong: never mind - I just realized what it is - the tests weren't updated to use the new theme names
[11:47:50 CDT(-0500)] <michelled> oops - I should have caught this before
[11:48:14 CDT(-0500)] <harriswong> michelled: ok
[11:55:08 CDT(-0500)] <colinclark> Sounds like I should have caught this issue, my apologies
[11:55:31 CDT(-0500)] <colinclark> when you're working at the build-level, it's hard to imagine that it will impact test failures
[11:55:35 CDT(-0500)] <michelled> it's interesting colinclark - Justin_o and I were just talking out loud about this
[11:55:38 CDT(-0500)] <colinclark> but of course I actually changed the configuration of UI Options
[11:56:00 CDT(-0500)] <michelled> UIE clears the themes it knows about before setting one
[11:56:00 CDT(-0500)] <colinclark> As for the image URLs issue, that's a pretty fascinating tip of an iceberg
[11:56:09 CDT(-0500)] <colinclark> ok
[11:56:12 CDT(-0500)] <colinclark> tell me more
[11:56:18 CDT(-0500)] <michelled> it does this so it can win (smile)
[11:56:40 CDT(-0500)] <michelled> but UIE doesn't know about the FSS themes anymore - it knows about the theme it can set
[11:57:22 CDT(-0500)] <michelled> so the test is correct in failing but what I'm wondering about is whether we are ok with this. meaning, how do the UIO themes behave if there's an FSS theme on the page with it
[11:57:27 CDT(-0500)] <michelled> do they coexist nicely?
[11:57:32 CDT(-0500)] <michelled> I think we need to do some testing
[11:57:45 CDT(-0500)] <michelled> otherwise UIE needs to know about all the FSS themes
[11:57:47 CDT(-0500)] <colinclark> Hmmm
[11:57:49 CDT(-0500)] <colinclark> this is interesting
[11:57:52 CDT(-0500)] <harriswong> michelled: do you have other issues you want me to look at?
[11:57:54 CDT(-0500)] <colinclark> I guess we know some things in principle
[11:58:00 CDT(-0500)] <colinclark> in practice, we probably need to look at it more
[11:58:51 CDT(-0500)] <michelled> harriswong: any chance you can start to look at it to see what happens?
[11:58:52 CDT(-0500)] <colinclark> I think that we know we're "safe" to coexist with another theme
[11:59:30 CDT(-0500)] <colinclark> and we know that, in cases where two themes have, say, been applied to a document
[11:59:36 CDT(-0500)] <colinclark> we will probably, at least sorta, win
[11:59:47 CDT(-0500)] <colinclark> but that the ideal case is probably still to remove any known themes from the page
[11:59:52 CDT(-0500)] <colinclark> so that we can have the stage to ourselves
[11:59:53 CDT(-0500)] <colinclark> so to speak
[12:01:01 CDT(-0500)] <Justin_o> colinclark: yah.. I can see where things might clash when if one theme sets something that the uio theme doesn't
[12:01:32 CDT(-0500)] <colinclark> yep, exactly
[12:01:38 CDT(-0500)] <colinclark> that seemed to be the case I saw yesterday
[12:01:50 CDT(-0500)] <colinclark> with the theme not knocking out the background images from the preview page
[12:02:10 CDT(-0500)] <colinclark> just setting a background-colour and making it important won't do what we want
[13:28:40 CDT(-0500)] <michelled> fluid-everyone: who wants to be skyped into the dev meeting today?
[13:28:59 CDT(-0500)] <colinclark> i do, i do
[13:29:44 CDT(-0500)] <heidi_> michelled me pls
[13:31:18 CDT(-0500)] <michelled> you guys missed anastasiac acrobatic talents today!
[13:31:25 CDT(-0500)] <heidi_> woah what'd she do?
[13:32:01 CDT(-0500)] <michelled> I'm not even sure how to describe it - a triple roll flip perhaps (smile)
[13:32:16 CDT(-0500)] <jessm> thank goodness Iris didn't see it
[13:32:27 CDT(-0500)] <michelled> (smile)
[13:32:40 CDT(-0500)] <heidi_> triple roll flip :o
[13:33:47 CDT(-0500)] <colinclark> is anastasiac okay?
[13:35:57 CDT(-0500)] <jessm> michelled: can you add me to the call?
[13:36:21 CDT(-0500)] <colinclark> heidi_: This is the map I'm following along with http://maps.google.com/maps?q=Kano,+Nigeria&amp;hl=en&amp;ll=9.968851,8.679199&amp;spn=14.225343,22.192383&amp;sll=11.404649,10.447998&amp;sspn=7.092555,11.096191&amp;geocode=FQAbtwAdO_SBAA&amp;t=h&amp;z=6
[13:36:24 CDT(-0500)] <michelled> anastasiac is fine - she's a woman of many skills
[13:36:34 CDT(-0500)] <heidi_> colinclark i'm looking at google maps too hehe
[13:36:41 CDT(-0500)] <colinclark> (smile)
[13:40:37 CDT(-0500)] <Bosmon> Me too
[15:01:10 CDT(-0500)] <harriswong> michelled: the fat panel drop down overrite the fl-theme-rust clsas.
[15:18:12 CDT(-0500)] <lahabana> Bosmon: hello just seen your message
[15:18:23 CDT(-0500)] <lahabana> I've only got the testing part to finish
[15:18:32 CDT(-0500)] <lahabana> but were should I put it?
[15:20:57 CDT(-0500)] <lahabana> hi colinclark maybe you can answer my question
[15:38:57 CDT(-0500)] <colinclark> hi lahabana
[15:38:57 CDT(-0500)] <colinclark> S
[15:39:02 CDT(-0500)] <lahabana> hi
[15:39:04 CDT(-0500)] <colinclark> Sorry for the delay in responding
[15:39:04 CDT(-0500)] <colinclark> what'
[15:39:04 CDT(-0500)] <colinclark> s
[15:39:06 CDT(-0500)] <colinclark> up?
[15:39:09 CDT(-0500)] <lahabana> it's ok
[15:39:39 CDT(-0500)] <lahabana> well Bosmon asked me to finished my correction of stringTemplate tonight
[15:39:52 CDT(-0500)] <lahabana> my only problem is that I don't know where to put the tests
[15:40:04 CDT(-0500)] <lahabana> I've written them and they work
[15:40:42 CDT(-0500)] <colinclark> ok, let me just look
[15:40:48 CDT(-0500)] <lahabana> just ftm I've just done a html file that runs a script and checks that the result is right
[15:40:49 CDT(-0500)] <colinclark> I'm pretty sure there were tests for the original implementation
[15:40:58 CDT(-0500)] <lahabana> yes that's what I thought
[15:41:10 CDT(-0500)] <lahabana> so I could just go with these
[15:41:30 CDT(-0500)] <colinclark> let's just have a look
[15:41:31 CDT(-0500)] <colinclark> one sec
[15:46:42 CDT(-0500)] <colinclark> lahabana: Here are the unit tests for fluid.stringTemplate()
[15:46:44 CDT(-0500)] <colinclark> https://github.com/fluid-project/infusion/blob/master/src/webapp/tests/framework-tests/core/js/FluidJSTests.js#L196-304
[15:46:55 CDT(-0500)] <colinclark> So you'd want to do the following
[15:47:00 CDT(-0500)] <colinclark> 1) Make sure the current unit tests still pass
[15:47:04 CDT(-0500)] <lahabana> that's what I've just found
[15:47:17 CDT(-0500)] <colinclark> 2) Add a new test function to test the new functionality you've added
[15:47:22 CDT(-0500)] <lahabana> ok
[15:48:56 CDT(-0500)] <lahabana> colinclark: thx the current tests still pass I'm adding the new tests
[15:49:03 CDT(-0500)] <lahabana> commits it and update my branch
[15:49:10 CDT(-0500)] <colinclark> great
[15:49:15 CDT(-0500)] <lahabana> and I ask for a pull request is that right?
[15:49:25 CDT(-0500)] <colinclark> yep, that's right
[15:49:25 CDT(-0500)] <colinclark> i
[15:49:37 CDT(-0500)] <lahabana> colinclark: ok thx
[15:57:40 CDT(-0500)] <Bosmon> Thanks lahabana, sorry not to respond
[15:57:49 CDT(-0500)] <Bosmon> I still need to configure this IRC client to alert me (tongue)
[15:57:54 CDT(-0500)] <Bosmon> I found a video to explain how to do it....
[15:58:20 CDT(-0500)] <lahabana> ho ok (wink) no probs Bosmon I'm almost done
[15:59:47 CDT(-0500)] <lahabana> Bosmon: I've found a new bug I think
[16:00:01 CDT(-0500)] <lahabana> Bosmon: but I don't really know how to solve it
[16:00:52 CDT(-0500)]

<lahabana> if I've got a template object like

Unknown macro: {"[]"}

[16:01:20 CDT(-0500)] <lahabana> it fails to replace the second one cause it replaces it by the first one
[16:01:29 CDT(-0500)] <Bosmon> lahabana - that's fine
[16:01:38 CDT(-0500)] <lahabana> I mean a string like %[] blabla %[]file blabla
[16:01:58 CDT(-0500)] <Bosmon> It is a reasonable requirement for users to ensure that no replacement text agrees with a template key text
[16:01:59 CDT(-0500)] <lahabana> will make: toReplace blabla toReplacefile blabla
[16:02:14 CDT(-0500)] <Bosmon> And that no template key is a prefix to another
[16:02:46 CDT(-0500)] <Bosmon> We can add these requirements to the documentation (tongue)
[16:03:08 CDT(-0500)] <lahabana> ok then
[16:03:19 CDT(-0500)] <lahabana> so I think I'm done
[16:03:30 CDT(-0500)] <lahabana> I've added 2 tests
[16:03:37 CDT(-0500)] <lahabana> one with multiple replacement
[16:03:50 CDT(-0500)] <lahabana> and one with special characters
[16:04:07 CDT(-0500)] <Bosmon> That's great - have you pushed your implementation to a branch?
[16:04:15 CDT(-0500)] <lahabana> I'm going to
[16:04:22 CDT(-0500)] <lahabana> I have to update my branch
[16:06:57 CDT(-0500)] <Bosmon> Hi cindyli - just checking in
[16:07:04 CDT(-0500)] <Bosmon> DId the comments from last night generally make sense?
[16:07:14 CDT(-0500)] <cindyli> make lots of sense
[16:07:19 CDT(-0500)] <Bosmon> I couldn't quite hear all of your update, but it sounded like you were going ahead with the plan of assigning "container" into the options structure
[16:07:21 CDT(-0500)] <cindyli> thanks for the nice detail suggestions
[16:07:26 CDT(-0500)] <Bosmon> So that it could be later used for options munging
[16:07:54 CDT(-0500)] <cindyli> yes, and assigning container as one of the options is working
[16:08:02 CDT(-0500)] <Bosmon> That's great
[16:08:04 CDT(-0500)] <cindyli> also implemented fluid.uiOptions.inline
[16:08:10 CDT(-0500)] <Bosmon> Splendid
[16:08:13 CDT(-0500)] <cindyli> moving on to "uiOptionsTransform"
[16:08:23 CDT(-0500)] <Bosmon> I'm not sure the name is great, but perhaps people have some better ideas
[16:08:26 CDT(-0500)] <lahabana> fluid-everyone how do I update my fork to the current fluid/infusion ?
[16:08:49 CDT(-0500)] <Bosmon> It seemed some way of expressing that these configurations of UIOptions put the component inline in the current page
[16:09:12 CDT(-0500)] <colinclark> lahabana: You'll need to fetch and pull from the upstream repository
[16:09:14 CDT(-0500)] <Bosmon> lahabana, you need to do a "git pull" from the master repo into your local copy of the branch, and then push that merged version into your fork
[16:09:18 CDT(-0500)] <colinclark> (smile)
[16:09:28 CDT(-0500)] <colinclark> I think we've probably got a tutorial in the wiki somewhere, wouldn't you think, Bosmon?
[16:09:28 CDT(-0500)] <Bosmon> You can also split that up as a "git fetch" followed by a "git merge" which is generally safer
[16:09:39 CDT(-0500)] <Bosmon> It's certainly possible (tongue)
[16:09:48 CDT(-0500)] <colinclark> lemme check
[16:09:55 CDT(-0500)] <cindyli> Bosmon: having problem with this code tho -
[16:09:57 CDT(-0500)] <cindyli>      fluid.uiOptions.fullPreview = function (container, options) {
[16:09:57 CDT(-0500)] <cindyli>          var mapping = fluid.defaults("fluid.uiOptions.fullPreview").uiOptionsTransform;
[16:10:05 CDT(-0500)] <lahabana> ok thx
[16:10:12 CDT(-0500)] <cindyli> got - fluid.defaults("fluid.uiOptions.fullPreview") is undefined
[16:10:15 CDT(-0500)] <Bosmon> The problem with "git pull" is that it will usually do the merge into the wrong branch, causing surprise and painful confusion (tongue)
[16:10:22 CDT(-0500)] <Bosmon> cindyli - that's interesting
[16:10:27 CDT(-0500)] <Bosmon> Did you make a defaults structure for it?
[16:10:38 CDT(-0500)] <cindyli> yes, i think it makes sense since "fluid.uiOptions.fullPreview" is no longer autoinit
[16:10:44 CDT(-0500)] <colinclark> lahabana: http://wiki.fluidproject.org/display/fluid/GIT+Tips+and+Tricks
[16:10:54 CDT(-0500)] <colinclark> Here's a brief overview of what you'll need to do:
[16:10:59 CDT(-0500)] <Bosmon> It's no longer autoInit, but it presumably still has defaults...
[16:11:00 CDT(-0500)] <cindyli> it would not be in place before the initView() call
[16:11:06 CDT(-0500)] <Bosmon> ?!
[16:11:09 CDT(-0500)] <colinclark> 1. Create a new remote, called "upstream," which will point to the project repo
[16:11:32 CDT(-0500)] <colinclark> 2. git fetch upstream
[16:11:42 CDT(-0500)] <cindyli> Bosmon: yes, it still has defaults but not sure if it's fetchable before the component is instantiated
[16:11:48 CDT(-0500)] <colinclark> 3. git checkout <your branch>
[16:11:55 CDT(-0500)] <colinclark> 4. git merge upstream/master
[16:11:57 CDT(-0500)] <Bosmon> cindyli - certainly it is .... it should be fetchable at any time after you have registered them
[16:12:00 CDT(-0500)] <Bosmon> Perhaps there is a typo?
[16:12:33 CDT(-0500)] <cindyli> ic, should i call register namespace, forget the exact func name, to register?
[16:12:45 CDT(-0500)] <Bosmon> cindy - should not be necessary
[16:12:57 CDT(-0500)] <Bosmon> The only thing I can think of is that you mistyped the name in the original fluid.defaults call.....
[16:14:07 CDT(-0500)] <cindyli> Bosmon: yes, found typo. correcting
[16:14:10 CDT(-0500)] <Bosmon> (smile)
[16:14:45 CDT(-0500)] <cindyli> Bosmon: perfect. passes that line
[16:14:51 CDT(-0500)] <cindyli> thanks, (smile)
[16:15:37 CDT(-0500)] <Bosmon> It's a shame that, with this scheme, "container" problem may be the only reason we can't destroy ALL contents of wrapper files except for fluid.defaults
[16:15:56 CDT(-0500)] <Bosmon> I looked into the framework code and couldn't see how we could make this work, given the 1.3.1 chewing implementation in the Uploader
[16:16:53 CDT(-0500)] <cindyli> we'll improve in 1.5 (wink)
[16:17:29 CDT(-0500)] <cindyli> i actually need to learn about "1.3.1 chewing implementation". no idea how it works
[16:17:52 CDT(-0500)] <Bosmon> cindyli - it works EXACTLY like this current scheme - only the record is named "transformOptions" rather than "uiOptionsTransform" (tongue)
[16:18:12 CDT(-0500)] <cindyli> oh, ic
[16:18:33 CDT(-0500)] <cindyli> but u don't think we can make use of that
[16:18:35 CDT(-0500)] <Bosmon> If you were to rename that record, you could destroy the wrapper completely and make the component autoInit - and the framework would run the transformation for you automatically
[16:18:47 CDT(-0500)] <cindyli> sounds good
[16:18:48 CDT(-0500)] <Bosmon> I think we can't use it because of the impossibility of referring to "container" in the transformation record
[16:18:54 CDT(-0500)] <cindyli> right
[16:19:05 CDT(-0500)] <cindyli> container needs to be handled specially
[16:19:13 CDT(-0500)] <cindyli> since it's not a regular option
[16:19:45 CDT(-0500)] <Bosmon> Yes.... it's our own silly fault for not deciding on univerally using 1-argument functions (tongue)
[16:19:52 CDT(-0500)] <Bosmon> But, 2008 was a very different age.....
[16:19:57 CDT(-0500)] <cindyli> lol
[16:21:09 CDT(-0500)]

<Bosmon> "in theory" there should be an IoC-style syntax for referring to the most recent container argument.... like "

Unknown macro: {container}

"


[16:21:15 CDT(-0500)] <Bosmon> But I suspect it won't work
[16:21:20 CDT(-0500)] <Bosmon> In this context
[16:22:03 CDT(-0500)] <cindyli> umm.. sounds tricky
[16:22:17 CDT(-0500)]

<cindyli>

Unknown macro: {container}

could refer to any container on the tree


[16:22:36 CDT(-0500)] <Bosmon> The scoping rules should take care of the fact it just refers to the most closely nested one
[16:22:44 CDT(-0500)] <cindyli> ic
[16:23:17 CDT(-0500)] <Bosmon> Anyway, once you get the "fully manual" version working, we can try a last-ditch experiment