fluid-work IRC Logs-2011-05-13

Owned by Fluid IRC Log Bot
Last updated: May 13, 2011Version comment
45 min read

[09:00:02 CDT(-0500)] <heidi> hey Justin_o re: private functions within finalInit - that they way we do it?
[09:00:28 CDT(-0500)] <heidi> also, i think that's totally why that.locate() isn't working - the button isn't within the container, so finding the button that way won't work.... i didn't know that about that.locate
[09:00:33 CDT(-0500)] <Justin_o> if they're private they don't have to be there
[09:00:44 CDT(-0500)] <Justin_o> although we are currently trying not to use too many if any private functions
[09:00:58 CDT(-0500)] <heidi> Justin_o so functions within finalInit are public?
[09:01:24 CDT(-0500)] <Justin_o> I guess i don't think there is a need to put them there if they are private
[09:01:35 CDT(-0500)] <Justin_o> putting something in there, won't automatically make them public though
[09:01:56 CDT(-0500)] <heidi> Justin_o i'm confused - where should component functions go? it seems like the standard is to put them within finalInit
[09:02:05 CDT(-0500)] <Justin_o> so for your slidingPanel.. that.togglePanel is public because you've attached it to the "that"
[09:02:07 CDT(-0500)] <Justin_o> or the compoennt
[09:02:26 CDT(-0500)] <heidi> ah, so it's not a public/private thing - just an organisation issue
[09:02:34 CDT(-0500)] <Justin_o> sort of
[09:02:36 CDT(-0500)] <Justin_o> i guess so
[09:03:10 CDT(-0500)] <heidi> Justin_o re: the that.locate issue. right now i have a div called "myUIOptions" that contains UIO and a bar with a button below it that controls showing/hiding it
[09:03:11 CDT(-0500)] <Justin_o> heidi: i think any hanging off of a "that" is like an instance method.. since you will need an instance of the component to access that function
[09:03:18 CDT(-0500)] <heidi> so the button isn't within the myUIO container
[09:03:46 CDT(-0500)] <heidi> Justin_o interesting... i should read up on that more
[09:04:25 CDT(-0500)] <heidi> anastasiac so my that.locate issue what that that.locate only works within the container of the component. i guess that
[09:04:33 CDT(-0500)] <heidi> that's true for all framework functions?
[09:04:48 CDT(-0500)] <Justin_o> heidi: is it possible to move the button to be inside of the component?
[09:05:47 CDT(-0500)] <heidi> Justin_o will have to figure out a way... or put a container around all of it and send that to the component.... and instead of hiding/showing the container, we hide/show a diff selector
[09:06:08 CDT(-0500)] <heidi> Justin_o i'll try reworking it - thanks so much, that really helps!
[09:06:31 CDT(-0500)] <heidi> Justin_o dare do look at my tab component? (big grin) so the issue with that is to find a way to figure out which "li" was clicked
[09:07:28 CDT(-0500)] <heidi> w/o using "this"
[09:08:58 CDT(-0500)] <Justin_o> heidi: (smile) okay.. i'll check that out now.. also another suggestion for the sliding panel.. you may want to expose the code that handles the showing and hiding behaviour as public functions too.. right now you have the single toggle function but i think it would be nice to be able to just call open or close as well
[09:10:00 CDT(-0500)] <heidi> Justin_o i thought about that. trying to figure out how that'd be useful... since you only want to hide if it's shown and show if it's hidden?
[09:12:15 CDT(-0500)] <Justin_o> heidi: sometimes it's nice to be explicit about your action.. another question.. slightly related.. how would someone know what state it's in... programmatically that is?
[09:13:14 CDT(-0500)] <heidi> Justin_o ah, like that would be a useful thing for someone to check. like i should set a var to be that value?
[09:14:40 CDT(-0500)] <Justin_o> heidi: it might be useful, not entirely sure.. i'm sort of thinking about unit tests and such at the moment.. i don't suppose you've written any yet
[09:15:01 CDT(-0500)] <heidi> Justin_o noooo. i'm bad! i should do that :o
[09:15:12 CDT(-0500)] <Justin_o> heidi: (smile) it's easy to forget
[09:15:14 CDT(-0500)] <heidi> but yeah, good point... this is so helpful... thanks
[09:15:37 CDT(-0500)] <heidi> Justin_o thoughts on where this component should live? UIO doesn't seem quite right
[09:16:23 CDT(-0500)] <Justin_o> heidi: i'm not quite sure yet... i think maybe for now you could move it out to it's own file under ui options.. and then we can think of a more permanent home later
[09:16:34 CDT(-0500)] <heidi> Justin_o that's a good plan
[09:35:19 CDT(-0500)] <harriswong> mlam, Justin_o: not sure if this has been mentioned... 1.6.1 has been officially released.
[09:35:31 CDT(-0500)] <mlam> cool, thanks harriswong
[09:58:12 CDT(-0500)] <Justin_o> harriswong: sorry, missed your message.. thanks
[10:13:19 CDT(-0500)] <Justin_o> harriswong, mlam : updated FLUID-4113 to reflect that we are upgrading to 1.6.1 and that it is a blocker for 1.4
[10:13:31 CDT(-0500)] <Justin_o> heidi: so we were talking about the tabs component in ui options..
[10:13:36 CDT(-0500)] <mlam> ok, thanks Justin_o
[10:13:42 CDT(-0500)] <harriswong> justin_o: k, should we change the title of the 4113 jira? it's misleading
[10:13:51 CDT(-0500)] <Justin_o> harriswong: yes.. that's what i did
[10:13:58 CDT(-0500)] <harriswong> justin_o:^oh you did. lol. htanks.
[10:14:15 CDT(-0500)] <heidi> Justin_o yeah, i think it prob makes sense to use JQUI tabs, esp if they're accessible
[10:14:26 CDT(-0500)] <heidi> we're using it in our demos already
[10:14:40 CDT(-0500)] <Justin_o> heidi: so i think it might make sense to use jQuery UI's tab widget... we might want to wrap it up in a small fluid component though
[10:14:53 CDT(-0500)] <Justin_o> heidi: yep
[10:15:01 CDT(-0500)] <Justin_o> that's right
[10:15:08 CDT(-0500)] <heidi> Justin_o i'm assuming they're easily styled? will have to look like james's mockups
[10:15:17 CDT(-0500)] <Justin_o> heidi: oh.. that's a good question
[10:15:29 CDT(-0500)] <heidi> maybe i should try it out
[10:15:52 CDT(-0500)] <heidi> Justin_o the tab component i started was building off of FSS's fl-tabs
[10:15:55 CDT(-0500)] <Justin_o> i mean you could use themeroller i guess.. not sure how customizable you can get though, but it would provide a base to look at anyways
[10:16:09 CDT(-0500)] <heidi> yeah don't think themeroller would do it?
[10:16:24 CDT(-0500)] <heidi> but might be able to override it
[10:16:41 CDT(-0500)] <heidi> Justin_o i think it might change our approach to FSS fl-tabs too
[10:16:47 CDT(-0500)] <heidi> if we adopt JQUI as our "tabbing" thing
[10:16:59 CDT(-0500)] <harriswong> Justin_o: Is UIOptions-test hanging on Chrome a known issue?
[10:17:01 CDT(-0500)] <Justin_o> heidi: possibly
[10:17:22 CDT(-0500)] <Justin_o> harriswong: hmm.. not sure..
[10:17:29 CDT(-0500)] <Justin_o> are you doing it locally or through a server?
[10:17:32 CDT(-0500)] <heidi> harriswong i think there are some UIO test fixes needed, right cindyli?
[10:17:40 CDT(-0500)] <heidi> was a jira for it...
[10:17:52 CDT(-0500)] <cindyli> exactly, heidi
[10:18:11 CDT(-0500)] <harriswong> Justin_o: locally. O, ok, so it's not because of 1.6.1, nice! Thanks heidi, cindyli
[10:18:14 CDT(-0500)] <cindyli> harriswong: that's not a known issue as i know
[10:18:24 CDT(-0500)] <harriswong> cindyli: o......
[10:18:47 CDT(-0500)] <Justin_o> harriswong: one of the ui option tests uses ajax to bring in the preview i think.. so that probably won't run locally in chrome
[10:19:20 CDT(-0500)] <harriswong> Justin_o: sorry i meant localhost as locally, apology for introducing confusion..
[10:19:40 CDT(-0500)] <Justin_o> harriswong: oh okay
[10:19:44 CDT(-0500)] <Justin_o> well that should probably have worked
[10:19:50 CDT(-0500)] <harriswong> Justin_o, cindyli: I ran http://build.fluidproject.org/infusion/tests/component-tests/uiOptions/html/UIOptions-test.html on chrome and it hangs.
[10:20:26 CDT(-0500)] <harriswong> Justin_o: i believe it also affects safari
[10:20:42 CDT(-0500)] <Justin_o> harriswong, cindyli: the preview window at the bottom says it can't find the requested url
[10:20:47 CDT(-0500)] <Justin_o> i wonder if the path is wrong
[10:21:18 CDT(-0500)] <harriswong> cindiyli, justin_o: more info: GET http://build.fluidproject.org/infusion/tests/component-tests/uiOptions/html/UIOptionsPreview.html 404 (Not Found)
[10:22:02 CDT(-0500)] <harriswong> it says, "The requested URL /infusion/tests/component-tests/uiOptions/html/UIOptionsPreview.html was not found on this server."
[10:23:13 CDT(-0500)] <cindyli> harriswong: should it be infusion/src/webapp/tests/...
[10:23:19 CDT(-0500)] <cindyli> checking
[10:24:22 CDT(-0500)] <Justin_o> cindyli, harriswong : maybe it should be pointing at this http://build.fluidproject.org/infusion/tests/component-tests/uiOptions/html/TestPreviewTemplate.html
[10:26:24 CDT(-0500)] <harriswong> Justin_o: i don't understand why it passes on FF though
[10:27:37 CDT(-0500)] <Justin_o> harriswong: good question
[10:29:32 CDT(-0500)] <cindyli> harriswong: Justin_o, i produce the same with my localhost in chrome. looking into it
[10:30:53 CDT(-0500)] <harriswong> cindyli: thanks!
[10:31:00 CDT(-0500)] <cindyli> np, harriswong
[10:49:08 CDT(-0500)] <colinclark> heidi: I'm just catching up the IRC logs from this morning
[10:49:11 CDT(-0500)] <michelled> cindyli: I have that cspace meeting in a few minutes and then I'm going to grab some lunch. After that we can talk about UI Options if you'd like
[10:49:29 CDT(-0500)] <colinclark> Saw your questions about where component methods go, as well as about the DOM Binder (i.e. that.locate())
[10:49:36 CDT(-0500)] <cindyli> awesome, michelled, thx
[10:49:40 CDT(-0500)] <colinclark> Did you get good answer to those questions, or can I help clarify?
[10:50:15 CDT(-0500)] <cindyli> colinclark: talking with me?
[10:50:23 CDT(-0500)] <colinclark> cindyli: Sorry, no
[10:50:28 CDT(-0500)] <colinclark> I was talking to heidi
[10:50:35 CDT(-0500)] <colinclark> but I think she's talking to jameswy
[10:50:38 CDT(-0500)] <colinclark> so no worries (smile)
[10:50:46 CDT(-0500)] <cindyli> ha. ic. no wonder i was lost
[10:50:48 CDT(-0500)] <cindyli> (smile)
[10:50:50 CDT(-0500)] <colinclark> lol
[10:50:55 CDT(-0500)] <colinclark> welcome to the club (tongue)
[10:50:59 CDT(-0500)] <colinclark> hey king Justin_o
[10:51:00 CDT(-0500)] <cindyli> sure
[10:51:05 CDT(-0500)] <Justin_o> colinclark: hello
[10:51:26 CDT(-0500)] <colinclark> I realized I am sitting on the notes from Wednesday's dev meeting
[10:51:40 CDT(-0500)] <colinclark> and that we haven't sent a note out to fluid-work about our impending testing sprint and bug parade
[10:51:52 CDT(-0500)] <Justin_o> colinclark: yes.. you're right
[10:51:54 CDT(-0500)] <colinclark> Should I send something to the list?
[10:51:59 CDT(-0500)] <Justin_o> i should do that today
[10:51:59 CDT(-0500)] <colinclark> Or would you prefer to do it?
[10:52:10 CDT(-0500)] <colinclark> okay
[10:52:19 CDT(-0500)] <heidi> colinclark sort of - i've learned that.locate won't work outside of a component container - i'm guessing that's true for all framework functions?
[10:52:19 CDT(-0500)] <colinclark> I'll send the notes our from our meeting
[10:52:29 CDT(-0500)] <colinclark> you can tell everyone about the sprint and bug parade, Justin_o
[10:52:35 CDT(-0500)] <Justin_o> colinclark: will do
[10:52:39 CDT(-0500)] <colinclark> heidi: Nope, not really
[10:53:14 CDT(-0500)] <colinclark> I'll elaborate...
[10:53:16 CDT(-0500)] <heidi> er... all helpering things like dombinder and change applier?
[10:53:26 CDT(-0500)] <colinclark> Nope, not that either (smile)
[10:53:30 CDT(-0500)] <heidi> haha ok
[10:53:40 CDT(-0500)] <colinclark> So, this is really just a characteristic of the DOM Binder
[10:53:48 CDT(-0500)] <colinclark> The point of a component is to be totally self contained
[10:54:04 CDT(-0500)] <colinclark> We found a lot of JavaScript widgets had big problems when they were combined with other widgets
[10:54:10 CDT(-0500)] <colinclark> because they thought they had free reign over the whole page
[10:54:17 CDT(-0500)] <colinclark> but as we've seen a lot, people tend to combine stuff
[10:54:22 CDT(-0500)] <heidi> makes sense
[10:54:25 CDT(-0500)] <colinclark> a portal or a mashup is probably the most extreme example
[10:54:45 CDT(-0500)] <colinclark> So what we did is to encourage components to stay within their own little markup "sandbox"
[10:54:53 CDT(-0500)] <colinclark> Obviously there's nothing stopping them from breaking out of it
[10:55:00 CDT(-0500)] <colinclark> but it's usually a sign of some refactoring needed if they do
[10:55:17 CDT(-0500)] <colinclark> So a View is given a container, and that container is supposed to scope all of its access to the DOM
[10:55:26 CDT(-0500)] <colinclark> So that.locate(), by default, does exactly what you noticed
[10:55:30 CDT(-0500)] <colinclark> search for stuff within the container
[10:55:43 CDT(-0500)] <colinclark> There is an optional second argument...
[10:56:52 CDT(-0500)] <colinclark> Nope, the second argument can be a different container
[10:57:03 CDT(-0500)] <colinclark> But again, you should only use it if you're really, really sure you need to
[10:57:14 CDT(-0500)] <colinclark> It's generally a sign of some refactoring if you need to use the second argument
[10:57:19 CDT(-0500)] <colinclark> or that you're doing something exceedingly fancy
[10:57:24 CDT(-0500)] <heidi> colinclark oh, does that mean i could specify/use a selector that's not in the component container?
[10:57:32 CDT(-0500)] <colinclark> yep
[10:57:39 CDT(-0500)] <heidi> but our doc should still discourage it
[10:57:59 CDT(-0500)] <colinclark> Yes, definitely
[10:58:09 CDT(-0500)] <colinclark> because it runs the risk that you'll bash into someone else in the DOM
[10:58:10 CDT(-0500)] <heidi> k gotcha.
[10:58:16 CDT(-0500)] <heidi> ya
[10:58:22 CDT(-0500)] <colinclark> So, in your particular case, how come you need to reach outside of the component's container?
[10:58:59 CDT(-0500)] <heidi> well, i'm going to change it so i don't (smile) but before i had a container of stuff, and then a bar + button that would open/close the container
[10:59:16 CDT(-0500)] <colinclark> Ah, cool
[10:59:19 CDT(-0500)] <heidi> but everything should go into one div, and then an option for the panel can be what you open/close
[10:59:30 CDT(-0500)] <colinclark> ok
[10:59:36 CDT(-0500)] <colinclark> I look forward to seeing it
[10:59:44 CDT(-0500)] <heidi> yeah i'm moving slow, but surely
[10:59:47 CDT(-0500)] <heidi> it's fun
[10:59:58 CDT(-0500)] <heidi> i'll be in a better position to help with the "creating a component" docs for sure
[11:00:20 CDT(-0500)] <Justin_o> colinclark, heidi: did you have a minute to chat about the tabs stuff?
[11:00:29 CDT(-0500)] <heidi> colinclark any thoughts on jquery UI tabs vs. our own tabs ... Justin_o ...there he is
[11:02:04 CDT(-0500)] <Justin_o> heidi: did you also want to mention your thoughts about fss-tab styling
[11:02:49 CDT(-0500)] <heidi> just that the component was using those... and that choosing JUI tabs as our "tab thing" might change our approach to fl-tabs in fss
[11:03:13 CDT(-0500)] <heidi> i.e. fluid tab code and tab fss styles should line up
[11:03:30 CDT(-0500)] <colinclark> sure, I have a sec
[11:03:36 CDT(-0500)] <colinclark> just don't tell mlam (tongue)
[11:03:50 CDT(-0500)] <colinclark> he's been waiting a long time for this merge (wink)
[11:04:07 CDT(-0500)] <Justin_o> mlam: sorry
[11:04:09 CDT(-0500)] <colinclark> These are tabs in the new UIO design?
[11:04:13 CDT(-0500)] <mlam> Nooo! j/k (smile)
[11:04:20 CDT(-0500)] <heidi> colinclark ya for the panels
[11:04:34 CDT(-0500)] <colinclark> lemme fire up the wireframes
[11:04:45 CDT(-0500)] <colinclark> i have them constantly open in a special tab
[11:04:48 CDT(-0500)] <colinclark> the jameswy tab
[11:04:59 CDT(-0500)] <jameswy> Haha.
[11:05:15 CDT(-0500)] <colinclark> So this is really fascinating
[11:05:32 CDT(-0500)] <heidi> i'm wondering if we can tweak jquery ui tabs enough to look jameswy-y
[11:05:47 CDT(-0500)] <colinclark> So, these are not tabs visually
[11:05:55 CDT(-0500)] <colinclark> but they sort of seem like they are, interaction-wise
[11:06:02 CDT(-0500)] <colinclark> except I guess you can ultimately have no panels showing?
[11:06:05 CDT(-0500)] <colinclark> jameswy: ^
[11:06:07 CDT(-0500)] <heidi> not tabs visually?
[11:06:18 CDT(-0500)] <colinclark> Well, they're more like a weird kind of menu bar
[11:06:20 CDT(-0500)] <heidi> at least one panel is visible
[11:06:26 CDT(-0500)] <colinclark> At all times?
[11:06:32 CDT(-0500)] <heidi> yeah
[11:06:41 CDT(-0500)] <colinclark> But there are wireframes here with no panels showing
[11:06:43 CDT(-0500)] <colinclark> just the bottom menu
[11:06:46 CDT(-0500)] <colinclark> (or top)
[11:06:49 CDT(-0500)] <heidi> ah, check fat panel
[11:07:05 CDT(-0500)] <jameswy> colinclark, heidi: It depends which mockup you look at. But yes, the point is that the interaction is the same, but that it's styled either as tab panels or menu navs.
[11:07:07 CDT(-0500)] <colinclark> Ah!
[11:07:07 CDT(-0500)] <heidi> those we should consider its use for skinny panel as well
[11:07:14 CDT(-0500)] <heidi> *tho
[11:07:19 CDT(-0500)] <colinclark> Aha
[11:07:26 CDT(-0500)] <colinclark> So fat panel is awfully tabby, you're right
[11:08:38 CDT(-0500)] <heidi> i wonder if an added benefit to our own tabs would be the ability to tweak for skinny panel...
[11:09:03 CDT(-0500)] <heidi> maybe this is less a general tabs component and more a UIOMenu component
[11:10:28 CDT(-0500)] <colinclark> It's possible
[11:10:34 CDT(-0500)] <colinclark> I just chatted with jameswy in person
[11:10:42 CDT(-0500)] <colinclark> since I was confused by his last statement
[11:10:47 CDT(-0500)] <colinclark> but as always, he is totally correct
[11:10:51 CDT(-0500)] <colinclark> right, jameswy?
[11:11:41 CDT(-0500)] <colinclark> So, fat panel is unambiguously tabby
[11:11:42 CDT(-0500)] <jameswy> Hahaha. If only.
[11:11:54 CDT(-0500)] <colinclark> So, heidi's point is interesting...
[11:12:07 CDT(-0500)] <colinclark> Could we eventually use the same component for skinny panel and fat panel?
[11:12:23 CDT(-0500)] <colinclark> Justin_o: What was your argument for using the jQuery UI tabs widget?
[11:12:59 CDT(-0500)] <heidi> is that too much diff functionality in one thing tho? the fat or skinny panel could make use of two diff components... tabs or menu nav if needed
[11:13:11 CDT(-0500)] <Justin_o> colinclark: not too much of an argument really.. just that it does what we need already, at least for the fat panel version
[11:13:18 CDT(-0500)] <colinclark> yeah
[11:13:31 CDT(-0500)] <colinclark> heidi: You nailed it... that's exactly the right question
[11:13:50 CDT(-0500)] <heidi> i see both being useful outside of UIO
[11:13:54 CDT(-0500)] <colinclark> Without looking into it much more deeply--i.e. trying to implement something, I guess we might not know what's different about each implementation
[11:14:09 CDT(-0500)] <colinclark> Superficially it sure does look like the tabs and the menu-y thing are pretty much the same
[11:14:12 CDT(-0500)] <colinclark> so one component would be great
[11:14:17 CDT(-0500)] <colinclark> I'm tempted to go with Justin_o's idea...
[11:14:24 CDT(-0500)] <colinclark> Let's use the jQuery UI tabs to start
[11:14:47 CDT(-0500)] <colinclark> But I'm flexible
[11:14:58 CDT(-0500)] <colinclark> Justin_o: I guess the question is whether you'd want us to have any kind of adaptor around it
[11:15:02 CDT(-0500)] <colinclark> like we did with the tooltip
[11:15:07 CDT(-0500)] <heidi> colinclark what do you think about its disassociation with fss fl-tabs?
[11:15:25 CDT(-0500)] <colinclark> Well, it's sort of disappointing
[11:15:31 CDT(-0500)] <colinclark> We have a tabs component that is quite nice already
[11:15:48 CDT(-0500)] <colinclark> but I guess I'm not super-keen on competing side-by-side with jQuery UI if we can avoid it
[11:15:57 CDT(-0500)] <Justin_o> colinclark: yes.. i was thinking we should wrap it.. that will make it easier to switch later if want to
[11:16:27 CDT(-0500)] <colinclark> So, as I say, I'm flexible...
[11:16:40 CDT(-0500)] <heidi> and we'll cross the skinny panel menu bridge when we get to it? sounds fine by me
[11:16:47 CDT(-0500)] <colinclark> heidi and Justin_o and jameswy: what are your final thoughts?
[11:17:41 CDT(-0500)] <heidi> i'd like fl-tabs to be more useful to someone, but i think using existing awesome code trumps that... and i might be able to combine the two somehow...
[11:17:53 CDT(-0500)] <Justin_o> colinclark: currently my vote would be to use the jquery ui tabs inside of a wrapper/adaptor
[11:18:12 CDT(-0500)] <heidi> i'll try making jquery ui tabs match jameswy's layout and see if that works well
[11:18:30 CDT(-0500)] <Justin_o> heidi: yes.. the styling may be the most difficult part
[11:18:31 CDT(-0500)] <heidi> i don't really get the adaptor thing
[11:18:52 CDT(-0500)] <colinclark> heidi: The idea of an adaptor would be to wrap the jQuery UI Tabs widget
[11:19:01 CDT(-0500)] <colinclark> so that it had an Infusion-ish, stable API
[11:19:28 CDT(-0500)] <colinclark> so that, if when we get to the skinny panel we need to change it out for something more robust, we can do it without having to change code in lots of places
[11:19:41 CDT(-0500)] <heidi> interesting. do we have other wrapped jquery ui components?
[11:19:46 CDT(-0500)] <colinclark> The tooltip, yes
[11:19:49 CDT(-0500)] <heidi> k
[11:20:01 CDT(-0500)] <jameswy> I don't have an opinion on what tabs widget we should use, but I do hope whatever we end up choosing has great flexibility in styling (and sliding tab animations)
[11:20:02 CDT(-0500)] <colinclark> Justin_o: You should probably argue for your adaptor idea, though (smile)
[11:21:25 CDT(-0500)] <Justin_o> colinclark: i think you about covered it (smile)
[11:22:58 CDT(-0500)] <colinclark> lol
[11:24:54 CDT(-0500)] <Justin_o> heidi: let me know if you have any questions, need help with, or want to pair on any of that stuff
[11:24:59 CDT(-0500)] <heidi> okay thanks all... we'll go w jquery ui tabs... justin_o i guess we can move it to /lib and change the demos to use that
[11:25:12 CDT(-0500)] <Justin_o> heidi: yes.. that would be good idea
[11:26:18 CDT(-0500)] <heidi> Justin_o k i'm gonna fix up sliding panel component and then start using the jq tabs
[11:26:33 CDT(-0500)] <heidi> Justin_o i'm not sure if you have time, but do oyu want to play with the livePreview component?
[11:26:49 CDT(-0500)] <heidi> it's started, in that file you got from my github
[11:27:45 CDT(-0500)] <Justin_o> heidi: okay i'll take a look... what needs to be done for that exactly.. is there a wiki page about it..
[11:27:54 CDT(-0500)] <Justin_o> or specific jira
[11:28:02 CDT(-0500)] <heidi> Justin_o there's a jira ya
[11:28:20 CDT(-0500)] <heidi> basically it treats the page like the preview... when UIO changes, the page live previews it
[11:28:34 CDT(-0500)] <Justin_o> oh right that thing
[11:28:55 CDT(-0500)] <heidi> colinclark started a bit of it - it makes use of some of the existing preview's functionality
[11:35:29 CDT(-0500)] <colinclark> cool
[11:35:36 CDT(-0500)] <colinclark> I'll have a look whenever you want, heidi
[11:35:56 CDT(-0500)] <heidi> thanks colin
[11:36:55 CDT(-0500)] <heidi> so jameswy the issue you were having is from the clear: both on line 14 of FullUIOptions.css
[11:56:24 CDT(-0500)] <Justin_o> fluid-everyone: so an interesting thing has come up. basically working was started on http://issues.fluidproject.org/browse/FLUID-3782 and as the details of it became more clear, separate jiras were filed for the particular work http://wiki.fluidproject.org/display/fluid/UI+Options+1.4+Roadmap
[11:56:43 CDT(-0500)] <Justin_o> however work on many of those things had already started under Fluid-3782
[11:56:53 CDT(-0500)] <Justin_o> and the question now is how to be split these things up.
[11:58:02 CDT(-0500)] <Justin_o> so what had once been an atomic FLUID-3782 branch is now a bit of a tangle of work that would be filed under several jiras.
[11:58:31 CDT(-0500)] <Justin_o> not to mention that the commit logs will be mentioning FLUID-3782 rather than the new specific jiras
[11:58:51 CDT(-0500)] <Justin_o> fluid-everyone: anyone have thoughts on solutions for splitting this apart
[11:59:49 CDT(-0500)] <heidi> jameswy you'll have to split your branch up too
[12:00:38 CDT(-0500)] <clown> Justin_o, heidi, everyone except yura_ and cindyli is out for lunch, here.
[12:00:57 CDT(-0500)] <clown> and, i suppose, me...
[12:01:11 CDT(-0500)] <Justin_o> clown: thanks for letting us know
[12:01:35 CDT(-0500)] <Justin_o> clown: i thought thursday was lunch day?
[12:01:59 CDT(-0500)] <clown> Justin_o: as far as I'm concerned, thu is lunch day.
[12:02:05 CDT(-0500)] <clown> (wink)
[12:03:24 CDT(-0500)] <Justin_o> (wink)
[12:27:03 CDT(-0500)] <heidi> Justin_o should i create a new branch from within FLUID-3782?
[12:27:14 CDT(-0500)] <heidi> or from master, and then copy stuff in?
[12:27:34 CDT(-0500)] <Justin_o> heidi: i'm not sure just yet.. depends on what we decide as a group
[12:27:46 CDT(-0500)] <Justin_o> i think in the mean time though, just start a new branch from master
[12:27:54 CDT(-0500)] <heidi> ok
[12:27:57 CDT(-0500)] <heidi> clean
[12:28:17 CDT(-0500)] <Justin_o> i think if we do it the other way we'll have a bunch of conflicts later when we try to merge them all back together
[12:28:47 CDT(-0500)] <heidi> and i guess i'll merge in FLUID-3782 from the new branch after?
[12:28:47 CDT(-0500)] <Justin_o> heidi: do you happen to know which commit the live preview stuff was in
[12:28:48 CDT(-0500)] <Justin_o> https://github.com/heidiv/infusion/compare/master...FLUID-3782
[12:28:54 CDT(-0500)] <Justin_o> i'm having a bit trouble spotting it
[12:30:05 CDT(-0500)] <heidi> Justin_o commit f0f98a69debbe8b0ad84
[12:30:33 CDT(-0500)] <Justin_o> heidi: thanks
[12:30:43 CDT(-0500)] <heidi> Justin_o i guess another thing with my github is that i use it to work between diff computers, so when i commit something it's not always 'done' or 'working' cos i'm mid-way between work
[12:31:00 CDT(-0500)] <Justin_o> heidi: that's okay
[12:31:49 CDT(-0500)] <Justin_o> heidi: i don't think there is a problem with that, as long as it doesn't make it into the project repo in that state
[12:32:31 CDT(-0500)] <heidi> Justin_o that's why maybe it's weird to include some stuff in the github history? should i be making "working" branches vs normal branches that should have working-ish stuff?
[12:33:22 CDT(-0500)] <Justin_o> heidi: i guess it depends on how fine grained the jira is
[12:33:41 CDT(-0500)] <Justin_o> my guess is that in most cases you wouldn't push something to the project repo till it was completely done anyways
[12:33:43 CDT(-0500)] <heidi> Justin_o i mean in terms of my pushing stuff that's not done thing... to switch comps
[12:34:03 CDT(-0500)] <heidi> but i push to my github daily, regardless of status of the work
[12:34:04 CDT(-0500)] <Justin_o> heidi: i think that's okay.. maybe just make a note of it in the commit log.. or something
[12:34:13 CDT(-0500)] <Justin_o> actually Bosmon used to do this in svn even
[12:34:20 CDT(-0500)] <heidi> a note how?
[12:34:33 CDT(-0500)] <Justin_o> i mean it would be half finished... and pushed
[12:34:42 CDT(-0500)] <heidi> yeah
[12:34:47 CDT(-0500)] <Justin_o> it is your github repo after all.. you can do that
[12:34:57 CDT(-0500)] <heidi> but when that branch is pulled into the repo, all that messy history goes in too?
[12:34:59 CDT(-0500)] <Justin_o> just as long as what finally gets pushed into the project-repo is stable and working
[12:35:27 CDT(-0500)] <Justin_o> heidi: yes.. that's true.. but it's the history of the process... and we've agreed that that can go in
[12:35:45 CDT(-0500)] <Justin_o> we actually had a discussion about that before.. i think michelled felt the same way as you are now
[12:35:56 CDT(-0500)] <heidi> even if it's "i didn't do anything major, but i'm done for the day" kinda commits?
[12:36:27 CDT(-0500)] <Justin_o> heidi: yes.. i think that's fine.. i don't know if I would write it up like that in the commit log (smile) but yah
[12:36:46 CDT(-0500)] <heidi> haha i don't
[12:36:58 CDT(-0500)] <Justin_o> i think a bigger issue would be making a commit without the jira number or something like that
[12:37:00 CDT(-0500)] <Justin_o> or no message
[12:37:03 CDT(-0500)] <colinclark> Justin_o: I'm just catching up on the logs now
[12:37:08 CDT(-0500)] <Justin_o> colinclark: thanks
[12:37:12 CDT(-0500)] <colinclark> We were away to have a celebratory lunch for almondkey
[12:37:41 CDT(-0500)] <Justin_o> colinclark: oh now i feel bad for not being there
[12:38:13 CDT(-0500)] <heidi> oh is it marriage week!
[12:38:56 CDT(-0500)] <colinclark> Justin_o: don't feel bad
[12:39:08 CDT(-0500)] <colinclark> especially considering your foot!
[12:39:36 CDT(-0500)] <colinclark> So, Justin_o and heidi, +1 for using your own fork for whatever you like, and not worrying about the history being messy
[12:39:39 CDT(-0500)] <colinclark> usually it's good history
[12:39:46 CDT(-0500)] <heidi> okee doke
[12:39:55 CDT(-0500)] <Justin_o> colinclark: this might be a bit tricky though
[12:40:05 CDT(-0500)] <colinclark> As for how to split up FLUID-3782, what kind of help can I offer?
[12:40:31 CDT(-0500)] <colinclark> It might not be worth retroactively trying to split it up, but finding a time when the work is relatively stable and then splitting out into sub-branches from there
[12:40:33 CDT(-0500)] <colinclark> or whatever
[12:40:44 CDT(-0500)] <colinclark> usually I defer to Justin_o or michelled for Git advice, since I'm terrified of it, myself (tongue)
[12:41:03 CDT(-0500)] <Justin_o> colinclark: maybe we can talk through the possible solutions a bit
[12:41:30 CDT(-0500)] <Justin_o> here are a few options i can think of
[12:41:53 CDT(-0500)] <Justin_o> 1) create new branches and just copy/paste the relevant code over
[12:42:16 CDT(-0500)] <Justin_o> 2) create new branches for the individual work off of the existing FLUID-3782 branch
[12:42:56 CDT(-0500)] <Justin_o> we could have done something fancy like git-cherry-pick or rebase but i think some of the individual commits themselves are no longer atomic
[12:43:54 CDT(-0500)] <Justin_o> i think if we go with option 2 we should be careful not to remove any of the existing code that other people will continue.. as i imagine that will just result in a lot of merge conflicts
[12:43:58 CDT(-0500)] <Justin_o> although i could be mistaken
[12:45:07 CDT(-0500)] <heidi> i like #1... seems cleanest/easiest?
[12:46:44 CDT(-0500)] <colinclark> Tell me more about your concern for #2, Justin_o
[12:47:15 CDT(-0500)] <Justin_o> so FLUID-3782 now will need to be split into several branches as it has really forked off into several jiras
[12:47:31 CDT(-0500)] <Justin_o> but work for many of those has already started in the current branch
[12:48:18 CDT(-0500)] <Justin_o> so if i wanted to have a clean branch for my new jira and continue on the work that was started. if we go with option 2 I might want to remove all of the other unfinished code for other work
[12:48:50 CDT(-0500)] <jameswy> heidi: I see the issue with the clear: both. But if I don't use it, I run into all sorts of much worse things.
[12:48:54 CDT(-0500)] <Justin_o> but if we did that.. when we go to put these things back together we may have merge conflicts because we'll have commits for removing and working on the same code
[12:48:59 CDT(-0500)] <jameswy> Any suggestions on how to have my cake and eat it too, heidi?
[12:49:10 CDT(-0500)] <Justin_o> in fact we'll have multiple commits for removing the same code (not sure if that will be a problem)
[12:49:22 CDT(-0500)] <heidi> jameswy i guess figure out how it helped before and see if you can use it, but less generally
[12:50:19 CDT(-0500)] <heidi> Justin_o i'm tempted to , in our case, not use FLUID-3782 (i.e. it's not something that will ever be pulled into the repo)
[12:50:23 CDT(-0500)] <Justin_o> colinclark: i made some comments above
[12:50:39 CDT(-0500)] <jameswy> heidi: Cools. Thanks, Heidi.
[12:50:55 CDT(-0500)] <colinclark> Justin_o: Yep, I see your point
[12:51:28 CDT(-0500)] <colinclark> The problem with #1 is, I guess, that it's fairly time consuming and we lose any commit history that goes along with the work that has already been done
[12:51:52 CDT(-0500)] <Justin_o> colinclark: yes... that would be pretty sad.. to lose the history
[12:51:58 CDT(-0500)] <colinclark> So, is it the case that we're at a point where the branch is full of half-finished stuff?
[12:52:12 CDT(-0500)] <colinclark> I'm just wondering if there's a natural stopping point for the current FLUID-3872 anytime soon
[12:52:12 CDT(-0500)] <colinclark> in w
[12:52:12 CDT(-0500)] <colinclark> i
[12:52:21 CDT(-0500)] <colinclark> in which case we could keep going for a little longer
[12:52:28 CDT(-0500)] <Justin_o> jameswy, heidi: any thoughts on that
[12:52:28 CDT(-0500)] <colinclark> then merge, then start working in more atomic branches?
[12:52:41 CDT(-0500)] <Justin_o> colinclark: that would be ideal
[12:52:50 CDT(-0500)] <Justin_o> i guess things would just need to be in a stable condition
[12:54:38 CDT(-0500)] <heidi> mmm... thinking. there's a lot in there
[12:55:12 CDT(-0500)] <jameswy> Justin_o, colinclark, heidi: Agreed, #1sounds like a lot of backward-then-forward busywork.
[12:55:34 CDT(-0500)] <heidi> i'm thinking the component bits (tabs, sliding panel, live preview) can be taken out and put into their own , and the rest left until done-ish ... i.e all our layout work
[12:55:38 CDT(-0500)] <jameswy> I think we're at or very near a natural stopping point for full page UIO w/ or w/out preview
[12:56:28 CDT(-0500)] <Justin_o> heidi: as far as the components go.. i think we would just remove the tabs one for now in FLUID-3782 since i figure that will be a restart either way
[12:56:35 CDT(-0500)] <Justin_o> get the sliding panel relatively stable
[12:56:44 CDT(-0500)] <Justin_o> not sure about the live preview.. does it do anything yet?
[12:56:49 CDT(-0500)] <heidi> no
[12:56:57 CDT(-0500)] <heidi> sounds good
[12:57:35 CDT(-0500)] <heidi> the fat panel look reqs tabs tho
[12:58:35 CDT(-0500)] <heidi> but i can leave it as the non-componenty js that was working before
[12:58:46 CDT(-0500)] <heidi> to be replace by jquery ui tabs
[12:58:54 CDT(-0500)] <Justin_o> colinclark: what do you think.. it's okay if things aren't fully function as long as things aren't flat out broken.. so no tabbing.. you only get one panel for now
[12:59:07 CDT(-0500)] <Justin_o> colinclark: also were you thinking of merging this into trunk.. or just branching off of it
[12:59:09 CDT(-0500)] <heidi> Justin_o what do oyu think of leaving in the plain js
[12:59:12 CDT(-0500)] <heidi> for tabbign
[13:00:25 CDT(-0500)] <Justin_o> heidi: hmm.. not sure..
[13:01:13 CDT(-0500)] <Justin_o> heidi: do we actually need tabbing for any of the other work
[13:01:28 CDT(-0500)] <heidi> Justin_o the tab js would be in the demo js file
[13:01:31 CDT(-0500)] <heidi> no
[13:02:18 CDT(-0500)] <Justin_o> heidi: i guess my preference would be to not leave it in then.. but i'm open to leaving it there as well
[13:02:29 CDT(-0500)] <colinclark> Hey mlam, just an update on where I'm at with FLUID-3886
[13:02:29 CDT(-0500)] <heidi> Justin_o it'd be broken without it
[13:02:32 CDT(-0500)] <colinclark> Everything is looking quite good
[13:02:39 CDT(-0500)] <colinclark> Except wiring up to options backwards compatibility
[13:02:39 CDT(-0500)] <mlam> awesome!
[13:02:47 CDT(-0500)] <colinclark> the biggest challenge being for users who are still using 1.2-era options
[13:03:05 CDT(-0500)] <colinclark> In the IoC way, it isn't apparent to me how I can make multiple transformations happen
[13:03:27 CDT(-0500)] <colinclark> So I think I'm going to extend transformWithRules() to take an array of rules to chain the transformation
[13:03:37 CDT(-0500)] <colinclark> so we could easily go from 1.2 -> 1.3 -> 1.4
[13:03:58 CDT(-0500)] <mlam> will there be a path for directly extending it from 1.2 -> 1.4 ?
[13:04:28 CDT(-0500)] <colinclark> I think the easiest way to do it is to make transformations composable
[13:04:30 CDT(-0500)] <Justin_o> heidi, jameswy: here's my thoughts.. i guess leave the tabs stuff for there now.. get to a break point, and then we'll branch off of fluid-3782 to the individual branches
[13:04:50 CDT(-0500)] <colinclark> meaning you, as a user, can chain together all the transformation rules as needed
[13:05:01 CDT(-0500)] <heidi> Justin_o will fluid-3782 be pulled in or just something we stop working on
[13:05:04 CDT(-0500)] <mlam> ahhh ic i c
[13:05:16 CDT(-0500)] <Justin_o> heidi: i think something we stop working on
[13:05:21 CDT(-0500)] <heidi> k
[13:05:28 CDT(-0500)] <Justin_o> the code from within it will be pulled in from one of the other branches eventually
[13:05:40 CDT(-0500)] <heidi> jameswy and i both have FLUID-3782 branches btw :|
[13:06:31 CDT(-0500)] <jameswy> I think that's okay though, no? It's really just heidi's --I'm feeding my changes to her.
[13:06:58 CDT(-0500)] <heidi> yeah i merge them in, but i don't really get how merges work. is his stuff then part of my branch?
[13:07:12 CDT(-0500)] <Justin_o> heidi: yes
[13:07:14 CDT(-0500)] <heidi> k
[13:07:17 CDT(-0500)] <heidi> then we're good
[13:07:30 CDT(-0500)] <Justin_o> so i guess you'll merge his in and we'll create the forks off of that
[13:07:58 CDT(-0500)] <Justin_o> harriswong, mlam: how is the 1.6.1 upgrade going
[13:08:28 CDT(-0500)] <harriswong> Justin_o: i am working on the focus/focusin problem; i thikn mlam is on uploader
[13:08:31 CDT(-0500)] <heidi> Justin_o did you want to do livepreview in a diff branch?
[13:08:48 CDT(-0500)] <Justin_o> harriswong: uploader for 1.6.1 or uploader in general?
[13:08:53 CDT(-0500)] <harriswong> Justin_o: beside that, we have fixed all the others that failed from the list i had on #4113
[13:08:55 CDT(-0500)] <mlam> Justin_o: 1.6.1
[13:09:12 CDT(-0500)] <Justin_o> heidi: yes.. i'll branch off FLUID-3782 when it's ready
[13:09:23 CDT(-0500)] <heidi> Justin_o should i leave what's in there, there?
[13:09:26 CDT(-0500)] <harriswong> Justin_o: *fixed all the ones that seemed to be introduced by 1.6.1.
[13:09:35 CDT(-0500)] <Justin_o> heidi: you mean for live preview
[13:09:38 CDT(-0500)] <Justin_o> what does it do at the moment
[13:09:41 CDT(-0500)] <heidi> yes
[13:09:47 CDT(-0500)] <heidi> it's started but doesn't work
[13:10:27 CDT(-0500)] <Justin_o> heidi: and i'm guessing it isn't anywhere near a break point?
[13:10:44 CDT(-0500)] <heidi> Justin_o not yet, want to work on it? (smile)
[13:11:10 CDT(-0500)] <Justin_o> heidi: I'd like to work on it.. just wondering how long it will take me to get to the break point.. (smile)
[13:11:21 CDT(-0500)] <heidi> guessing not too long
[13:11:26 CDT(-0500)] <Justin_o> if it's really just at the beginning it might be better to just remove it and start over afterwards
[13:11:28 CDT(-0500)] <Justin_o> okay
[13:11:37 CDT(-0500)] <Justin_o> i'll take a look.. i guess we just need it to do something
[13:24:02 CDT(-0500)] <Justin_o> cindyli, colinclark, heidi: what's the difference between live preview and preview for ui options..
[13:24:25 CDT(-0500)] <heidi> Justin_o preview requires an iframe in which to load a file
[13:24:26 CDT(-0500)] <Justin_o> so i know that the idea is that one works on the current page and one works against a preview window
[13:24:39 CDT(-0500)] <colinclark> one currently exists and the other doesn't yet (smile)
[13:24:44 CDT(-0500)] <heidi> haha
[13:24:45 CDT(-0500)] <Justin_o> colinclark: lol
[13:24:53 CDT(-0500)] <Justin_o> so my question is, why can't they be the same component
[13:25:09 CDT(-0500)] <colinclark> Preview might better be renamed "iFramePreview"
[13:25:09 CDT(-0500)] <heidi> Justin_o mentioned above - preview expects to load a file within a frame
[13:25:10 CDT(-0500)] <Justin_o> seems the only difference would be which uiEnhancer it is working with
[13:25:14 CDT(-0500)] <colinclark> It's very much concerned with iFrame-ism
[13:25:25 CDT(-0500)] <colinclark> Whereas the LivePreview is essentially a no-op preview
[13:25:46 CDT(-0500)] <colinclark> no-op meaning it doesn't do anything except go find the page's UIE and bind it up to UIO's model change events
[13:25:53 CDT(-0500)] <colinclark> Does that make sense at all?
[13:26:15 CDT(-0500)] <colinclark> Justin_o: You're right in principle that the only difference is which UIE it is working with
[13:26:19 CDT(-0500)] <Justin_o> yes.. so preview is actually live preview plus go load an iframe and work with that uienhancer instead
[13:26:20 CDT(-0500)] <Justin_o> ?
[13:26:21 CDT(-0500)] <colinclark> in practice there are some lifecycle concerns
[13:26:25 CDT(-0500)] <colinclark> yep
[13:26:26 CDT(-0500)] <colinclark> exactly
[13:26:46 CDT(-0500)] <colinclark> We can do pretty much what you're suggesting
[13:27:00 CDT(-0500)] <colinclark> So, some quick background info
[13:27:09 CDT(-0500)] <colinclark> The global UIE currently does something fairly underhanded
[13:27:23 CDT(-0500)] <colinclark> Upon creation, it hides itself in the DOM on the Document element using jQuery.data()
[13:27:45 CDT(-0500)] <colinclark> So Preview and UIO are forced to go rummaging around in the DOM to find it
[13:27:50 CDT(-0500)] <colinclark> That's one line of code
[13:27:50 CDT(-0500)] <cindyli> HI, Bosmon, r u there?
[13:28:03 CDT(-0500)] <colinclark> but what we want is to store the global UIE in the appropriate spot
[13:28:15 CDT(-0500)] <colinclark> which, since it's global to the whole page, is the staticEnvironment
[13:28:27 CDT(-0500)] <colinclark> at that point, we can throw out the last of LivePreview's code
[13:28:30 CDT(-0500)] <colinclark> and it will just be configuration
[13:28:48 CDT(-0500)] <colinclark> Which would allow us, I think, to actually compose iFramePreview from LivePreview
[13:28:55 CDT(-0500)] <colinclark> So we might be best to flip the names around
[13:29:03 CDT(-0500)] <colinclark> Calling LivePreview just "Preview"
[13:29:11 CDT(-0500)] <colinclark> and calling Preview "iFramePreview"
[13:29:11 CDT(-0500)] <Bosmon> Yes, I am here
[13:29:28 CDT(-0500)] <colinclark> and then have iFramePreview just be a composition of Preview and the stupid iFrame-specific stuff
[13:29:40 CDT(-0500)] <colinclark> which is really just a bit of configuration in the form of createOnEvent
[13:29:48 CDT(-0500)] <colinclark> Look, it's Bosmon
[13:31:18 CDT(-0500)] <Justin_o> colinclark: so the only thing that is currenlty holding us back is the bug in uiOptions that sets the uienhancer to the document?
[13:32:03 CDT(-0500)] <colinclark> Pretty well, yes
[13:32:10 CDT(-0500)] <colinclark> Doesn't the UIE put itself on the Document?
[13:32:19 CDT(-0500)] <colinclark> and then UIO and Preview go and find it?
[13:32:23 CDT(-0500)] <colinclark> I don't have the code open at the moment
[13:33:08 CDT(-0500)] <Justin_o> colinclark: http://issues.fluidproject.org/browse/FLUID-4205
[13:33:48 CDT(-0500)] <colinclark> I'm not sure this bug report entirely makes sense
[13:34:03 CDT(-0500)] <colinclark> but i have a meeting
[13:34:06 CDT(-0500)] <colinclark> I'll be back
[13:34:34 CDT(-0500)] <Justin_o> colinclark: okay.. i'll start working with it as is then
[13:36:38 CDT(-0500)] <colinclark> anastasiac: Is this a recent bug you filed?
[13:37:06 CDT(-0500)] <anastasiac> colinclark, yes, I noticed it when putting together the new test page
[13:37:17 CDT(-0500)] <colinclark> Can you elaborate on what you think the actual bug is?
[13:41:40 CDT(-0500)] <anastasiac> well, the UIOptions component assumes a fixed location for finding the Enhancer, and the Enhancer could conceivably put it in different places. That's the problem. We'll have to think about which component is doing the "wrong thing."
[13:44:59 CDT(-0500)] <colinclark> What are the use cases for a UIE being put in another location, anastasiac?
[13:45:10 CDT(-0500)] <colinclark> Or, I guess I should put it differently
[13:45:17 CDT(-0500)] <colinclark> Why would the UIE be put into a different location?
[13:46:23 CDT(-0500)] <anastasiac> I'm not sure there is such a use case. If we think about it and decide that it would never happen, then the problem is that the UI Enhancer actually supports other containers (and puts itself onto the container)
[13:46:57 CDT(-0500)] <colinclark> I'm not sure that's the case either
[13:47:03 CDT(-0500)] <colinclark> if you have a look at the code (smile)
[13:47:33 CDT(-0500)] <colinclark> The real bug here is that the page-level UIE is placed into the DOM, rather than into the staticEnvironment where it can be resolved via IoC
[13:47:43 CDT(-0500)] <colinclark> So, UIO in some forms has two UIEs
[13:47:45 CDT(-0500)] <colinclark> One for the page
[13:47:47 CDT(-0500)] <colinclark> and one for the preview
[13:48:00 CDT(-0500)] <colinclark> Meaning, UIE needs to support a parameterized container
[13:48:39 CDT(-0500)] <colinclark> The issue you're pointing out is that there is a hard-baked assumption that the global, page-level UIE is stored in the DOM on the document
[13:50:10 CDT(-0500)] <jameswy> heidi: Fixed the vertical alignment issue.
[13:50:17 CDT(-0500)] <jameswy> Thanks for pointing out that it was the clear property!
[13:50:41 CDT(-0500)] <heidi> jameswy rad! yr a css pro now
[14:05:28 CDT(-0500)] <Justin_o> heidi: have you noticed that there is an arrow on the demo page for the fat panel
[14:05:55 CDT(-0500)] <heidi> Justin_o hm?
[14:06:08 CDT(-0500)] <heidi> beside 'reset all' ?
[14:06:23 CDT(-0500)] <Justin_o> heidi: (wink) i wrote arrow instead of error
[14:06:25 CDT(-0500)] <Justin_o> oops
[14:06:37 CDT(-0500)] <Justin_o> i think that's one of my funnier spelling mistakes
[14:06:37 CDT(-0500)] <heidi> haha Justin_o yeah it's cos it's looking for the preview frame
[14:06:59 CDT(-0500)] <Justin_o> heidi: are you sure.. because you have it set to use the live preview i think
[14:07:15 CDT(-0500)] <heidi> Justin_o yeah i've set it but it's not working...
[14:07:20 CDT(-0500)] <jhung> anastasiac: can I pick your metadata brain?
[14:07:21 CDT(-0500)] <heidi> not sure if i did it right
[14:07:42 CDT(-0500)] <Justin_o> heidi: i think it might be because the markup for the fat panel doesn't have a form
[14:08:04 CDT(-0500)] <heidi> Justin_o but it does tho
[14:08:07 CDT(-0500)] <Justin_o> hmm.. actually maybe it does.. maybe it just can't find it
[14:08:11 CDT(-0500)] <Justin_o> yes.. just saw it
[14:08:38 CDT(-0500)] <heidi> Justin_o thoughts on how i can fix?
[14:08:46 CDT(-0500)] <heidi> maybe it's cos my panel/form is hidden?
[14:08:58 CDT(-0500)] <Justin_o> oh my mistake.. it's because their's no save button i think
[14:09:17 CDT(-0500)] <heidi> ahh
[14:09:43 CDT(-0500)] <heidi> yeah that's another jira... the control change = auto-save
[14:13:42 CDT(-0500)] <Justin_o> heidi: okay
[14:14:32 CDT(-0500)] <heidi> Justin_o i'm gonna leave the tab js out
[14:14:40 CDT(-0500)] <Justin_o> heidi: okay
[14:19:08 CDT(-0500)] <heidi> jameswy soon ready to freeze 3782 and split it out into sub jiras? Justin_o maybe we should wait till yr livepreview's ready?
[14:20:47 CDT(-0500)] <Justin_o> heidi: okay.. i'll try to be quick
[14:33:38 CDT(-0500)] <jameswy> heidi: I think I'm ready on my side. I'm not making any more changes.
[14:33:41 CDT(-0500)] <jameswy> Justin_o: ^
[14:34:25 CDT(-0500)] <Justin_o> jameswy: oh sorry to be the bottle neck
[14:34:53 CDT(-0500)] <jameswy> Haha, no worries. I'm working on other things now.
[14:36:13 CDT(-0500)] <heidi> Justin_o no rush. i'm writing unit tests for slidingpanel
[14:37:17 CDT(-0500)] <Justin_o> heidi: okay.. i'm just going to try to get this thing basically working and then will fix it up in it's own branch.. just having trouble tracking a couple of things down at the moment
[14:37:34 CDT(-0500)] <heidi> cool
[14:41:08 CDT(-0500)] <anastasiac> jhung, sorry, I was on a call - what's up?
[14:41:26 CDT(-0500)] <jhung> anastasiac: on a call w jameswy. Ping you after?
[14:41:34 CDT(-0500)] <anastasiac> jhung, sure
[14:43:24 CDT(-0500)] <heidi> jameswy did you push up yr most recent?
[14:43:52 CDT(-0500)] <jameswy> heidi: Just now.
[14:43:58 CDT(-0500)] <heidi> tanks
[14:44:20 CDT(-0500)] <Bosmon> fluid-everyone: So, my proposal is to remove the last use of an exception that we have in the codebase
[14:44:23 CDT(-0500)] <Bosmon> INside fluid.container
[14:44:50 CDT(-0500)] <colinclark> Bosmon: Like I suggested to Justin_O earlier today...
[14:44:59 CDT(-0500)] <colinclark> you'll have to make an argument for that (smile)
[14:45:10 CDT(-0500)] <Bosmon> Well, I think I made one to the list 2 days ago
[14:45:19 CDT(-0500)] <colinclark> ?!?
[14:45:22 CDT(-0500)] <Bosmon> "Exceptions are not usable in browser-side code and should be disused"
[14:45:26 CDT(-0500)] <colinclark> maybe that's one of those emails I haven't quite read
[14:45:32 CDT(-0500)] <colinclark> What is your argument for this statement?
[14:45:38 CDT(-0500)] <Bosmon> Please read my email (smile)
[14:45:43 CDT(-0500)] <colinclark> pshaw
[14:45:48 CDT(-0500)] <colinclark> You're being so reasonable!
[14:45:56 CDT(-0500)] <michelled> I think it boiled down to IE is crazy
[14:45:57 CDT(-0500)] <Bosmon> Uncharacteristically (tongue)
[14:46:14 CDT(-0500)] <Bosmon> Well, actually most of the browsers are crazy
[14:46:43 CDT(-0500)] <Bosmon> But the bottom line is that exceptions, by the implementation strategy that one can detect, are not in the minds of browser implementors designed to be used (tongue)
[15:01:35 CDT(-0500)] <Justin_o> jameswy, heidi : okay i basically have it working
[15:01:43 CDT(-0500)] <heidi> Justin_o you rule
[15:01:48 CDT(-0500)] <Justin_o> the only thing though is that problem with the save button
[15:01:56 CDT(-0500)] <Justin_o> also it's really slow to start, but it works other than that
[15:02:28 CDT(-0500)] <heidi> slow to start how?
[15:02:39 CDT(-0500)] <Justin_o> so i'm wondering if i should add my hack to get around that problem with the save button
[15:02:44 CDT(-0500)] <Justin_o> since nothing works when it is there
[15:03:02 CDT(-0500)] <Justin_o> heidi: slow meaning that on the first change you sit and wait for a minute while the browser thinks then it updates stuff quickly
[15:03:12 CDT(-0500)] <heidi> ah...
[15:03:28 CDT(-0500)] <Justin_o> heidi: is there a jira for the save button and if so, who is working on that
[15:03:39 CDT(-0500)] <heidi> Justin_o yes, in the roadmap
[15:03:58 CDT(-0500)] <heidi> i think it's generally for fixing UIO to work with new controls, so mayb ewe should add a more specific one
[15:04:38 CDT(-0500)] <heidi> Justin_o it's this one: FLUID-4221
[15:06:13 CDT(-0500)] <Justin_o> heidi: thanks
[15:06:24 CDT(-0500)] <Justin_o> cindyli, colinclark: anyone have thoughts about what to do for this issue
[15:06:34 CDT(-0500)] <colinclark> sorry, we're just in a call
[15:06:36 CDT(-0500)] <colinclark> won't be long
[15:06:44 CDT(-0500)] <Justin_o> basically if there is no save button in the template UI options dies
[15:06:47 CDT(-0500)] <Justin_o> colinclark: okay
[15:10:09 CDT(-0500)] <heidi> Justin_o can i pull yr stuff in and start separating jiras?
[15:10:48 CDT(-0500)] <Justin_o> heidi: i guess so
[15:10:52 CDT(-0500)] <Justin_o> let me push it up
[15:11:07 CDT(-0500)] <heidi> and by separating jiras... i forget, are we deleting irrelevant stuff? or just leaving as is and continuing working on specific issue
[15:12:54 CDT(-0500)] <Justin_o> heidi: i've pushed the branch up to my github repo
[15:13:37 CDT(-0500)] <Justin_o> heidi: so we are just stopping work on fluid-3782 branch and creating new branches off of it, for the jiras that were started in it
[15:13:47 CDT(-0500)] <Justin_o> did that make sense? i think i'm being a bit confusing
[15:14:09 CDT(-0500)] <heidi> Justin_o without deleting stuff there now? just adding to it?
[15:14:29 CDT(-0500)] <Justin_o> heidi: yes
[15:14:50 CDT(-0500)] <heidi> cool
[15:14:58 CDT(-0500)] <heidi> k i'll pull yr stuff in, and finish mine
[15:15:04 CDT(-0500)] <heidi> thanks so much for doing that
[15:15:19 CDT(-0500)] <Justin_o> heidi: no problem.. still need to do more work on the live preview though to make it better
[15:15:30 CDT(-0500)] <heidi> yeah i think that goes with... lots of stuff (smile)
[15:15:50 CDT(-0500)] <Justin_o> :0
[15:15:52 CDT(-0500)] <Justin_o> (smile)
[15:16:39 CDT(-0500)] <harriswong> Justin_o: ping
[15:18:29 CDT(-0500)] <Justin_o> harriswong: hello
[15:19:48 CDT(-0500)] <heidi> Justin_o jameswy alright we're done with FLUID-3782 - both of yr stuff has been merged into my branch, so we can create sub jiras off of it. cool?
[15:20:03 CDT(-0500)] <jameswy> yep
[15:20:10 CDT(-0500)] <Justin_o> heidi: thanks
[15:20:29 CDT(-0500)] <Justin_o> so you'll leave your branch up on your github repo for use to use to branch off of?
[15:21:02 CDT(-0500)] <heidi> Justin_o ya, i pushed everything up just now. hey justin how do i delete branches again?
[15:21:59 CDT(-0500)] <Justin_o> local or remote?
[15:23:26 CDT(-0500)] <harriswong> Justin_o: https://github.com/harriswong/infusion/blob/FLUID-4113-test/src/webapp/tests/component-tests/reorderer/html/focus-test.html.
[15:24:47 CDT(-0500)] <harriswong> Justin_o: ^ due to the fact that calling "focus" would fire focus twice, should we alter the expected value from "1" to "2" in ImageReordererTests.testForcusBlur()?
[15:25:06 CDT(-0500)] <harriswong> heidi: to delete local, git branch -D <branch name>
[15:25:20 CDT(-0500)] <harriswong> heidi: to delete remote: git push origin :<branch_name>
[15:25:58 CDT(-0500)] <Justin_o> harriswong: not sure.. we should ask Bosmon about it
[15:26:11 CDT(-0500)] <Justin_o> mlam, harriswong: how much longer will you guys be working?
[15:26:33 CDT(-0500)] <harriswong> harriswong: just focus left
[15:26:38 CDT(-0500)] <harriswong> ....... i don't know why i msged myself
[15:26:41 CDT(-0500)] <harriswong> Justin_o^
[15:26:55 CDT(-0500)] <Justin_o> harriswong: i think everyone does that at least once.. i've done it before.. it was pretty funny
[15:27:21 CDT(-0500)] <mlam> Justin_o: i'm just figuring out why a FluidView test is failing for me, but passing for harriswong
[15:27:52 CDT(-0500)] <Justin_o> mlam: that's interesting
[15:27:56 CDT(-0500)] <Justin_o> which test is it
[15:28:12 CDT(-0500)] <mlam> dead man's blur test
[15:28:18 CDT(-0500)] <Bosmon> mlam - it is probably the one that is stateful
[15:28:18 CDT(-0500)] <harriswong> Justin_o: i wish to have 1.6.1 included before monday assuming all tests passed.
[15:28:21 CDT(-0500)] <Bosmon> Just run it again and it will pass
[15:28:24 CDT(-0500)] <Bosmon> It always fails the first run
[15:28:29 CDT(-0500)] <mlam> ahhh ok
[15:28:31 CDT(-0500)] <harriswong> Bosmon: ping
[15:28:38 CDT(-0500)] <mlam> ding!
[15:28:56 CDT(-0500)] <Justin_o> harriswong: we need to have 1.6.1 in by monday
[15:29:09 CDT(-0500)] <Justin_o> mlam: is it working now?
[15:29:14 CDT(-0500)] <mlam> yes
[15:29:20 CDT(-0500)] <harriswong> Justin_o: as soon as I have a verdict on what to do with the reorderer's test cases.
[15:29:44 CDT(-0500)] <Justin_o> mlam, harriswong: is the reorderer unit test that only that isn't working now?
[15:30:19 CDT(-0500)] <mlam> there's a UI options test and I believe cindyli is working on that...but I dont' think that one is specifically related to 1.6.1, right harriswong?
[15:30:39 CDT(-0500)] <harriswong> mlam, Justin_o: right.
[15:30:49 CDT(-0500)] <Justin_o> harriswong: okay.. cool...
[15:31:09 CDT(-0500)] <Justin_o> Bosmon: do you think you could look at the reorderer unit tests a bit and then push up the 1.6.1 upgrade?
[15:31:32 CDT(-0500)] <harriswong> Justin_o, mlam: to clairfy, on the list I have for Jira #FLUID-4113 (based on 1.6.1rc1), only UI options (chrome safari), and image-reorderer (focus/focusin) are failing.
[15:32:00 CDT(-0500)] <Justin_o> harriswong: did you guys switch to 1.6.1 final yet?
[15:32:14 CDT(-0500)] <mlam> yup, that's my list as well, after the FluidView test suggestion
[15:32:21 CDT(-0500)] <mlam> Justin_o: yah, we're on 1.6.1
[15:32:38 CDT(-0500)] <Justin_o> mlam: not the rc1 right?
[15:32:46 CDT(-0500)] <harriswong> Justin_o: 1.6.1 final is in our branch: https://github.com/harriswong/infusion/tree/jkkremer-FLUID-4113
[15:32:55 CDT(-0500)] <Justin_o> harriswong, mlam: great thanks
[15:33:40 CDT(-0500)] <Bosmon> Justin_o - ok
[15:33:45 CDT(-0500)] <Bosmon> I assume a few are failing?
[15:33:55 CDT(-0500)] <Bosmon> I have to warn you that I intend to push 1.6.1 even if they fail (tongue)
[15:33:59 CDT(-0500)] <harriswong> Bosmon: just 2 test cases.
[15:34:15 CDT(-0500)] <harriswong> Bosmon: related to focus/focusin, demonstrated briefly here: https://github.com/harriswong/infusion/blob/FLUID-4113-test/src/webapp/tests/component-tests/reorderer/html/focus-test.html
[15:34:20 CDT(-0500)] <Justin_o> Bosmon: if you do that, could you please also file a jira for the failure
[15:34:30 CDT(-0500)] <Bosmon> Justin_o: certainly
[15:34:34 CDT(-0500)] <Justin_o> thanks
[15:35:38 CDT(-0500)] <heidi> delayed thank you harriswong
[15:35:50 CDT(-0500)] <harriswong> Bosmon: I had a qunit test to demonstrate if you prefer it better; but I have to dig it back out, i think i accidentally deleted it when i was refreshing my branches....
[15:36:06 CDT(-0500)] <harriswong> heidi: np!
[15:36:15 CDT(-0500)] <Bosmon> harriswong - I think the point is that tests based on focus state are not reliable in any case
[15:36:27 CDT(-0500)] <Bosmon> It's the reason for the "indeterminate" FluidViews test also
[15:37:18 CDT(-0500)] <Bosmon> We have to accept that we can't write tests which are very satisfactory which make assertions based on focus state, and in most cases, all we can do is i) ensure that the real component is working, ii) try to characterise the situation as well as we can, iii) fix up the test so it just works again
[15:37:27 CDT(-0500)] <Bosmon> Most of these focus tests just contain "arbitrary code" in any case
[15:38:21 CDT(-0500)] <harriswong> Bosmon: I like iii), i say we change "1" to "2" so the focus world is happy again
[15:38:43 CDT(-0500)] <Justin_o> fluid-everyone: just a small warning.. github will have some down time tomorrow... but it shouldn't be more than a few minutes https://github.com/blog/854-scheduled-maintenance-saturday-22-00-pst
[15:38:49 CDT(-0500)] <Bosmon> Well, we are probably actually uninterested in the NUMBER of focus events we receive
[15:38:52 CDT(-0500)] <Bosmon> Just that we receive some
[15:39:11 CDT(-0500)] <Bosmon> Preferably, not followed by any blur events (tongue)
[15:39:52 CDT(-0500)] <harriswong> Bosmon: as long as the focus event doesn't trigger actions/functionality that cannot be occurred twice; then i think we are good.
[15:41:20 CDT(-0500)] <harriswong> Bosmon: what i meant is say if we have an action delete_prev_item() that's called by focus; everytime we have focus triggered, we delete 2 elements..
[15:41:25 CDT(-0500)] <Bosmon> A component that behaves that way is bug-ridden in any case
[15:41:31 CDT(-0500)] <Bosmon> Since it could never be made to work in IE (tongue)
[15:41:45 CDT(-0500)] <Bosmon> IE fires focus and blur events almost at random
[15:41:56 CDT(-0500)] <harriswong> Bosmon: lovely....IE is just so lovely..
[15:43:05 CDT(-0500)] <harriswong> Bosmon: then in that case, I think it's safe to just mod the testcase, so that it verify a focus/blur has been fired, instead of couting them?
[15:43:39 CDT(-0500)] <harriswong> verifies*
[15:44:14 CDT(-0500)] <jhung> anstasiac: sorry I just finished now. Maybe we can chat briefly on Monday?
[15:45:08 CDT(-0500)] <Bosmon> harriswong - yes
[15:46:13 CDT(-0500)] <harriswong> Bosmon: another note is within FluidDocument.js, line 58~60.
[15:46:55 CDT(-0500)] <harriswong> Bosmon: we have focusin binded onto $(document), meaning focusin is fired almost everywhere whenever we are within the document scope...
[15:47:39 CDT(-0500)] <harriswong> Bosmon: I am not sure if that's affecting the test case to fail in the reorderer since FluidDocument.js is included in ImageReorderer-test.html
[15:47:58 CDT(-0500)] <Justin_o> Bosmon, harriswong, mlam: i'm going to take off now.. i think you guys have everything in order for 1.6.1
[15:48:14 CDT(-0500)] <mlam> cool, have a good weekend Justin_o
[15:48:17 CDT(-0500)] <harriswong> thanks justin_o
[15:48:21 CDT(-0500)] <Justin_o> heidi: i'm going to take off now.. anything else you need before i leave
[15:48:28 CDT(-0500)] <Justin_o> mlam: you too
[15:48:32 CDT(-0500)] <heidi> Justin_o no thanks for yr help today!!
[15:48:36 CDT(-0500)] <heidi> happy weekend
[15:48:43 CDT(-0500)] <Justin_o> heidi: np, have a good weekend
[16:12:26 CDT(-0500)] <Bosmon> colinclark - you back?
[16:12:34 CDT(-0500)] <colinclark> I will be in a moment
[16:12:36 CDT(-0500)] <colinclark> (smile)
[16:12:44 CDT(-0500)] <Bosmon> ok
[16:21:10 CDT(-0500)] <Bosmon> Hi harriswong - you there?
[16:21:20 CDT(-0500)] <harriswong> Bosmon: yes
[16:21:24 CDT(-0500)] <Bosmon> Can you explain the change swapping out attr/removeAttr for prop/removeProp?
[16:22:13 CDT(-0500)] <harriswong> Bosmon: mm, that's from mlam but i think he took off.
[16:22:44 CDT(-0500)] <Bosmon> It is important to have reasoning behind these changes, rather than just "making it work" - as I think colinclark explained recently (tongue)
[16:22:50 CDT(-0500)] <Bosmon> Except of course in the case of focus issues...
[16:22:58 CDT(-0500)] <Bosmon> But even there we at least TRY to have reasoning (tongue)
[16:23:06 CDT(-0500)] <harriswong> what number is it?
[16:23:19 CDT(-0500)] <Bosmon> It seems to have happened at a few revisions
[16:23:29 CDT(-0500)] <Bosmon> For example there are some at f3cab5 and 4af148
[16:23:40 CDT(-0500)] <Bosmon> And then the final merge caused another one
[16:24:28 CDT(-0500)] <Bosmon> Actually, the documentation on this API method specifically states NOT to use it
[16:24:33 CDT(-0500)] <Bosmon> So I am quite suspicious of this change
[16:24:40 CDT(-0500)] <Bosmon> http://api.jquery.com/removeProp/
[16:25:41 CDT(-0500)] <Bosmon> So suspicious that I may actually go back on my promise to blindly merge this branch in (tongue)
[16:26:19 CDT(-0500)] <Bosmon> Also, I am suspicious of your change for testFocusBlur
[16:26:39 CDT(-0500)] <harriswong> ah it changes removeAttr to removeProp, and attr to prop.
[16:26:42 CDT(-0500)] <Bosmon> Just because we can't be sure of the exact count for the selection event, doesn't mean we shouldn't test whether it has been notified at all
[16:27:13 CDT(-0500)] <harriswong> this is because in 1.6.1, http://blog.jquery.com/, they altered the behavior
[16:28:23 CDT(-0500)] <harriswong> and for testFocusBlur, it was as explained before that the counter was tracking the the number of 'focus' being triggered. Its previous line made sure that the event is triggered, thus the count is not needed
[16:29:50 CDT(-0500)] <harriswong> Bosmon: in brief, for 1.6/1.6.1, it was suggested to use attr on element with attributes, and prop on elements that has properties, there are also some related changes with .val() as well.
[16:30:50 CDT(-0500)] <Bosmon> harriswong - I don't think that the usage in line with this guideline, since it is specifically referring to the use of BOOLEAN attributes
[16:31:06 CDT(-0500)] <Bosmon> Whereas the use here has retained the string-valued value "boolean" for the disabled attribute....
[16:31:42 CDT(-0500)] <Bosmon> If we changed from attr() to prop(), we should ALSO have changed to the use of "true/false" for the attribute value
[16:32:03 CDT(-0500)] <Bosmon> But my personal feeling is, "if it isn't broke, don't fix it" - the blog specifically states that all previous uses of "attr" could continue unchanged...
[16:32:50 CDT(-0500)] <harriswong> Bosmon: I agree on the "if it isn't broke, don't fix it" verdict
[16:32:58 CDT(-0500)] <Bosmon> You'll note that the "before" and "after" uses of attr were taking boolean values as the RHS, not strings
[16:33:00 CDT(-0500)] <harriswong> Bosmon: it was however broken in 1.6, thus the change.
[16:33:21 CDT(-0500)] <Bosmon> awful
[16:33:30 CDT(-0500)] <Bosmon> You'd think these guys could describe their own API correctly...
[16:33:31 CDT(-0500)] <harriswong> Bosmon: the changes was then "okay" again when 1.6.1 came out because the entire universe went crazy when they took made that api change..
[16:33:39 CDT(-0500)] <Bosmon> Ah I see
[16:33:45 CDT(-0500)] <Bosmon> This was just an aberration with 1.6.0?
[16:34:02 CDT(-0500)] <harriswong> Bosmon: i think 1.6.1 is a "fix" for attr-prop for 1.6..
[16:34:07 CDT(-0500)] <Bosmon> jquery really don't seem to have their eyes on the ball any more
[16:34:22 CDT(-0500)] <harriswong> due to backward compatibility flames
[16:34:32 CDT(-0500)] <Bosmon> flames for sure...
[16:35:04 CDT(-0500)] <harriswong> Bosmon: yea, so some of these changes were prob. added to address 1.6, and then we upgraded it to 1.6.1, and it remains "working"...
[16:35:13 CDT(-0500)] <Bosmon> Perhaps we should just increasingly recommend the uses of fluid wrappers for jquery functions (smile)
[16:35:20 CDT(-0500)] <harriswong> Bosmon: so we didn't revert it back due to the "if it isn't broken, don't fix it"
[16:35:22 CDT(-0500)] <Bosmon> Just as we do for fluid.value()
[16:35:29 CDT(-0500)] <Bosmon> We actually do have a fluid.enabled() function (tongue)
[16:35:42 CDT(-0500)] <Bosmon> Which should insulate us from any further insanity of this type....
[16:35:43 CDT(-0500)] <harriswong> Bosmon: i agree, fluid.attr(), and fluid.prop()
[16:36:02 CDT(-0500)] <Bosmon> we intend to keep our agreements re. API compatibility, even if jQuery don't...
[16:36:30 CDT(-0500)] <harriswong> Bosmon: i think it is better to ask mlam on Monday just to make sure, since he is the one who added it and most likely have a better opinion on this than i do...
[16:37:15 CDT(-0500)] <Bosmon> Ok - but as a note for the future, these opinions should be recorded in commit comments or on the JIRA
[16:37:33 CDT(-0500)] <Bosmon> It's crucial to have a record of the intention and evidence behind changes like this
[16:37:35 CDT(-0500)] <Bosmon> Or indeed, any changes (tongue)
[16:37:38 CDT(-0500)] <harriswong> Bosmon: yes... in any case, i am going to head home, would you like me to go online later to continue this discussion or shall we wait till monday?
[16:38:04 CDT(-0500)] <Bosmon> It's ok, I will fix up the branch a bit now before I merge it
[16:38:15 CDT(-0500)] <Bosmon> I think we've managed to pool enough info on the matter (tongue)
[16:38:52 CDT(-0500)] <harriswong> Bosmon: Will do, apology for not being clear.. Should i add some of these into the jira?
[16:39:08 CDT(-0500)] <Bosmon> Please do - especially if you happen to have any memory of which test cases failed under 1.6 (smile)
[16:39:29 CDT(-0500)] <harriswong> Bosmon: another note is mike was working directly on my branch so maybe that's why our git commit looks kinda...weird.
[16:39:36 CDT(-0500)] <Bosmon> If you don't have such a memory, consider it an evidence for the importance of writing these things down early (smile)
[16:40:09 CDT(-0500)] <harriswong> Bosmon: noted, I will recollect my memories and add them back onto the jira once i get home.
[16:41:01 CDT(-0500)] <harriswong> Bosmon: thanks for looking after the pull request, have a great weekend!
[16:44:55 CDT(-0500)] <colinclark> Ok Bosmon
[16:45:05 CDT(-0500)] <colinclark> For posterity, let's duke it out over exceptions
[16:45:10 CDT(-0500)] <colinclark> I have read your email
[16:45:42 CDT(-0500)] <colinclark> Entitled "Exception handling, 'notrycatch', debugging in IE, and new diagnostics" from yesterday at 4:30 am
[16:46:13 CDT(-0500)] <colinclark> Which, I guess, for your schedule, was actually written 2 days ago (tongue)
[16:46:46 CDT(-0500)] <Bosmon> Sure
[16:46:55 CDT(-0500)] <colinclark> So, the argument is an exception in IE will never allow us to see the whole call stack
[16:46:58 CDT(-0500)] <colinclark> making them entirely useless
[16:47:48 CDT(-0500)] <colinclark> I, too, encountered the frustration with the breaking Uploader Compatibility tests, despite even having a working debugger for IE6!
[16:47:56 CDT(-0500)] <Bosmon> !
[16:48:00 CDT(-0500)] <Bosmon> Which is your working IE6 debugger?
[16:48:06 CDT(-0500)] <colinclark> I have this magical VM from the King
[16:48:08 CDT(-0500)] <Bosmon> Oh, you mean the Web Studio thing?
[16:48:09 CDT(-0500)] <Bosmon> Ah yes
[16:48:12 CDT(-0500)] <colinclark> in which he was successfully able to install that, yes
[16:48:33 CDT(-0500)] <Bosmon> Yes, I have once seen such a thing (smile)
[16:48:51 CDT(-0500)] <colinclark> Okay, so I was the author of the fluid.container() exception, way back in the day
[16:48:54 CDT(-0500)] <colinclark> the NotOne exception
[16:49:02 CDT(-0500)] <colinclark> I believe, to try to understand the creator's intentions...
[16:49:07 CDT(-0500)] <colinclark> that I was trying to be very communicative
[16:49:30 CDT(-0500)] <colinclark> as in "something bad happened, and here's some information you might find helpful, both in plain English and programmatically interpretable ways
[16:49:37 CDT(-0500)] <Bosmon> Yes - I guess in those days, we all laboured under the impression that exceptions could be CAUGHT
[16:49:46 CDT(-0500)] <colinclark> (smile)
[16:49:47 CDT(-0500)] <Bosmon> That is - some could actually catch this exception, and look at it
[16:49:53 CDT(-0500)] <colinclark> One would imagine that's what they'd be for (tongue)
[16:50:01 CDT(-0500)] <Bosmon> And perhaps make some disposition based on some machine-readable aspects of its "type"
[16:50:07 CDT(-0500)] <colinclark> So, what will you replace this exception with?
[16:50:13 CDT(-0500)] <colinclark> A call to fluid.fail() with the same message?
[16:51:01 CDT(-0500)] <Bosmon> Yes - my recommendation is that we centralise on fluid.fail() as a "one stop shop" for all kinds of failure
[16:51:11 CDT(-0500)] <Bosmon> I also changed the message that night, as you may have seen
[16:51:23 CDT(-0500)] <Bosmon> Log messages which result from this are prepended with the message "ASSERTION FAILED"
[16:51:32 CDT(-0500)] <Bosmon> Which I think gives a slightly clearer summary of its purpose
[16:51:48 CDT(-0500)] <Bosmon> I think we have to accept that JS as an implemented language just doesn't really have "exceptions"
[16:52:00 CDT(-0500)] <Bosmon> The only disposition in the case of a failure is simply to abort EVERYTHING and consider it a logic bug
[16:52:10 CDT(-0500)] <colinclark> Well, it's hard to mount a defence for the lone example of something that should make sense
[16:52:11 CDT(-0500)] <colinclark> but doesn't
[16:52:17 CDT(-0500)] <colinclark> So go for it
[16:52:23 CDT(-0500)] <Bosmon> Well
[16:52:32 CDT(-0500)] <Bosmon> I'd like to see you defend it a bit harder (smile)
[16:52:36 CDT(-0500)] <Bosmon> Don't you think you could muster something? (tongue)
[16:53:02 CDT(-0500)] <colinclark> Well, let's look again at the intention of the creator
[16:53:20 CDT(-0500)] <colinclark> A clear, easy to understand indication to a developer that an error has occurred
[16:53:27 CDT(-0500)] <Bosmon> So, I speculated that even if we can't have exceptions on the client, we may still be able to use them on the server
[16:53:33 CDT(-0500)] <colinclark> I saw that, yes
[16:53:41 CDT(-0500)] <Bosmon> But then I observed that this is archetypically client-only code
[16:53:44 CDT(-0500)] <Bosmon> Given it is looking at the DOM
[16:53:56 CDT(-0500)] <Bosmon> At least, in our view it is archetypically client-only
[16:54:03 CDT(-0500)] <Bosmon> NodeConf was swarming with people who want to use the DOM on the server
[16:55:40 CDT(-0500)] <colinclark> I can imagine
[16:56:14 CDT(-0500)] <Bosmon> But I guess my reasoning is - i) we recommend to ourselves, and all of our clients, that we NEVER write a "catch" block
[16:56:27 CDT(-0500)] <Bosmon> ii) in the cases when it is morally unavoidable, we make use of fluid.tryCatch
[16:56:56 CDT(-0500)] <Bosmon> So, the core use case the distinguishes exceptions from assertion failures is the "disposition"...
[16:57:24 CDT(-0500)] <Bosmon> In the case of an exception, the poster case was always that you might be able to flag the possibility for some kind of "intervention" - and then the operation might be retried, and succeed
[16:57:43 CDT(-0500)] <colinclark> right
[16:57:54 CDT(-0500)] <Bosmon> In the case of an assertion failure, there has been a logic fault, and the app should be destroyed, if being developer - or should continue as well as possible, if in production
[17:00:08 CDT(-0500)] <colinclark> that seems about right, yes
[17:00:15 CDT(-0500)] <Bosmon> exceptions always had a quite distinct morality to them
[17:00:36 CDT(-0500)] <Bosmon> Especially in the Java-type world of I/O bound processes in the "real world"
[17:00:43 CDT(-0500)] <Bosmon> So, in the JS world, exceptions just don't figure
[17:00:55 CDT(-0500)] <Bosmon> In the case an AJAX callback fails, you get an "event" - not an exception
[17:01:12 CDT(-0500)] <Bosmon> That is, ALL control paths are considered to be part of "normal control flow", not just non-exceptional ones
[17:02:13 CDT(-0500)] <Bosmon> I guess, like OO, exceptions were another Java feature that was just put in half-heartedly...
[17:02:29 CDT(-0500)] <Bosmon> I don't believe LISP had exception (tongue)
[17:02:30 CDT(-0500)] <Bosmon> s
[17:03:06 CDT(-0500)] <Bosmon> Interesting.... LISP has "conditions"...
[17:03:32 CDT(-0500)] <Bosmon> Ah yes!
[17:03:44 CDT(-0500)] <Bosmon> I think this makes sense of it.... the purpose behind exceptions is to let you "unwind the stack"
[17:04:00 CDT(-0500)] <Bosmon> BUT - in a fully ordered world, the only thing which can actually "fail" is I/O
[17:04:09 CDT(-0500)] <Bosmon> And in JS, both on the client and server, I/O is fully asynchronous
[17:04:19 CDT(-0500)] <Bosmon> Which means that in all cases, there is NO stack to unwind
[17:04:31 CDT(-0500)] <Bosmon> And hence the niche which exceptions occupy in the language is uninhabitable
[17:07:50 CDT(-0500)] <colinclark> That actually makes a lot of sense
[17:09:40 CDT(-0500)] <Bosmon> Hmm
[17:09:44 CDT(-0500)] <Bosmon> I had another wacky idea
[17:09:58 CDT(-0500)] <Bosmon> Given we have now gone the route of fluid.tryCatch...
[17:10:07 CDT(-0500)] <colinclark> yes?
[17:10:22 CDT(-0500)] <Bosmon> We could actually upgrade the implementation of "finally" blocks so that rather than being discarded in the case of a fluid.fail() they are actually just QUEUED UP
[17:10:28 CDT(-0500)] <Bosmon> This is something the functional model makes extremely easy
[17:10:58 CDT(-0500)] <Bosmon> The once we bomb all the way down the stack (actually, just BEFORE we destroy everything), we can actually unwind all of the queued handlers in fluid.fail() itself
[17:11:24 CDT(-0500)] <Bosmon> This gives us the advantage of keeping the environment clean, in the case there was any cleanup to be performed, whilst still maintaining debuggability
[17:11:36 CDT(-0500)] <colinclark> ah, interesting
[17:11:44 CDT(-0500)] <Bosmon> I mean, its very unlikely you will do anything successful with an app after it has issued fluid.fail() - but it would nice to be able to have the optioon
[17:11:54 CDT(-0500)] <colinclark> It is unlikely, yes
[17:11:58 CDT(-0500)] <Bosmon> For example, in a GUI app, triggering ONE event might cause a fail() but you might still want to explore the interface a bit
[17:12:01 CDT(-0500)] <colinclark> but if it's not onerous to open up the possibility
[17:12:17 CDT(-0500)] <Bosmon> There's many times that some residual value can be got out of an app that has "mostly crashed" but might still be partially navigable
[17:13:23 CDT(-0500)] <Bosmon> Either for debugging value, or for making a last-ditch attempt to save your data...
[17:34:02 CDT(-0500)] <colinclark> Bosmon: Do you have a sec?
[17:36:50 CDT(-0500)] <Bosmon> Yes, I'm here
[17:45:47 CDT(-0500)] <colinclark> So, Bosmon, options chewing
[17:46:18 CDT(-0500)] <colinclark> There are other conversations we can have about it once we're in bug parade
[17:46:32 CDT(-0500)] <colinclark> but I have one issue that might be worth discussing now
[17:46:40 CDT(-0500)] <colinclark> I'd like to think it's an interesting one (tongue)
[17:47:06 CDT(-0500)] <colinclark> So, it seems nice of us to try to support backwards compatibility for older versions than the immediately previous one
[17:47:18 CDT(-0500)] <colinclark> So, we made another, smaller options API change for 1.4
[17:47:28 CDT(-0500)] <colinclark> Which means we now have rules for going from 1.2->1.3
[17:47:32 CDT(-0500)] <colinclark> and 1.3->1.4
[17:47:45 CDT(-0500)] <colinclark> and so there isn't really any reason we can't support going from 1.2->1.4
[17:47:54 CDT(-0500)] <colinclark> Through a chaining of transformations
[17:48:01 CDT(-0500)] <colinclark> So my questions
[17:48:08 CDT(-0500)] <colinclark> 1. Do you see any reason why we shouldn't do it this way?
[17:48:55 CDT(-0500)] <colinclark> 2. Do you see any reason why I shouldn't implement this in transformWithRules() by allowing users to provide an array of rules instead of the current implementation, which only takes a single rules object?
[17:49:38 CDT(-0500)] <Bosmon> That does seem reasonable...
[17:49:48 CDT(-0500)] <Bosmon> "In theory" of course, it should be possible to compose the rules objects themselves (tongue)
[17:49:58 CDT(-0500)] <Bosmon> But this is "left as an exercise for the reader"
[17:51:52 CDT(-0500)] <colinclark> Well, I had thought of this
[17:51:59 CDT(-0500)] <colinclark> but it seems to me there's an ordering problem
[17:52:03 CDT(-0500)] <colinclark> no?
[17:52:32 CDT(-0500)] <colinclark> At the moment, there really is no way in a rules object to say "this should happen first"
[17:52:37 CDT(-0500)] <colinclark> which I don't think is necessarily a bad thing
[17:52:48 CDT(-0500)] <colinclark> Am I missing something?
[17:53:36 CDT(-0500)] <Bosmon> Well, I mean compose them structurally
[17:53:36 CDT(-0500)] <colinclark> Bosmon: ^
[17:53:42 CDT(-0500)] <colinclark> hmm
[17:53:43 CDT(-0500)] <Bosmon> I don't seriously suggest we do this
[17:53:49 CDT(-0500)] <colinclark> That's cool
[17:53:52 CDT(-0500)] <colinclark> it is Friday...
[17:53:52 CDT(-0500)] <Bosmon> But it is one of the possibilities raised by the "model calculus"
[17:53:54 CDT(-0500)] <colinclark> do elaborate (smile)
[17:54:19 CDT(-0500)] <Bosmon> Well, there exists clearly, a set of rules, which has the effect of two separate sets of rules, applied in sequence
[17:54:36 CDT(-0500)] <Bosmon> When these rules are written in code, you have no option, but to simply apply the rules one after the other
[17:54:48 CDT(-0500)] <Bosmon> But having them written out declaratively, raises the possibility that their composition can be computed
[17:55:08 CDT(-0500)] <Bosmon> One day, we could set a PhD student on the task of working how how this is to be so (smile)
[17:55:33 CDT(-0500)] <Bosmon> I mean, for example, the composition of a "value" rule that moves a to b, and one which moves b to c, is a "value" rule which just moves a to c in one step
[17:56:26 CDT(-0500)] <Bosmon> We would need to make sure that the set of model transformation elements we draw up is actually CLOSED
[17:56:33 CDT(-0500)] <Bosmon> Which I believe the current set is not
[17:57:10 CDT(-0500)] <Bosmon> For example - the composition of two rules, one of which computes the length of a list and stores it somewhere, and another rule, which moves this list length from one place to another, can't be described by ruleset we currently have
[18:00:49 CDT(-0500)] <colinclark> yes, that's right
[18:01:16 CDT(-0500)] <colinclark> Is this the sort of thing that Boomerang achieves?