fluid-work IRC Logs-2011-08-05
- Fluid IRC Log Bot
[09:11:40 CDT(-0500)] <huslage> hi hi <colinclark> And I'm going to try "importantInjectionModule=$ /build-scripts/importantInjection.json", which should allow Ant to generate suitably absolute paths for the build <Justin_o> listeners: ;
[11:00:37 CDT(-0500)] <colinclark> Justin_o: hey king
[11:00:39 CDT(-0500)] <colinclark> how's it going?
[11:01:16 CDT(-0500)] <Justin_o> colinclark: hello.. not too bad.. it seems like i just have a deep muscle strain or something like that
[11:01:23 CDT(-0500)] <colinclark> ouch
[11:01:34 CDT(-0500)] <colinclark> some stretches and the like?
[11:02:17 CDT(-0500)] <Justin_o> colinclark: just try not to aggravate it till it heals up is basically all the doctor said 
[11:02:24 CDT(-0500)] <colinclark> cool
[11:02:45 CDT(-0500)] <colinclark> Well, I bought a baseball glove if you want to play some catch instead of higher-impact soccer or basketball
[11:02:54 CDT(-0500)] <colinclark> Anyway, the daily build
[11:03:09 CDT(-0500)] <colinclark> So I ultimately didn't have to make any code changes or really do anything... just include clearer instructions
[11:03:18 CDT(-0500)] <colinclark> Users can do one of two things;
[11:03:39 CDT(-0500)] <colinclark> 1. Replace the version of Rhino installed by Ant with the newer one we distribute with Infusion's build scripts
[11:03:56 CDT(-0500)] <colinclark> 2. Use the -lib flag to specify our version of that jar
[11:04:03 CDT(-0500)] <Justin_o> colinclark: +1 for playing catch
[11:04:13 CDT(-0500)] <colinclark> cool
[11:04:18 CDT(-0500)] <colinclark> name the day and time
[11:04:27 CDT(-0500)] <colinclark> Which of these solutions makes the most sense for the daily build?
[11:04:29 CDT(-0500)] <colinclark> and
[11:04:32 CDT(-0500)] <colinclark> a. Can I help?
[11:04:39 CDT(-0500)] <colinclark> b. Does huslage need to be involved at all?
[11:05:48 CDT(-0500)] <Justin_o> colinclark: i guess it depends on what affect it will have on the current infusion builder
[11:06:09 CDT(-0500)] <colinclark> ah, yes
[11:06:10 CDT(-0500)] <colinclark> the Builder, too
[11:06:30 CDT(-0500)] <colinclark> I think the easiest and least change-causing thing to do would be to just upgrade Ant's version of Rhino
[11:06:32 CDT(-0500)] <colinclark> what do you think?
[11:07:48 CDT(-0500)] <Justin_o> colinclark: i think so
[11:08:19 CDT(-0500)] <Justin_o> i did take a quick peak this morning at the ant on server, but didn't see the rhino jar in the lib directory
[11:08:24 CDT(-0500)] <Justin_o> i may have just missed it though
[11:16:34 CDT(-0500)] <colinclark> hmm
[11:16:38 CDT(-0500)] <colinclark> That would be very odd
[11:16:47 CDT(-0500)] <colinclark> and a sign that somehow the code wasn't getting updated properly
[11:20:08 CDT(-0500)] <Justin_o> colinclark: just to clarify, i didn't mean in the infusion checkout but in the ant's lib directory
[11:21:47 CDT(-0500)] <Justin_o> which makes me wonder how the build worked at all.
[11:25:44 CDT(-0500)] <colinclark> hmm
[11:25:51 CDT(-0500)] <colinclark> it must be there somewhere, I guess
[11:25:53 CDT(-0500)] <colinclark> I can take a look
[11:26:06 CDT(-0500)] <colinclark> I'm not sure I have the credentials, but you can remind me of them offline at some point
[12:35:56 CDT(-0500)] <Bosmon> Hi cindyli - what is the state of munging and merging today? 
[12:36:21 CDT(-0500)] <cindyli> Bosmon: it's done!!!
[12:36:56 CDT(-0500)] <cindyli> in my branch, waiting for ur futher review
[12:41:44 CDT(-0500)] <Justin_o> jameswy: quick question about the themes
[12:42:12 CDT(-0500)] <Justin_o> jameswy: I think our jquery ui style sheets for them may be wrong
[12:42:18 CDT(-0500)] <Justin_o> here's an example of the yellow on black
[12:42:18 CDT(-0500)] <Justin_o> http://jqueryui.com/themeroller/?ffDefault=Verdana,Arial,sans-serif&fwDefault=normal&fsDefault=1.1em&cornerRadius=4px&bgColorHeader=ffff00&bgTextureHeader=01_flat.png&bgImgOpacityHeader=100&borderColorHeader=000000&fcHeader=00000&iconColorHeader=000000&bgColorContent=ffff00&bgTextureContent=01_flat.png&bgImgOpacityContent=100&borderColorContent=000000&fcContent=000000&iconColorContent=000000&bgColorDefault=ffff0
[12:42:18 CDT(-0500)] <Justin_o> xtureDefault=01_flat.png&bgImgOpacityDefault=100&borderColorDefault=000000&fcDefault=000000&iconColorDefault=000000&bgColorHover=ffff00&bgTextureHover=01_flat.png&bgImgOpacityHover=100&borderColorHover=000000&fcHover=000000&iconColorHover=000000&bgColorActive=ffff00&bgTextureActive=01_flat.png&bgImgOpacityActive=50&borderColorActive=000000&fcActive=000000&iconColorActive=000000&bgColorHighlight=ffff00&bgTextureH
[12:42:19 CDT(-0500)] <Justin_o> t=01_flat.png&bgImgOpacityHighlight=100&borderColorHighlight=000000&fcHighlight=000000&iconColorHighlight=000000&bgColorError=ffff00&bgTextureError=01_flat.png&bgImgOpacityError=100&borderColorError=cd0a0a&fcError=000000&iconColorError=000000&bgColorOverlay=aaaaaa&bgTextureOverlay=01_flat.png&bgImgOpacityOverlay=0&opacityOverlay=30&bgColorShadow=aaaaaa&bgTextureShadow=01_flat.png&bgImgOpacityShadow=0&opacityShad
[12:42:19 CDT(-0500)] <Justin_o> hicknessShadow=8px&offsetTopShadow=-8px&offsetLeftShadow=-8px&cornerRadiusShadow=8px#ffDefault=Verdana%2CArial%2Csans-serif&fwDefault=normal&fsDefault=1.1em&cornerRadius=4px&bgColorHeader=ffff00&bgTextureHeader=01_flat.png&bgImgOpacityHeader=100&borderColorHeader=000000&fcHeader=ffff00&iconColorHeader=000000&bgColorContent=ffff00&bgTextureContent=01_flat.png&bgImgOpacityContent=100&borderColorContent=000000&fcCo
[12:42:19 CDT(-0500)] <Justin_o> 00000&iconColorContent=000000&bgColorDefault=ffff00&bgTextureDefault=01_flat.png&bgImgOpacityDefault=100&borderColorDefault=000000&fcDefault=000000&iconColorDefault=000000&bgColorHover=ffff00&bgTextureHover=01_flat.png&bgImgOpacityHover=100&borderColorHover=000000&fcHover=000000&iconColorHover=000000&bgColorActive=ffff00&bgTextureActive=01_flat.png&bgImgOpacityActive=50&borderColorActive=000000&fcActive=000000&i
[12:42:19 CDT(-0500)] <Justin_o> rActive=000000&bgColorHighlight=ffff00&bgTextureHighlight=01_flat.png&bgImgOpacityHighlight=100&borderColorHighlight=000000&fcHighlight=000000&iconColorHighlight=000000&bgColorError=ffff00&bgTextureError=01_flat.png&bgImgOpacityError=100&borderColorError=cd0a0a&fcError=000000&iconColorError=000000&bgColorOverlay=aaaaaa&bgTextureOverlay=01_flat.png&bgImgOpacityOverlay=0&opacityOverlay=30&bgColorShadow=aaaaaa&bgTe
[12:42:20 CDT(-0500)] <Justin_o> adow=01_flat.png&bgImgOpacityShadow=0&opacityShadow=30&thicknessShadow=8px&offsetTopShadow=-8px&offsetLeftShadow=-8px&cornerRadiusShadow=8px
[12:42:23 CDT(-0500)] <jameswy> Yikes!
[12:42:27 CDT(-0500)] <jameswy> That definitely looks wrong.
[12:42:34 CDT(-0500)] <jameswy>
[12:42:43 CDT(-0500)] <jameswy> What am I looking exactly?
[12:43:11 CDT(-0500)] <Justin_o> did you follow the link?
[12:43:56 CDT(-0500)] <Justin_o> jameswy: i wonder if you would like to do some screen sharing and we can try to get them all corrected
[12:43:57 CDT(-0500)] <Justin_o> ?
[12:45:51 CDT(-0500)] <jameswy> Justin_o: Sure, let's do that in a bit. Give me 10.
[12:46:03 CDT(-0500)] <Justin_o> jameswy: okay.. i'll log into Skype, call me when you're ready
[12:53:36 CDT(-0500)] <Bosmon> cindyli - amazing
[12:53:41 CDT(-0500)] <Bosmon> Did you manage to merge up with my branch?
[12:54:00 CDT(-0500)] <cindyli> yes, Bosmon
[12:54:06 CDT(-0500)] <Bosmon> super
[13:01:03 CDT(-0500)] <Bosmon> cindyli - reviewing your branch now
[13:01:13 CDT(-0500)] <Bosmon> it is looking very good - I have a question about the new "mapOptions"
[13:01:19 CDT(-0500)] <cindyli> sure
[13:02:03 CDT(-0500)] <Bosmon> On line 237, shouldn't you be adding the new value to the "componentOptions" applier rather than to the main one?
[13:02:18 CDT(-0500)] <Bosmon> Hmm
[13:02:32 CDT(-0500)] <Bosmon> I guess you are treating all of "componentOptions" as lower priority to "options"....
[13:02:40 CDT(-0500)] <cindyli> exactly
[13:03:13 CDT(-0500)] <Bosmon> I guess that works in this case, but it makes me worried, as a general policy
[13:04:35 CDT(-0500)] <cindyli> well, i don't treat which option has what priority, it's determined by mergePolicy. i just manipulte them on separate trees, in case the same options are given on both
[13:06:04 CDT(-0500)] <Bosmon> Can you point me again to the place where the object RHS appears in a transform record?
[13:06:09 CDT(-0500)] <Bosmon> I don't seem to be finding it
[13:06:26 CDT(-0500)] <cindyli> line 242
[13:06:36 CDT(-0500)] <Bosmon> I mean, where it appears in configuration
[13:06:54 CDT(-0500)] <Bosmon> So, I think we have other "priority" problems in any case
[13:07:11 CDT(-0500)] <Bosmon> On lines 200 and 201 there are options which may conflict
[13:07:24 CDT(-0500)] <Bosmon> One of them assigns to "templateLoader" and the other to a nested path
[13:07:39 CDT(-0500)] <Bosmon> And given that JSON iteration order is not guaranteed, on some platforms this will lead to a failure
[13:07:50 CDT(-0500)] <cindyli> in terms of the "the object RHS appearance", FullNoPreviewUIOptions.js line 30 - 50
[13:07:54 CDT(-0500)] <Bosmon> Thanks
[13:07:59 CDT(-0500)] <cindyli> np
[13:08:34 CDT(-0500)] <Bosmon> Ah, I see
[13:08:51 CDT(-0500)] <Bosmon> So what configuration can FullNoPreview 30-50 conflict with?
[13:09:04 CDT(-0500)] <cindyli> with the user's options
[13:09:18 CDT(-0500)] <Bosmon> with the user's options......
[13:09:38 CDT(-0500)] <cindyli> for example, the same "templateLoader" is given in the options at calling fluid.uiOptions.fullNopreview
[13:09:51 CDT(-0500)] <Bosmon> Ah yes
[13:10:33 CDT(-0500)] <Bosmon> Ok, so that is clear, no possibility for "irrational conflict" there...
[13:10:47 CDT(-0500)] <Bosmon> So I think after we take care of this conflict possibility I just mentioned, we can be ready to commit
[13:11:05 CDT(-0500)] <cindyli> u mean lines 200 and 201
[13:11:10 CDT(-0500)] <Bosmon> Yes
[13:11:21 CDT(-0500)] <cindyli> ya, i agree there's a conflict
[13:11:28 CDT(-0500)] <Bosmon> So, what I suggest is that you convert the transform config into an array first in mapOptions
[13:11:42 CDT(-0500)] <Bosmon> And then sort the array keys in order of increasing length
[13:12:52 CDT(-0500)] <cindyli> ok
[13:14:07 CDT(-0500)] <Bosmon> Also I'm wondering on FatPanelUIOptions.js line 263, it might not be safer to use fluid.set() rather than direct property access
[13:14:17 CDT(-0500)] <Bosmon> Just in case someone tries to configure a "deeper bridge mapping"
[13:14:21 CDT(-0500)] <Bosmon> We expect that they shouldn't do this
[13:14:27 CDT(-0500)] <Bosmon> But it is not inconceivable
[13:15:12 CDT(-0500)] <Bosmon> Also just for neatness on line 267, eliminate the common subexpression accessing the component's default options....
[13:15:59 CDT(-0500)] <Bosmon> Same at line 280
[13:18:21 CDT(-0500)] <colinclark> Bosmon and cindyli: Sounds like things are coming along pretty nicely
[13:18:55 CDT(-0500)] <colinclark> nice work, dudes
[13:34:28 CDT(-0500)] <colinclark> Justin_o: So it seems that the daily build hasn't been failing due to the version of Rhino
[13:34:40 CDT(-0500)] <colinclark> I'm digging into it, but it's not finding a file called importantInjection.json
[13:34:55 CDT(-0500)] <Justin_o> 
[13:35:23 CDT(-0500)] <Justin_o> that one should be coming with the checkout though right
[13:35:43 CDT(-0500)] <colinclark> yeah, it's there
[13:35:56 CDT(-0500)] <colinclark> it's just a question, I think, of what the current directory is when it's run by continuum
[13:36:12 CDT(-0500)] <Bosmon> anastasiac, michelled, colinclark, cindyli, Justin_o - so we should get ready to have an API review of UIOptions shortly, I think
[13:36:24 CDT(-0500)] <Bosmon> Just as soon as we get cindyli's upcoming pull in
[13:36:29 CDT(-0500)] <Justin_o> colinclark: oh.. strange
[13:36:53 CDT(-0500)] <Justin_o> Bosmon: when do you think that will be?
[13:37:07 CDT(-0500)] <Justin_o> today or monday? for the review
[13:41:20 CDT(-0500)] <colinclark> Justin_o: I think it's probably just the relative path we used in the build.properties
[13:41:44 CDT(-0500)] <colinclark> we had "importantInjectionModule=./importantInjection.json"
[13:42:12 CDT(-0500)]
[13:42:34 CDT(-0500)] <colinclark> I'm going to need to push this to the project repository to test it (aside from on my local system)
[13:42:44 CDT(-0500)] <colinclark> What do you recommend the appropriate procedure should be?
[13:43:16 CDT(-0500)] <Justin_o> colinclark: the fix makes sense.. it's unfortunate that you'd have to push it, but it seems there's no other way.. i wonder why it is that the server behaves differently than our local systems
[13:43:19 CDT(-0500)] <Justin_o> ?
[13:44:24 CDT(-0500)] <Bosmon> Justin_o - I think cindyli should be ready by this afternoon?
[13:44:34 CDT(-0500)] <Bosmon> I guess we actually need to take some time to assemble what the new API actually IS
[13:44:44 CDT(-0500)] <Bosmon> Since it's certainly quite different to the one we currently have documented
[13:54:26 CDT(-0500)] <harriswong> Justin_o: i have a question on the imageReorderer. I keep getting a " ASSERTION FAILED: Listener registered for event afterMove which is not defined for this component" and i am not sure what i am missing.
[13:55:52 CDT(-0500)] <Justin_o> harriswong: sounds like you have a listener that doesn't exist.. like if you passed in options like the following
[13:56:03 CDT(-0500)] <harriswong> Justin_o: Looking at http://wiki.fluidproject.org/display/fluid/Image+Reorderer+API, listeners; i tried adding the "afterMove" to the listener in the demo (webapp/demos/reorderer/imageReorderer/js/imageReorderer.js)
[13:56:14 CDT(-0500)]
[13:57:14 CDT(-0500)] <harriswong> Justin_o: that's what i thought, i must be missing something somewhere, here is my code if you have a min, http://pastebin.com/CcpeLJJH
[13:58:05 CDT(-0500)] <Justin_o> harriswong: what happens if you don't include the listener block at all?
[13:58:39 CDT(-0500)] <harriswong> Justin_o: then it's fine, the current demo has no listeners.
[13:58:58 CDT(-0500)] <Justin_o> harriswong: but you get the error with this?
[13:59:14 CDT(-0500)] <Bosmon> harriswong - the "ImageReorderer" is a different component to the Reorderer
[13:59:20 CDT(-0500)] <Bosmon> And it has no events defined on it directly
[13:59:28 CDT(-0500)] <Bosmon> If you were to look at the source
[13:59:32 CDT(-0500)] <Bosmon> Which I highly recommend
[14:00:23 CDT(-0500)] <Bosmon> I guess this is a kind of bug....
[14:00:40 CDT(-0500)] <Bosmon> But merely highlights the kinds of problems we have had for a long time writing these kinds of wrappers
[14:01:30 CDT(-0500)] <Justin_o> Bosmon: the docs make it look like you should be able to use these at the top level
[14:01:31 CDT(-0500)] <Justin_o> http://wiki.fluidproject.org/display/fluid/Image+Reorderer+API
[14:01:33 CDT(-0500)] <harriswong> Justin_o: yes
[14:01:49 CDT(-0500)] <harriswong> Justin_o: yes for the "but you get the error with this?"
[14:03:31 CDT(-0500)] <colinclark> I'm fairly certain that those wrappers did indeed support the core Reorderer options
[14:04:17 CDT(-0500)] <colinclark> or rather, do
[14:05:53 CDT(-0500)] <colinclark> Given the changes to the framework over the past little while, the code in fluid.reorderImages() does seem a bit suspect
[14:05:54 CDT(-0500)] <Justin_o> colinclark, Bosmon, harriswong: this makes it look like they do get passed along https://github.com/fluid-project/infusion/blob/master/src/webapp/components/reorderer/js/ImageReorderer.js#L131-149
[14:06:07 CDT(-0500)] <Justin_o> although there is something going on with the events there before hand
[14:06:15 CDT(-0500)] <colinclark> yeah, it's a bit problematic
[14:06:27 CDT(-0500)] <colinclark> Are there unit tests for this?
[14:07:19 CDT(-0500)] <colinclark> Bosmon: Given the changes to the framework since IoC, is this sort of double options merging even viable anymore?
[14:08:21 CDT(-0500)] <colinclark> harriswong: Just for fun, could you try registering your listener after instantiating your Reorderer?
[14:08:56 CDT(-0500)] <colinclark> You can add listeners at any time by calling myReorderer.events.afterMove.addListener()
[14:09:35 CDT(-0500)] <Bosmon> colinclark - it is not terribly viable, but the bug is actually from a different cause
[14:09:41 CDT(-0500)] <colinclark> ah, interesting
[14:09:42 CDT(-0500)] <colinclark> what is it?
[14:09:57 CDT(-0500)] <Bosmon> In the case you used to register an listener for a non-existent event, the framework would silently auto-create the event for you
[14:10:39 CDT(-0500)] <Bosmon> Some time, perhaps around 1.3 or so we decided that this actually was an unhelpful behaviour, since it let cases that were really misconfiguration look as if they were working
[14:10:46 CDT(-0500)] <Bosmon> Which I guess technically you can say this is
[14:11:06 CDT(-0500)] <Bosmon> For example, before this fix, imageReorderer would be adding the listener to an auto-created event of its own
[14:11:14 CDT(-0500)] <harriswong> colinclark: ok i will try that now.
[14:11:19 CDT(-0500)] <Bosmon> BEFORE then taking it and adding it also to the "right" event in the inner Reorderer
[14:11:53 CDT(-0500)] <Bosmon> I mean, it wasn't really a problem, because the "ImageReorderer" component would be garbage collected before long, but it certainly wasn't "kosher"
[14:12:40 CDT(-0500)] <Bosmon> It's interesting to see how many wackily different solutions to this "component wrapper issue" we have concocted over the years
[14:12:43 CDT(-0500)] <Bosmon> But NO LONGER!
[14:12:49 CDT(-0500)] <Bosmon> 1.5 will be the release where they finally all die
[14:16:34 CDT(-0500)] <harriswong> colinclark: then it works after instantiation
[14:16:39 CDT(-0500)] <cindyli> Bosmon: changes done and pushed
[14:21:42 CDT(-0500)] <Bosmon> I don't understand why git will sometimes refuse to do a fetch
[14:21:49 CDT(-0500)] <Bosmon> I'm using exactly the same command I used 1 hour ago to fetch your changes
[14:21:54 CDT(-0500)] <Bosmon> And this time it is refusing
[14:22:11 CDT(-0500)] <Bosmon> With that stupid message it gives
[14:22:11 CDT(-0500)] <Bosmon> fatal: Refusing to fetch into current branch refs/heads/cindyli/FLUID-4353 of non-bare repository
[14:22:14 CDT(-0500)] <Bosmon> hmm!!!
[14:22:24 CDT(-0500)] <Bosmon> ha!!!
[14:22:25 CDT(-0500)] <cindyli> what...
[14:22:28 CDT(-0500)] <Bosmon> It is simply because it is the CURRENT BRANCH
[14:22:33 CDT(-0500)] <Bosmon> I finally read the message carefully
[14:22:34 CDT(-0500)] <cindyli> aha
[14:22:35 CDT(-0500)] <Bosmon> What a stupid restriction
[14:27:08 CDT(-0500)] <Bosmon> Ok, this is looking good
[14:27:14 CDT(-0500)] <Bosmon> I will just try it out for a bit and then push it...
[14:34:56 CDT(-0500)] <Bosmon> Hi cindy - one final problem
[14:35:23 CDT(-0500)] <Bosmon> Line 263, FatPanelUIOptions.js
[14:35:41 CDT(-0500)] <Bosmon> It doesn't actually give us any extra power to access option values, since it always truncates at the LAST "." index
[14:35:58 CDT(-0500)] <Bosmon> And so this will actually even fail in the case that they try to specify any deeper options
[14:36:21 CDT(-0500)] <Bosmon> The EL path should best be extracted by the part that follows "*.bridge.options."
[14:36:24 CDT(-0500)] <Bosmon> cindyli ^
[14:36:32 CDT(-0500)] <cindyli> ya
[14:37:32 CDT(-0500)] <harriswong> Justin_o: http://issues.fluidproject.org/browse/FLUID-4388
[14:38:01 CDT(-0500)] <harriswong> Justin_o: regarding to a ToC hide/show problem heidi_ spotted yesterday.
[14:40:04 CDT(-0500)] <Justin_o> harriswong: thanks, just read it over.. it had been decided that it should just be a hide when closed; however we should look into that in more detail later…thanks for filing it
[14:40:45 CDT(-0500)] <harriswong> Justin_o: great, thanks.
[14:41:57 CDT(-0500)] <cindyli> Bosmon: i still think it should truncate from the last "."
[14:42:23 CDT(-0500)] <Bosmon> cindyli - in that case, there is no point using fluid.set()...
[14:42:31 CDT(-0500)] <cindyli> another level of options interpretion will be done in "inline" components
[14:42:40 CDT(-0500)] <Bosmon> Well, it will, yes
[14:43:31 CDT(-0500)] <Bosmon> This is why I said I thought that this shouldn't really be necessary - however, it is conceivable somebody might want to take advantage of this flexibility
[14:43:50 CDT(-0500)] <cindyli> umm..
[14:44:04 CDT(-0500)] <cindyli> that makes sense
[14:44:06 CDT(-0500)] <Bosmon> But picking the "last ." will probably make noone happy
[14:44:26 CDT(-0500)] <Bosmon> In that case, people specifying longer paths will just get them truncated to the last segment, which will be deeply surprising
[14:44:51 CDT(-0500)] <Bosmon> I think the two sensible options are i) the method used in the code originally, which just uses "flat property access" and ii) a method allowing "deep property access"
[14:45:20 CDT(-0500)] <cindyli> yes. ur way would allow both
[14:45:27 CDT(-0500)] <cindyli> ok. making change
[14:45:33 CDT(-0500)] <Bosmon> Cheers
[14:52:05 CDT(-0500)] <cindyli> Bosmon: pushed
[14:54:47 CDT(-0500)] <Bosmon> Ok, this is now looking good
[14:54:51 CDT(-0500)] <Bosmon> I will MERGE UP!
[14:54:55 CDT(-0500)] <Bosmon> Thanks for all your work, cindyli
[14:56:20 CDT(-0500)] <anastasiac> cindyli, I have a question about the prefix and relativePrefix of the fatPanel
[14:56:24 CDT(-0500)] <anastasiac> these lines: https://github.com/cindyli/infusion/blob/FLUID-4353/src/webapp/demos/uiOptions/FatPanelUIOptions/js/fatPanelUIOptions.js#L25-26
[14:56:50 CDT(-0500)] <cindyli> sure, anastasiac
[14:57:06 CDT(-0500)] <Bosmon> ack, merge conflict...
[14:57:10 CDT(-0500)] <Bosmon> Haven't had one of these in a long time
[14:57:27 CDT(-0500)] <cindyli> Bosmon: conflict with merging in project repo master?
[14:57:31 CDT(-0500)] <Bosmon> yes
[14:57:38 CDT(-0500)] <anastasiac> looking at the source, it seems that relativePrefix is an option of fatpanel, but prefix is an option of the renderIFrame - how does it work to put the prefix at the top level??
[14:57:39 CDT(-0500)] <cindyli> ok, let me find out
[14:58:03 CDT(-0500)] <anastasiac> ah, meeting, I'll check in later
[14:58:33 CDT(-0500)] <Bosmon> It's ok, I will try to sort it out
[14:59:37 CDT(-0500)] <cindyli> Bosmon: seems I messed up somewhere at merging in master
[14:59:42 CDT(-0500)] <cindyli> i will fix it up
[15:00:09 CDT(-0500)] <Bosmon> It's ok, it is just the test file
[15:00:18 CDT(-0500)] <Bosmon> I assume I can just resolve the conflict in favour of your branch version?
[15:00:39 CDT(-0500)] <cindyli> yes, my version
[15:01:55 CDT(-0500)] <Bosmon> ok
[15:01:57 CDT(-0500)] <Bosmon> JT JS PUSHED!
[15:02:13 CDT(-0500)] <cindyli> cool!!! hoooo raayyyy
[15:03:43 CDT(-0500)] <Bosmon> I declare this component officially FROZZEN
[15:03:47 CDT(-0500)] <Bosmon> and may GODD bless all who sail in her
[15:05:36 CDT(-0500)] <cindyli> :-D
[15:07:24 CDT(-0500)] <cindyli> Bosmon: can u answer anastasiac's question above. i also have a doubt why prefix goes into renderIFrame url
[15:07:46 CDT(-0500)] <cindyli> unless iframe html always sits together with templates in the same directory
[15:07:53 CDT(-0500)] <Bosmon> Well, it may or it may not
[15:08:08 CDT(-0500)] <Bosmon> Following our strategy, the user is free to use the prefix in the URL if they want to, by writing %prefix/
[15:08:11 CDT(-0500)] <Bosmon> Otherwise it will be ignored
[15:09:04 CDT(-0500)] <cindyli> ok. makes sense
[15:10:07 CDT(-0500)] <cindyli> Bosmon: prefix is the relative url from main html to template, which acts same across 3 versions of ui options
[15:10:23 CDT(-0500)] <cindyli> what is "relativePrefix" relative to?
[15:10:42 CDT(-0500)] <Bosmon> relativePrefix is the transformed version of prefix, relative to the iframe location
[15:10:48 CDT(-0500)] <Bosmon> It should mostly be an internal option only
[15:11:21 CDT(-0500)] <cindyli> i see it's calcaulated based on 2 urls and the prefix
[15:11:28 CDT(-0500)] <Bosmon> yes
[15:12:03 CDT(-0500)] <cindyli> so, the user's options on "relativePrefix" would not take effect at all?
[15:12:08 CDT(-0500)] <Bosmon> Perhaps not
[15:12:16 CDT(-0500)] <cindyli> if so, should we remove it from the fatPanel.js
[15:12:20 CDT(-0500)] <Bosmon> I don't think so, with the current implementation
[15:12:34 CDT(-0500)] <Bosmon> I guess we should consider whether we ever want this to be possible
[15:12:47 CDT(-0500)] <Bosmon> it is possible that the automatic calculation might give an incorrect answer
[15:14:08 CDT(-0500)] <cindyli> in the case that the calculated url is wrong, the rest script will still proceed with the wrong
[15:14:19 CDT(-0500)] <Bosmon> Well, right now it will
[15:14:24 CDT(-0500)] <cindyli> i don't see that the user's "relativePrefix" would have a chance to override
[15:14:37 CDT(-0500)] <Bosmon> The decision to be made is whether we think it is worth trying to alter the implementation so that it can be overridden
[15:14:52 CDT(-0500)] <cindyli> a future step
[15:23:01 CDT(-0500)] <Bosmon> A Latin word, a Greek remark, and one, that's, French
