fluid-work IRC Logs-2011-05-02

[09:07:28 CDT(-0500)] <heidi_> cindyli thinking UIO could have another option similar to previewTemplateUrl for UIOTemplateURL, so the implementer can choose which layout to use. that makes sense, right?
[09:08:17 CDT(-0500)] <cindyli> heidi_: what other templates in ur mind?
[09:08:50 CDT(-0500)] <cindyli> heidi_: like fat panel layout or skinny layout
[09:09:18 CDT(-0500)] <cindyli> that makes sense i think
[09:10:17 CDT(-0500)] <heidi_> cindyli yep, panels, or full page, etc. right now how does one choose to have preview or not? is that implemented?
[09:11:42 CDT(-0500)] <cindyli> heidi_: no, not implemented, the preview is always there
[09:12:07 CDT(-0500)] <heidi_> cindyli maybe instead of being a separate option, the user would just choose the UIO template with or without the preview?
[09:12:53 CDT(-0500)] <heidi_> or maybe more has to happen behind the scenes
[09:13:07 CDT(-0500)] <heidi_> for enhancer to know whether to update the preview or page with the changes...
[09:13:16 CDT(-0500)] <cindyli> heidi_: makes sense. i'm just thinking what would happen if the preview url is not provided. should try tat
[09:14:22 CDT(-0500)] <heidi_> cindyli i wonder if it's better to be separate, to explicitly tell Enhancer what to live-update
[09:15:22 CDT(-0500)] <heidi_> cindlyi tho it looks like previewFrame is already an option in selectors - so the user would just specify the preview area or the page?
[09:16:24 CDT(-0500)] <cindyli> heidi_: yes
[09:17:38 CDT(-0500)] <heidi_> cindyli okay cool... so UIOTemplateURL should be enough extra info for layout
[09:17:42 CDT(-0500)] <heidi_> thanks
[09:35:13 CDT(-0500)] <Justin_o> mlam: hello... are these tests failing for you? http://build.fluidproject.org/infusion/tests/component-tests/uploader/html/Uploader-test.html
[09:35:54 CDT(-0500)] <mlam> hey Justin_o, no they're not.
[09:36:57 CDT(-0500)] <mlam> are they failing on swarm?
[09:38:04 CDT(-0500)] <Justin_o> on my machine they are throwing errors and won't complete
[09:38:27 CDT(-0500)] <Justin_o> mlam: ^
[09:38:48 CDT(-0500)] <mlam> strange...which browser? i guess safari?
[09:38:57 CDT(-0500)] <Justin_o> FF4
[09:39:28 CDT(-0500)] <Justin_o> mlam: works fine on safari
[09:39:48 CDT(-0500)] <mlam> ok
[09:42:52 CDT(-0500)] <mlam> Justin_o: Ok, same thing for me....I'll take a look
[09:43:01 CDT(-0500)] <Justin_o> mlam: thanks
[09:43:06 CDT(-0500)] <mlam> np
[09:43:59 CDT(-0500)] <Justin_o> mlam: bosmon put in a fix for options merging for listeners over the weekend... you may want to double check if that is related or not..
[09:45:10 CDT(-0500)] <mlam> ok
[10:14:32 CDT(-0500)] <Justin_o> heidi_: just curious if you've had a chance to look at FLUID-3880 again yet
[10:54:12 CDT(-0500)] <Justin_o> jamon: I'm looking at the daily build stuff a bit..
[10:54:38 CDT(-0500)] <Justin_o> i'm planning on making the current builds happen nightly instead of hourly and setting up another group that builds hourly
[10:54:58 CDT(-0500)] <Justin_o> jamon: how does this sound.. also would we be able to mount the hourly builds somewhere
[10:55:16 CDT(-0500)] <Justin_o> e.g. build.fluidproject.org/hourly/infusion or something like that
[11:07:15 CDT(-0500)] <jamon> Justin_o: let me poke around continuum a bit and see how it can be organized
[11:07:52 CDT(-0500)] <Justin_o> jamon: thanks
[11:08:25 CDT(-0500)] <Justin_o> i've started adding an hourly group so you'll probaby see that there now.. the infusion one is currently in there but not sure if it's working yet
[11:40:20 CDT(-0500)] <Justin_o> cindyli: I can't quite remember.. did you say that the new uploader server is all ready to go
[11:40:22 CDT(-0500)] <Justin_o> ?
[11:40:36 CDT(-0500)] <cindyli> yes, Justin_o
[11:40:49 CDT(-0500)] <Justin_o> cindyli: where is it at the moment?
[11:40:49 CDT(-0500)] <cindyli> digging out the branch
[11:40:54 CDT(-0500)] <Justin_o> cindyli: thanks
[11:41:17 CDT(-0500)] <cindyli> https://github.com/cindyli/image-gallery
[11:41:35 CDT(-0500)] <cindyli> r u trying it out, Justin_o
[11:41:53 CDT(-0500)] <Justin_o> cindyli: i was going to look at getting it built
[11:41:53 CDT(-0500)] <cindyli> follow the "installation" section in "readme"
[11:42:01 CDT(-0500)] <Justin_o> so that it will be part of our daily build site
[11:42:06 CDT(-0500)] <cindyli> ok
[11:42:22 CDT(-0500)] <cindyli> let me know if anything u r not happy with
[11:42:34 CDT(-0500)] <mlam> colinclark: there's an issue in FF4 with the uploader unit tests. The tests break on a call to append file data to formData. Chrome, which uses formData itself isn't affected. I've done some searching, and I was wondering if this would be a viable solution to our problem : http://bugs.dojotoolkit.org/changeset/24334
[11:42:48 CDT(-0500)] <Justin_o> cindyli: sure.. thanks.. is there anything special needed to get it working, besides checking it out
[11:43:04 CDT(-0500)] <cindyli> run install.sh
[11:43:11 CDT(-0500)] <Justin_o> cindyli: great.. thanks
[11:43:19 CDT(-0500)] <cindyli> np
[11:44:26 CDT(-0500)] <colinclark> mlam: Give be about five minutes, and I'll take a look
[11:44:35 CDT(-0500)] <mlam> ok, thanks
[11:44:37 CDT(-0500)] <harriswong> Justin_o: I notice in jquery-ui 1.9m4, tooltip is a part of it
[11:46:02 CDT(-0500)] <Justin_o> harriswong: yes.. tooltip is part of the 1.9 prerelease.. we used it early in 1.3 so it's kind of experimental code at the moment
[11:46:29 CDT(-0500)] <Justin_o> that's infusion 1.3 that we used it in
[11:46:29 CDT(-0500)] <colinclark> mlam: I guess the first question is, do you know why the call breaks in the unit tests?
[11:46:36 CDT(-0500)] <colinclark> Why does it break there and not in the real implementation?
[11:46:42 CDT(-0500)] <colinclark> Or does it break in the real implementation?
[11:47:27 CDT(-0500)] <mlam> No, I've been trying to figure that out without much luck. I just get an error in the console saying that there was an error in converting the data
[11:47:46 CDT(-0500)] <colinclark> mlam: Looking at this Dojo ticket, you can see what they're doing...
[11:47:50 CDT(-0500)] <mlam> and it doesn't break in the real implementation, which makes this even more strange
[11:47:54 CDT(-0500)] <harriswong> Justin_o: Is the jquery.ui.tooltip.js in fluid actually the one from 1.9?
[11:48:12 CDT(-0500)] <mlam> yes, they're basically using sendAsBinary for FF browsers.
[11:48:15 CDT(-0500)] <colinclark> Right
[11:48:24 CDT(-0500)] <Justin_o> harriswong: yes.. at least some version of it.. they may have updated it since we took it
[11:48:28 CDT(-0500)] <colinclark> So, what would our unit test be testing if we went with a solution like that?
[11:48:53 CDT(-0500)] <colinclark> mlam: The first thing that would be helpful to know is what's different about the unit test from the real thing?
[11:48:54 CDT(-0500)] <mlam> it would be testing HTML5 , but the files would be "sent" using sendAsBinary
[11:49:04 CDT(-0500)] <colinclark> mlam: Meaning, it wouldn't be testing the implementation we want to test
[11:49:07 CDT(-0500)] <colinclark> it would be testing something else entirely
[11:49:32 CDT(-0500)] <colinclark> In other words, our test wouldn't correctly test the real behaviour on Firefox 4
[11:51:38 CDT(-0500)] <mlam> It's just so bizarre because chrome uses formData and it's fine, and the real implementation with FF4 is working fine.
[11:52:14 CDT(-0500)] <mlam> I guess excluding formData from FF4 defeats the purpose of progressive enhancement.
[12:13:46 CDT(-0500)] <colinclark> mlam: But what's different about the test from the real thing?
[12:13:59 CDT(-0500)] <colinclark> Why does it happen here and not there?
[12:14:10 CDT(-0500)] <colinclark> That seems like mission #1
[12:14:15 CDT(-0500)] <mlam> I'm not sure, that's what I'm trying to figure out here.
[12:22:45 CDT(-0500)] <cindyli> colinclark: the previous text slider supports the supply of the initial slider value by recongnizing the default value of <input> in the markup. example: <input class="flc-textfieldSlider-field" type="text" value="15" />, 15 will be taken by the script and set on slider. I wonder if this is what we really want since the usual way of providing default is thru js, in defaults block. Should we support both for the text slider?
[12:23:10 CDT(-0500)] <colinclark> cindyli: I'd have to look at the code
[12:23:14 CDT(-0500)] <cindyli> ok
[12:23:19 CDT(-0500)] <colinclark> give me a few minutes to finish up what I'm doing, and then I'll take a look
[12:23:23 CDT(-0500)] <cindyli> sure
[12:54:53 CDT(-0500)] <colinclark> cindyli: Justin_o and I are trying out the new Image Gallery you created
[12:54:54 CDT(-0500)] <colinclark> it's super cool
[12:55:01 CDT(-0500)] <colinclark> On thing we've noticed:
[12:55:07 CDT(-0500)] <colinclark> Images aren't being displayed
[12:55:15 CDT(-0500)] <colinclark> This is with the stock PHP and Apache running on Mac OS X
[12:55:18 CDT(-0500)] <cindyli> really>>!!
[12:55:20 CDT(-0500)] <colinclark> Luckily, there's an error message
[12:55:23 CDT(-0500)] <cindyli> that's called "super cool"?
[12:55:37 CDT(-0500)] <colinclark> lol
[12:55:38 CDT(-0500)] <cindyli> should i come over?
[12:55:41 CDT(-0500)] <colinclark> well, almost super cool?
[12:55:46 CDT(-0500)] <colinclark> This is the error: Warning</b>: strtotime() [<a href='function.strtotime'>function.strtotime</a>]: It is not safe to rely on the system's timezone settings.
[12:56:05 CDT(-0500)] <colinclark> Is this a misconfiguration with my PHP settings, or a problem with the code's use of strtotime()?
[12:56:06 CDT(-0500)] <cindyli> looking..
[12:59:13 CDT(-0500)] <colinclark> cindyli: The other thing we're noticing, which might well be related, is that we don't get an error when we upload the same file twice
[13:00:01 CDT(-0500)] <cindyli> colinclark: this error is done on purpose
[13:00:16 CDT(-0500)] <colinclark> right, but we can't get it to happen on purpose
[13:00:20 CDT(-0500)] <colinclark> oh
[13:00:21 CDT(-0500)] <colinclark> sorry
[13:00:22 CDT(-0500)] <cindyli> Justin_o wants an error scenario
[13:00:26 CDT(-0500)] <colinclark> right
[13:00:26 CDT(-0500)] <colinclark> yes
[13:00:30 CDT(-0500)] <colinclark> but we can't get it to happen
[13:00:38 CDT(-0500)] <cindyli> oh, really.. haha
[13:00:39 CDT(-0500)] <colinclark> It happily takes the same file over and over again
[13:00:54 CDT(-0500)] <cindyli> ok. let me try mine
[13:01:36 CDT(-0500)] <cindyli> regarding strtotime() error, 2 ways to solve. in ur php.ini, set date.timezone to whatever we are at, or in the script, i call a function to set the default timezone
[13:01:41 CDT(-0500)] <cindyli> which way do u prefer, colinclark
[13:02:29 CDT(-0500)] <colinclark> I guess I might not be the only person who quickly sets this up on the stock PHP configuration
[13:02:38 CDT(-0500)] <colinclark> So if you think it makes sense, let's do the latter
[13:04:37 CDT(-0500)] <cindyli> ok
[13:30:12 CDT(-0500)] <cindyli> colinclark, Justin_o, the warning regarding strtotime() has been fixed and pushed into my github/image-gallery, which also fixed the issue that the error messages are displayed in the image view panel. you may want to try it out.
[13:35:41 CDT(-0500)] <heidi_> hey cindyli , where would i find the header for UIOptions.html ..and can we add it back into the file? Why was it removed? Just thinking we'll be making more .html template pages, with different .css includes
[13:37:44 CDT(-0500)] <cindyli> heidi_: it was removed on purpose. it was a full html before but not actaully necessary since it wa only used as a template, the header part that contains the js was executed and interfered the component itself
[13:38:01 CDT(-0500)] <cindyli> so, decided to be taken out
[13:38:26 CDT(-0500)] <heidi_> cindyli so how would i add say, a css file to it
[13:38:55 CDT(-0500)] <cindyli> heidi_: good question. give me a sec to dig ..
[13:39:08 CDT(-0500)] <heidi_> thanks digging here too!
[13:39:51 CDT(-0500)] <cindyli> heidi_: do u think it makes sense to include in caller html
[13:40:10 CDT(-0500)] <cindyli> heidi_: in that case, all themes need to be included
[13:41:43 CDT(-0500)] <colinclark> cool, i'll try it out, cindyli
[13:41:58 CDT(-0500)] <heidi_> cindyli yeah i'm not sure how this will work. am thinking UIOptions.html will be the default template (full with preview i think), but we'll also have UIOptions_skinny_panel.html etc. as well, and the implementer would specify with the UIOTemplateUrl option in the component. but to create those new template pages... they will need to be able to include their specific stylesheet
[13:43:00 CDT(-0500)] <cindyli> heidi_: understand. what if we put it back with only css, no js
[13:43:17 CDT(-0500)] <heidi_> cindyli that would be fine i think
[13:43:58 CDT(-0500)] <cindyli> heidi_: the js was there before was to make UIOptions.html itself a runnable ui options demo. ya, should be ok to put in css, i think
[13:44:39 CDT(-0500)] <Justin_o> colinclark, cindyli: So i'm thinking about the testing.. i think we could probably get away with testing the defaults for most cases...
[13:45:05 CDT(-0500)] <Justin_o> i think the areas that i know of that might be interesting to try things would be the file queue limit, the file size limit and maybe the file types
[13:45:12 CDT(-0500)] <heidi_> cindyli ah, i see. but it was interfering with parent js. cool... so i can add the header in minus js?
[13:45:36 CDT(-0500)] <cindyli> heidi_: yes i think
[13:45:45 CDT(-0500)] <heidi_> cindyli will try it - thanks
[13:45:52 CDT(-0500)] <cindyli> np
[13:45:53 CDT(-0500)] <Justin_o> colinclark, cindyli: we could probably just try images, as is the case now for the file types. the file queue limit could be set at some default level that isn't infinite
[13:46:16 CDT(-0500)] <Justin_o> colinclark, cindyli: the interesting one is the file size limit though.. i gathered from mlam that there are actually two limits..
[13:46:29 CDT(-0500)] <Justin_o> an upper ceiling that cannot be passed and a user defined limit
[13:46:35 CDT(-0500)] <Justin_o> it would be nice to be able to test both of those
[13:48:15 CDT(-0500)] <Justin_o> so i wonder if we could add in a ui for that... and if we are going to do that.. how hard would it be to be able to have ui's to adjust those three options
[13:49:04 CDT(-0500)] <cindyli> Justin_o: don't think it would be hard, just to find a place for 3 input boxes
[13:49:38 CDT(-0500)] <Justin_o> cindyli: i imagine though that this would result to some changes in the php settings... particularly for the file types expected.. is that correct?
[13:50:46 CDT(-0500)] <cindyli> Justin_o: no, i think it only affects the js end. server limitation is separate from the client.
[13:52:42 CDT(-0500)] <cindyli> Justin_o: server file types is to restrict the user to upload some executable that would result in security issues. for example, php or exe files, the users set the actually file types they would like to allow at the client side
[13:53:23 CDT(-0500)] <Justin_o> cindyli: ah i see
[13:54:01 CDT(-0500)] <colinclark> Justin_o and cindyli: There's one wrinkle to what you're trying to do... but it shouldn't be a big deal
[13:54:15 CDT(-0500)] <colinclark> At the moment, component options aren't designed to be changed dynamically
[13:54:18 CDT(-0500)] <cindyli> colinclark, Justin_o, when u try the image gallery, u may notice the error message is a bit weird like "3.jpg : Failed uploading. HTTP Status Code: 403", this is cuz the server returned error message is in xhr that is only available in browsers that support html5. after talking with mlam, decided to only display status code everywhere.
[13:54:32 CDT(-0500)] <colinclark> At least in theory, once you set an option for a component, it's set for life
[13:55:02 CDT(-0500)] <colinclark> Knowing the implementation of the Uploader, you might be able to get away with setting things like file size limits dynamically and having it all work...
[13:55:11 CDT(-0500)] <colinclark> but that's an implementation detail, and one we shouldn't exploit
[13:55:25 CDT(-0500)] <colinclark> So we'll need to "zap" the Uploader whenever a user changes a configuration option
[13:55:25 CDT(-0500)] <cindyli>
[13:55:37 CDT(-0500)] <colinclark> Meaning, get rid of the old one and create a new one with the specified configuration
[13:55:45 CDT(-0500)] <colinclark> Shouldn't be difficult
[13:56:31 CDT(-0500)] <colinclark> mlam: Can you elaborate on cindyli's point above? ^
[13:57:58 CDT(-0500)] <colinclark> Justin_o: In regards to your previous point about there being two upload limits in the Uploader...
[13:58:26 CDT(-0500)] <colinclark> I wonder if what you're referring to is the special "legacy limit" for browsers that will load the entire file into memory?
[13:58:31 CDT(-0500)] <colinclark> Or is it something else?
[13:58:48 CDT(-0500)] <colinclark> It seems to me that for everything except Firefox 3.6, there is actually only one file size limit
[13:59:02 CDT(-0500)] <colinclark> And I guess we must be getting closer to the point where Firefox 3.6 is no longer on our testing matrix?
[13:59:34 CDT(-0500)] <colinclark> Oh, by the way, while I'm thinking about versions, Justin_o, mlam, and harriswong, I noticed a Tweet from Resig today that jQuery 1.6 is destined to be released tomorrow
[13:59:48 CDT(-0500)] <colinclark> So you might as well focus your full attention on the 1.6 branch
[14:02:29 CDT(-0500)] <Justin_o> colinclark: thanks for the update on jquery
[14:02:52 CDT(-0500)] <Justin_o> colinclark: yes.. for the two limits that's what i was refering to, although i think mlam was saying that the limit is the true for all html5 versions at the moment
[14:02:54 CDT(-0500)] <mlam> colinclark: with regards to the file status codes being returned, at the moment, we only return what is given to us from the serverData and the response texts. we never implemented anything in terms of appropriate error messages to make translate the error codes
[14:03:30 CDT(-0500)] <colinclark> Ok
[14:03:35 CDT(-0500)] <colinclark> So the message cindyli mentioned above...
[14:03:37 CDT(-0500)] <mlam> colinclark: Justin_o, cindyli: yes, the legacy browser limit is currently implemented to work with all html5 types
[14:03:44 CDT(-0500)] <colinclark> "3.jpg : Failed uploading. HTTP Status Code: 403"
[14:03:49 CDT(-0500)] <mlam> colinclark: yes
[14:03:53 CDT(-0500)] <colinclark> That's coming from XMLHttpRequest directly?
[14:03:58 CDT(-0500)] <mlam> Yes
[14:04:01 CDT(-0500)] <colinclark> The browser is in control of this value?
[14:04:04 CDT(-0500)] <colinclark> ok
[14:04:07 CDT(-0500)] <colinclark> too bad
[14:04:32 CDT(-0500)] <colinclark> but that makes sense
[14:04:44 CDT(-0500)] <colinclark> and of course Flash doesn't pass along anything interesting in serverData
[14:05:20 CDT(-0500)] <mlam> cindy and i talked a while ago about creating functions in both flash and html5 strategies to translate these server error codes into a proper message. I'm sure it's not something slated for 1.4?
[14:05:36 CDT(-0500)] <colinclark> no
[14:05:47 CDT(-0500)] <colinclark> That'll be a nice feature for a future release
[14:06:09 CDT(-0500)] <colinclark> In the meantime, I'll make sure the ErrorHandlerView is capable of giving the user some control over this sort of message if they want to add it
[14:06:17 CDT(-0500)] <mlam> Yah, that was my understanding too, which is why we never brought it up
[14:06:40 CDT(-0500)] <colinclark> Cool
[14:06:46 CDT(-0500)] <colinclark> I just wanted to make sure I understood it correctly
[14:06:53 CDT(-0500)] <colinclark> cindyli: Nice work on the fixes to the Image Gallery
[14:06:58 CDT(-0500)] <colinclark> it's working nicely for me
[14:07:33 CDT(-0500)] <colinclark> So Justin_o, do you want cindyli to add those three options to the Gallery before we use it for QA?
[14:07:42 CDT(-0500)] <Justin_o> heidi_: wondering if you had a chance to look at FLUID-3880 again and what issues were left for FLUID-4150
[14:08:23 CDT(-0500)] <Justin_o> colinclark: sure, we could try to get it up on the daily build site in the mean time though if you guys wanted to test it out
[14:08:33 CDT(-0500)] <colinclark> Justin_o: Sounds like a good idea
[14:08:57 CDT(-0500)] <Justin_o> we could probably even build it from her repo till all the changes are in and then migrate it over the fluid-project space afterwards
[14:08:59 CDT(-0500)] <heidi_> Justin_o i'll look again - what changed in 3880? and for 4150, position:relative needs to be removed (you can see how it breaks the slider in UIO)... but it means abs positioned stuff doesn't linearize then, unless you can think of a way
[14:09:48 CDT(-0500)] <colinclark> So cindyli, I guess you can just, as you say, add a few text fields to the page. And then if any of them change, reinstantiate the Uploader?
[14:09:54 CDT(-0500)] <colinclark> Does that seem about right?
[14:10:17 CDT(-0500)] <Justin_o> heidi_: oh i switched some of the demos to use fl-focus instead of whatever focus styling they had
[14:10:22 CDT(-0500)] <Justin_o> if they were same
[14:10:22 CDT(-0500)] <cindyli> ok, colinclark
[14:11:03 CDT(-0500)] <heidi_> Justin_o ah yes, i'll look now
[14:11:12 CDT(-0500)] <Justin_o> heidi_: thanks
[14:11:48 CDT(-0500)] <Justin_o> heidi_: for the linearization, not sure.. but i'll try to take a look at it in a bit
[14:23:39 CDT(-0500)] <colinclark> cindyli: One other quick favour...
[14:23:51 CDT(-0500)] <colinclark> Can you add json2.js to the list of scripts your uploader.html includes?
[14:24:03 CDT(-0500)] <cindyli> sure. why?
[14:24:05 CDT(-0500)] <colinclark> It seems that Bosmon accidentally made it a framework-wide dependency back in March
[14:24:13 CDT(-0500)] <heidi_> Justin_o 3880 looks good. didn't realise it was just those two demos - great
[14:24:14 CDT(-0500)] <cindyli> ic. np
[14:24:29 CDT(-0500)] <colinclark> Closer to the release, we'll see if this is something we want or not
[14:24:38 CDT(-0500)] <colinclark> but in the meantime, I can't run your gallery in IE6
[14:24:49 CDT(-0500)] <Justin_o> heidi_: thanks for checking it out.. i'll try to get it in today or tomorrow
[14:24:49 CDT(-0500)] <cindyli> what the ...
[14:24:57 CDT(-0500)] <colinclark> yeah
[14:24:58 CDT(-0500)] <cindyli> errors? colinclark
[14:25:02 CDT(-0500)] <colinclark> it sucks
[14:25:04 CDT(-0500)] <colinclark> blame Bosmon
[14:25:34 CDT(-0500)] <cindyli> oh, ic, adding json2.js now
[14:30:08 CDT(-0500)] <cindyli> colinclark: added and pushed
[14:30:13 CDT(-0500)] <colinclark> thanks so much
[14:30:16 CDT(-0500)] <cindyli> np
[14:30:16 CDT(-0500)] <colinclark> sorry for the regression
[14:30:20 CDT(-0500)] <colinclark> I'm filing a JIRA about it now
[14:30:26 CDT(-0500)] <cindyli> np
[14:45:28 CDT(-0500)] <colinclark> cindyli: The new Gallery is looking hot in IE6 now
[14:46:41 CDT(-0500)] <cindyli> colinclark: great
[15:03:41 CDT(-0500)] <colinclark> heidi_: I caught up a bit in the channel logs on your chat with cindyli about UI Options and templates
[15:03:54 CDT(-0500)] <colinclark> I'm wondering if you can fill me in on a bit of background with that
[15:03:55 CDT(-0500)] <heidi_> colinclark cool, thoughts?
[15:04:00 CDT(-0500)] <colinclark> I find myself just slightly confused
[15:04:07 CDT(-0500)] <heidi_> which part?
[15:04:11 CDT(-0500)] <colinclark> Well, all of it
[15:04:20 CDT(-0500)] <colinclark> probably just because I don't have all the background
[15:04:24 CDT(-0500)] <colinclark> so you were talking about two things
[15:04:32 CDT(-0500)] <colinclark> an option for configuring UI Options' template
[15:04:48 CDT(-0500)] <colinclark> and about UI Options' template's <head>, or lack thereof
[15:04:56 CDT(-0500)] <colinclark> What did you end up deciding for each of those things, if anything?
[15:05:43 CDT(-0500)] <heidi_> yep exactly... i think the UIOTemplateURL option still makes sense. but the header am still unsure. it really doesn't make sense for the .html to have a <head> since it gets dumped inot an existing html page
[15:05:55 CDT(-0500)] <colinclark> right
[15:05:58 CDT(-0500)] <colinclark> Okay, so for the first one...
[15:06:05 CDT(-0500)] <colinclark> There's already an option, right?
[15:06:22 CDT(-0500)] <colinclark> I'm looking at the defaults for fluid.uiOptions, which is a rendererComponent
[15:06:44 CDT(-0500)] <heidi_> colinclark there's an option for specifying the preview template url
[15:06:45 CDT(-0500)] <colinclark> So it has an option called resources.template.url
[15:06:58 CDT(-0500)] <colinclark> Are you working in cindyli's branch, or in the project repo?
[15:07:37 CDT(-0500)] <heidi_> i thought i merged in cindy's branch, but now i'm confused... what line is resources.template on
[15:08:20 CDT(-0500)] <heidi_> did she recently push new stuff up?
[15:08:26 CDT(-0500)] <yura_> colinclark: is there a way to specify 2 listeners to component event in options ?
[15:08:29 CDT(-0500)] <colinclark> heidi_: Maybe you're not using her FLUID-4171 branch?
[15:08:38 CDT(-0500)] <colinclark> Lemme dig you up a link
[15:09:01 CDT(-0500)] <cindyli> line 257
[15:09:05 CDT(-0500)] <heidi_> maybe i'm not using git right
[15:09:05 CDT(-0500)] <colinclark> Here's the line where fluid.uiOptions' defaults start: https://github.com/cindyli/infusion/blob/FLUID-4171/src/webapp/components/uiOptions/js/UIOptions.js#L213
[15:09:08 CDT(-0500)] <cindyli> https://github.com/cindyli/infusion/blob/FLUID-4171/src/webapp/components/uiOptions/js/UIOptions.js
[15:09:10 CDT(-0500)] <colinclark> heidi_: eek
[15:09:31 CDT(-0500)] <colinclark> Okay, let's start at the beginning
[15:09:38 CDT(-0500)] <heidi_> colinclark quickly: i set cindy as a remote, i fetched cindy's stuff, then i merged in her FLUID-4171 branch
[15:09:52 CDT(-0500)] <colinclark> that sounds right to me
[15:10:13 CDT(-0500)] <colinclark> Do you not have code that looks like the link cindyli and I sent along?
[15:10:22 CDT(-0500)] <heidi_> i don't :s
[15:10:58 CDT(-0500)] <heidi_> i must be doing this wrong then
[15:11:13 CDT(-0500)] <heidi_> git fetch cindy , then while in my branch git merge cindy/FLUID-4171
[15:11:27 CDT(-0500)] <cindyli> looks good to me
[15:11:41 CDT(-0500)] <heidi_> it says "Already up-to-date."
[15:12:37 CDT(-0500)] <colinclark> What's the URL of "cindy" when you do a git remote -v, heidi_?
[15:12:44 CDT(-0500)] <heidi_> WAIT A MINUTE..... ugh so having a monday.
[15:12:55 CDT(-0500)] <heidi_> i have it
[15:13:07 CDT(-0500)] <heidi_> false alarm... had wrong UIOptions.js file open
[15:13:13 CDT(-0500)] <heidi_> okay, i see it now
[15:13:13 CDT(-0500)] <colinclark> lol
[15:13:15 CDT(-0500)] <colinclark>
[15:13:39 CDT(-0500)] <heidi_> okay so like 257
[15:13:42 CDT(-0500)] <heidi_> line
[15:13:42 CDT(-0500)] <colinclark> Okay, so you can see that cindyli has refactored UI Options a lot
[15:13:57 CDT(-0500)] <colinclark> There's already an option for the template's URL, which is cool
[15:13:57 CDT(-0500)] <heidi_> yes
[15:14:04 CDT(-0500)] <heidi_> yes good, ok
[15:14:27 CDT(-0500)] <colinclark> So, I think you're right that each flavour of UI Options will have a different HTML template
[15:14:43 CDT(-0500)] <colinclark> yura_: sorry, one sec
[15:14:55 CDT(-0500)] <colinclark> heidi_: I guess there's more to it than that, too
[15:15:04 CDT(-0500)] <colinclark> There will be a different template, and perhaps also some different subcomponents
[15:15:10 CDT(-0500)] <heidi_> am worried about duplicating so much code
[15:15:11 CDT(-0500)] <colinclark> In that the full page version will have a Preview subcomponent
[15:15:18 CDT(-0500)] <colinclark> heidi_: You're duplicated code?
[15:15:28 CDT(-0500)] <colinclark> duplicating
[15:15:28 CDT(-0500)] <heidi_> we can do a common .css file, and add specific .css for each template
[15:15:37 CDT(-0500)] <colinclark> That makes sense, yes
[15:16:04 CDT(-0500)] <heidi_> but that leaves the implementer having to change the template but also add the .css to their demo page
[15:16:14 CDT(-0500)] <colinclark> Let's get to that in a sec
[15:16:17 CDT(-0500)] <heidi_> which seems too separate
[15:16:19 CDT(-0500)] <heidi_> ok
[15:16:30 CDT(-0500)] <colinclark> So, our three different flavours...
[15:16:37 CDT(-0500)] <colinclark> What are the key differences between them all?
[15:16:45 CDT(-0500)] <heidi_> duplicating html is what i meant
[15:16:48 CDT(-0500)] <colinclark> right
[15:16:52 CDT(-0500)] <colinclark> we don't want to duplicate any HTML
[15:16:56 CDT(-0500)] <colinclark> and we needn't
[15:16:57 CDT(-0500)] <heidi_> agreed
[15:17:06 CDT(-0500)] <colinclark> So, they look different, for sure
[15:17:19 CDT(-0500)] <colinclark> Meaning they're definitely going to have different markup and a different stylesheet
[15:17:31 CDT(-0500)] <colinclark> They behave slightly differently, too, right?
[15:17:36 CDT(-0500)] <colinclark> Preview/no preview
[15:17:37 CDT(-0500)] <colinclark> What else?
[15:17:58 CDT(-0500)] <heidi_> each section/div of options is displayed differently, the stuff within them stays the same
[15:18:13 CDT(-0500)] <heidi_> fat panel and skinny panel
[15:18:17 CDT(-0500)] <colinclark> ah, right
[15:18:28 CDT(-0500)] <colinclark> Fat panel is very "panelly"
[15:18:39 CDT(-0500)] <colinclark> Meaning, you click on a section, and you see the settings in the area below
[15:18:50 CDT(-0500)] <colinclark> Whereas thin panel is more "menu-y"
[15:18:55 CDT(-0500)] <colinclark> Is that right, heidi_?
[15:19:12 CDT(-0500)] <heidi_> http://wiki.fluidproject.org/display/fluid/User+interface+options%2C+Infusion+1.4%2C+draft+1+mockups
[15:19:14 CDT(-0500)] <heidi_> yep
[15:20:01 CDT(-0500)] <colinclark> So, will the "controls" markup for the various versions need to change?
[15:20:18 CDT(-0500)] <colinclark> When I say "controls," I mean the markup for the individual settings
[15:20:38 CDT(-0500)] <colinclark> Like, could it be the same markup for Text & Colour across all three versions? Or will that change, too?
[15:20:50 CDT(-0500)] <colinclark> Definitely the styles are different
[15:21:29 CDT(-0500)] <heidi_> i think the markup for the settings will stay the same... i think. weary about agreeing on that limitation tho...
[15:23:03 CDT(-0500)] <heidi_> i see on jameswy's last fat panel image, there are links to "show advanced options" for the links and buttons sections that aren't in the others. whether we use that or not, that could be a possibility?
[15:23:43 CDT(-0500)] <colinclark> ah, interesting
[15:24:17 CDT(-0500)] <heidi_> jameswy is there a reason that's on this one and not the others, or was it a leftover bit ?
[15:24:24 CDT(-0500)] <colinclark> I can imagine that those advanced options aren't limited to only the fat panel version
[15:24:36 CDT(-0500)] <colinclark> When they are introduced, I imagine they will exist in them all
[15:24:46 CDT(-0500)] <colinclark> but only jameswy knows for sure, and he's on a call at the moment
[15:25:04 CDT(-0500)] <heidi_> yeah it's maybe not a great example. but i guess i'm wondering if there are any other possibilities for markup to change between views
[15:25:11 CDT(-0500)] <colinclark> It's quite possible
[15:25:20 CDT(-0500)] <colinclark> you're entirely correct to be wary of that
[15:25:21 CDT(-0500)] <jameswy> colinclark, heidi_: correct. If/when advanced options make it in, they'll exist in all panels. Not in existence right now.
[15:25:28 CDT(-0500)] <colinclark> thanks, dude
[15:25:46 CDT(-0500)] <heidi_> colinclark i think for now
[15:25:54 CDT(-0500)] <heidi_> prob safe to say it'll be the same throughout
[15:26:09 CDT(-0500)] <colinclark> So, heidi_, one of cindyli's next steps for UI Options will be to break down each section of UI Options into separate templates and components
[15:26:22 CDT(-0500)] <heidi_> ah, interesting, ok
[15:26:32 CDT(-0500)] <colinclark> So then, at least for as long as they stay the same, we can hopefully share markup between all versions
[15:26:44 CDT(-0500)] <heidi_> good to know, that'll help
[15:26:44 CDT(-0500)] <colinclark> if there's a case where the markup stops being the same, that's okay too
[15:26:56 CDT(-0500)] <heidi_> yeah can override in the template
[15:27:00 CDT(-0500)] <colinclark> since we'll have littler templates, there'll be a lot less markup duplicated
[15:27:30 CDT(-0500)] <colinclark> In the end, I don't think the implementer will need to worry about all these different templates, etc., unless they want to do their own special customizations
[15:27:45 CDT(-0500)] <heidi_> great, so now our UIO templates will just be shells
[15:27:54 CDT(-0500)] <colinclark> I don't know if this is what you were thinking, heidi_ and cindyli, but I imagine we might do something like what we did with the Reorderer...
[15:28:07 CDT(-0500)] <colinclark> where we have names that represent the various different configurations
[15:28:21 CDT(-0500)] <colinclark> so from an end-user perspective, all they have to do is ask for an imageReorderer
[15:28:38 CDT(-0500)] <colinclark> not really worrying about the fact that it's all just the same Reorderer with lots of things configured differently
[15:28:50 CDT(-0500)] <colinclark> so a user will probably just want to say "give me UI Options in a skinny panel" or whatever
[15:29:02 CDT(-0500)] <heidi_> does that mean the .css file can be an added resource
[15:29:07 CDT(-0500)] <colinclark> It might
[15:29:13 CDT(-0500)] <colinclark> I guess we have to think through that a bit more
[15:29:16 CDT(-0500)] <heidi_> instead of up to the implementer to add to their site
[15:29:22 CDT(-0500)] <colinclark> You're on to something sort of interesting, heidi_
[15:29:42 CDT(-0500)] <colinclark> I guess Reorderer is probably our best example
[15:29:48 CDT(-0500)] <colinclark> it looks very different depending on its flavour
[15:30:28 CDT(-0500)] <colinclark> And so there is a special ImageReorderer.css file for users who want it to look like an Image Reorderer
[15:30:30 CDT(-0500)] <heidi_> i see prevew template url has been removed as an option as well
[15:30:39 CDT(-0500)] <colinclark> heidi_: Preview is now a subcomponent
[15:30:44 CDT(-0500)] <colinclark> so it's an option for it
[15:30:49 CDT(-0500)] <colinclark> instead of for UI Options
[15:30:52 CDT(-0500)] <heidi_> ah, k
[15:30:57 CDT(-0500)] <colinclark> UI Options is now minding its own business
[15:31:20 CDT(-0500)] <colinclark> So, heidi_, will an implementer ever want to deploy more than one flavour of UI Options at the same time?
[15:31:33 CDT(-0500)] <colinclark> or will they always just say "my site uses the fat panel" or whatever?
[15:31:51 CDT(-0500)] <heidi_> i would think mostly they would use one flavour
[15:31:58 CDT(-0500)] <heidi_> however, possibly more
[15:32:08 CDT(-0500)] <colinclark> jameswy: What do you think?
[15:32:20 CDT(-0500)] <colinclark> Assuming, for the moment, that they'll probably pick one flavour and stick with it
[15:32:23 CDT(-0500)] <heidi_> if they have a particular page where a full w. preview would work better... not sure
[15:32:57 CDT(-0500)] <colinclark> Do you think it's too much to ask them to link in two CSS files: a base UIOptions.css and then a flavour-specific CSS? (e.g. UIOptionsFatPanel.css)
[15:33:49 CDT(-0500)] <heidi_> there's also Slider.css
[15:33:54 CDT(-0500)] <heidi_> and all the themes
[15:33:56 CDT(-0500)] <heidi_> hmm
[15:34:20 CDT(-0500)] <jameswy> colinclark, heidi_: I can't ever see them using both panel configurations, but I can see a panel and full page configuration working together in some cases.
[15:34:33 CDT(-0500)] <heidi_> can we have one .css with @imports
[15:35:45 CDT(-0500)] <colinclark> heidi_: For sure
[15:35:58 CDT(-0500)] <colinclark> although there are good performance reasons why you wouldn't want to use that in production
[15:36:10 CDT(-0500)] <colinclark> jameswy: That's good to know
[15:36:11 CDT(-0500)] <colinclark> S
[15:36:26 CDT(-0500)] <colinclark> So they'd probably have a panel on every page, and then the full UIO on a different page
[15:36:38 CDT(-0500)] <heidi_> yeah
[15:37:10 CDT(-0500)] <colinclark> So I think we're really hitting on the point that maybe we need to concatenate our CSS like we do for our JavaScript
[15:37:38 CDT(-0500)] <colinclark> Uploader has several stylesheets to include, too
[15:38:17 CDT(-0500)] <heidi_> in the meantime, i think adding one more .css to the list won't hurt
[15:38:22 CDT(-0500)] <colinclark> ok
[15:38:27 CDT(-0500)] <colinclark> I think the themes will get interesting...
[15:38:34 CDT(-0500)] <colinclark> We'll probably load those ones programmatically
[15:38:55 CDT(-0500)] <colinclark> since we will actually be loading special UI Options versions of them, which should only be included in the page under certain circumstances
[15:38:57 CDT(-0500)] <heidi_> can we load in the UIO template specific .css too?
[15:39:16 CDT(-0500)] <colinclark> we could, but there's a real downside to that
[15:39:24 CDT(-0500)] <colinclark> flickering
[15:39:32 CDT(-0500)] <heidi_> yeah the timing would be weird
[15:39:36 CDT(-0500)] <colinclark> A page loads a certain amount, and then some code comes along and injects a stylesheet
[15:39:39 CDT(-0500)] <colinclark> and suddenly it looks different
[15:39:51 CDT(-0500)] <colinclark> It makes for a pretty ugly user experience
[15:40:14 CDT(-0500)] <colinclark> which is why we always asked users to link in the appropriate stylesheets themselves, since they can do it much earlier than our code can
[15:40:32 CDT(-0500)] <colinclark> The themes are a different story, though
[15:40:43 CDT(-0500)] <heidi_> okay. it just seems weird that if someone wants to change how their UIO looks, they change the template option in the js, but then the .css in their html page... seems like they should be in the same place. but no biggie
[15:41:09 CDT(-0500)] <colinclark> Well, that was my point earlier, heidi_
[15:41:17 CDT(-0500)] <colinclark> I don't think they'll typically change the configuration option directly
[15:41:26 CDT(-0500)] <colinclark> Have a look at how the Reorderer demos in the demo portal works
[15:41:36 CDT(-0500)] <heidi_> how are themes different?
[15:41:41 CDT(-0500)] <colinclark> a user just asks for, say, fluid.imageReorderer() and they get it
[15:41:48 CDT(-0500)] <heidi_> ah, right
[15:41:48 CDT(-0500)] <colinclark> or they ask for fluid.gridReorderer(), and they get it
[15:42:10 CDT(-0500)] <colinclark> and so really, you're changing everything at the same place--the page's markup itself
[15:42:21 CDT(-0500)] <colinclark> The themes are different because of our conversation last week
[15:42:24 CDT(-0500)] <colinclark> About !important
[15:42:41 CDT(-0500)] <heidi_> right...
[15:42:42 CDT(-0500)] <colinclark> So, imagine a case where someone is, say, using coal for their site's default look and feel
[15:43:10 CDT(-0500)] <colinclark> if we asked them to also link in the special UI Options version of the high contrast theme, we might well have problems
[15:43:10 CDT(-0500)] <colinclark> I guess perhaps the themes are all fully scoped
[15:43:14 CDT(-0500)] <colinclark> in which case they're not so special after all
[15:43:37 CDT(-0500)] <colinclark> But I guess the point is that they're really related to the behaviour of the component, not something the user wants
[15:43:43 CDT(-0500)] <colinclark> Does that make any sense?
[15:44:12 CDT(-0500)] <heidi_> mmm, sorta kinda
[15:44:17 CDT(-0500)] <colinclark> Like, it makes sense for me to link in FatPanel.css because I want a fat panel, but it seems weird to also ask me to link the High Contrast theme into my page for no reason
[15:44:37 CDT(-0500)] <colinclark> In other words, if a user never bothers to come along and transform the page to High Contrast, why are we sending down that theme's style sheet at all?
[15:44:41 CDT(-0500)] <heidi_> right, but if the user has chosen high contrast, wouldn't you get flickering to load it in later?
[15:44:55 CDT(-0500)] <colinclark> Not if we don't get flickering now
[15:45:09 CDT(-0500)] <colinclark> In other words, we're already dynamically changing the style of the page with UI Options
[15:45:37 CDT(-0500)] <heidi_> but the theme's .css file is in the head, added by the implementer
[15:45:57 CDT(-0500)] <heidi_> maybe i misunderstood ... scrolling up
[15:46:00 CDT(-0500)] <colinclark> Right, but it's there doing nothing
[15:46:19 CDT(-0500)] <heidi_> it's only doing nothing if that theme isn't chosen
[15:47:03 CDT(-0500)] <heidi_> okay when you said the themes are a different story, maybe that didn't mean the themes should no longer be added by the implementer in the <head> ?
[15:47:27 CDT(-0500)] <colinclark> No, I did mean that
[15:47:32 CDT(-0500)] <colinclark> Assuming I'm thinking clearly
[15:47:41 CDT(-0500)] <heidi_> okay... so if a user has changed their page to use a theme
[15:47:54 CDT(-0500)] <heidi_> but that theme .css isn't in the <head> right away, but added programically later
[15:48:03 CDT(-0500)] <heidi_> wouldn't that be flickery?
[15:48:25 CDT(-0500)] <colinclark> I don't think so...
[15:48:33 CDT(-0500)] <colinclark> So, how will they change the theme--the end user?
[15:48:41 CDT(-0500)] <heidi_> yeah
[15:49:10 CDT(-0500)] <colinclark> They'll pick it from the menu in UI Options, and then click the "Apply" button or whatever
[15:49:23 CDT(-0500)] <heidi_> they would've changed the theme, and it would be in their cache as a preference, and when they come to that page, that theme would load
[15:49:55 CDT(-0500)] <colinclark> I guess it just means that UI Enhancer has to do its work very very early
[15:50:00 CDT(-0500)] <colinclark> or you're right, then they'd get flickering
[15:51:01 CDT(-0500)] <colinclark> But if it were UI Enhancer's job to inject the appropriate stylesheet, we wouldn't need to ask the implementer to link in all these extra, apparently unnecessary style sheets
[15:51:01 CDT(-0500)] <colinclark> which will be carried around on every single page, but perhaps only used by certain users or at certain times
[15:51:16 CDT(-0500)] <colinclark> Does that make sense? I'm not sure I'm thinking clearly
[15:52:34 CDT(-0500)] <heidi_> i definitely prefer that method, much cleaner. so i guess the difference between the theme .css files is that they're loaded by enhancer, not uioptions? ie. for programically loading say UIOptions_FatPanel.css
[15:53:17 CDT(-0500)] <heidi_> also, maybe this is a silly question cindyli, but right now if someone adds UIO to their website, and it's on every page, do the styles they choose with it apply to the whole site or just that page they're on?
[15:53:40 CDT(-0500)] <heidi_> ah she's gone
[15:56:20 CDT(-0500)] <colinclark> I'm pretty sure they need to link in the themes on each and every page
[15:56:23 CDT(-0500)] <colinclark> which is a drag to say the least
[15:56:51 CDT(-0500)] <colinclark> UI Enhancer should be responsible for loading only whichever theme the user asked for
[15:57:01 CDT(-0500)] <colinclark> UI Options should probably just be ordinary, like any other component
[15:57:07 CDT(-0500)] <heidi_> colinclark i mean the caching of styles - does it apply the .css to every page on the site or just the page that it's on?
[15:57:16 CDT(-0500)] <colinclark> Meaning, a user links its two CSS files wherever they want a UI Options to appear
[15:57:44 CDT(-0500)] <colinclark> UI Options doesn't really do anything
[15:58:11 CDT(-0500)] <colinclark> UI Enhancer, whenever it's included on a page
[15:58:16 CDT(-0500)] <colinclark> will "enhance" it
[15:58:29 CDT(-0500)] <heidi_> but if it's been previously enhanced
[15:58:37 CDT(-0500)] <heidi_> is it just that page, or the whole site that changes
[15:58:48 CDT(-0500)] <colinclark> I'm not sure I follow
[15:58:50 CDT(-0500)] <heidi_> i'm guessing just that page? or is there a way to control that
[15:59:00 CDT(-0500)] <colinclark> As far as JavaScript is concerned, the world ends at the page
[15:59:03 CDT(-0500)] <colinclark>
[15:59:08 CDT(-0500)] <heidi_> k, you have a website with UIO panel at the top of every page
[15:59:28 CDT(-0500)] <heidi_> on a particular page, you open UIO and tweak the look, and close it. then you go to another page on the site.
[15:59:55 CDT(-0500)] <colinclark> yes
[16:00:00 CDT(-0500)] <heidi_> do you have to tweak every page? or do the styles apply throughout? is it a possibilty to do that?
[16:00:12 CDT(-0500)] <colinclark> Who is "you" here?
[16:00:16 CDT(-0500)] <colinclark> The UI Enhancer?
[16:00:24 CDT(-0500)] <heidi_> jameswy was thinking you'd make the changes on one page and it'd apply to the entire site
[16:00:29 CDT(-0500)] <heidi_> the end user, sorry
[16:01:15 CDT(-0500)] <colinclark> Yep, it would apply to the whole site
[16:01:21 CDT(-0500)] <heidi_> okay, awesome
[16:01:30 CDT(-0500)] <colinclark> That is, assuming each page in the whole site links in the UI Enhancer
[16:01:51 CDT(-0500)] <heidi_> k
[16:02:51 CDT(-0500)] <colinclark> So, in terms of a <head> for UI Options' templates
[16:03:00 CDT(-0500)] <colinclark> seems like we shouldn't ever have one, right?
[16:03:00 CDT(-0500)] <colinclark> s
[16:03:05 CDT(-0500)] <heidi_> agreed
[16:03:07 CDT(-0500)] <colinclark> since UI Options goes in someone else's page
[16:03:21 CDT(-0500)] <heidi_> and we'll get the implementer to add the extra .css file depending on the UIO layout they choose
[16:03:36 CDT(-0500)] <colinclark> Right
[16:03:50 CDT(-0500)] <heidi_> and the template choice is already possible as an option with cindy's changes (cool)
[16:03:58 CDT(-0500)] <colinclark> and since it's only one extra CSS file, it's probably not onerous for the implementer
[16:04:00 CDT(-0500)] <colinclark> great!
[16:04:10 CDT(-0500)] <heidi_> and soon all the controls will have their own templates
[16:04:18 CDT(-0500)] <colinclark> yes, exactly
[16:04:30 CDT(-0500)] <heidi_> so the UIO templates will just be shell to lay that stuff out, not dup markup
[16:04:34 CDT(-0500)] <heidi_> alright!
[16:04:47 CDT(-0500)] <heidi_> thanks colinclark for clarifying all this
[16:05:15 CDT(-0500)] <colinclark> np
[16:05:16 CDT(-0500)] <colinclark> this was fun
[16:05:26 CDT(-0500)] <heidi_> yeah UIO is pretty neat