fluid-work IRC Logs-2011-05-13

[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