/
fluid-work IRC Logs-2008-12-04

fluid-work IRC Logs-2008-12-04

Dec 04, 2008

[01:08:24 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[02:36:22 EST(-0500)] * famicom (i=famicom@5ED2FF2D.cable.ziggo.nl) has joined #fluid-work
[04:04:13 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[04:06:28 EST(-0500)] * phiggins_ (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[08:09:58 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined #fluid-work
[08:19:01 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[08:21:17 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[08:26:01 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[08:50:46 EST(-0500)] * clown (n=clown@bas1-cooksville17-1279271796.dsl.bell.ca) has joined #fluid-work
[09:16:20 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[09:35:30 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[09:45:52 EST(-0500)] * athena7 (n=athena7@adsl-99-164-85-168.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[09:49:04 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[09:49:42 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279621226.dsl.bell.ca) has joined #fluid-work
[09:53:17 EST(-0500)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[09:53:44 EST(-0500)] * Topic is 'Stop eating all the cookies!' set by colinclark on 2008-12-04 09:53:44 EST(-0500)
[10:28:15 EST(-0500)] * athena7 (n=athena7@adsl-99-164-85-168.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[10:29:43 EST(-0500)] * Topic is 'ApoCATTastasis' set by colinclark on 2008-12-04 10:29:43 EST(-0500)
[10:40:10 EST(-0500)] <sgithens342f> does anyone have opinions on either of the jQuery books
[10:40:37 EST(-0500)] <sgithens342f> I'd like to order a few for our office since it's a common thing that folks are having to pick up
[10:41:03 EST(-0500)] <sgithens342f> and the online documentation isn't always great for getting started
[10:47:45 EST(-0500)] <sgithens342f> or actually they are all on Safari
[10:58:29 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[11:18:33 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279621226.dsl.bell.ca) has joined #fluid-work
[11:19:12 EST(-0500)] <colinclark> sgithens342f: I missed your earlier question, sorry.
[11:19:26 EST(-0500)] <colinclark> jQuery in Action is the better one that I've encountered.
[11:19:30 EST(-0500)] <sgithens342f> ah cool
[11:19:47 EST(-0500)] <sgithens342f> boundless cheers
[11:19:57 EST(-0500)] <colinclark> I wouldn't bother with Learning jQuery, because it is really pretty much the online documentation verbatim.
[11:20:17 EST(-0500)] <colinclark> I have one other book suggestion that is not jQuery-specific.
[11:20:17 EST(-0500)] <sgithens342f> ok, that's actually really helpful to know
[11:20:30 EST(-0500)] <colinclark> JavaScript: The Good Parts
[11:20:31 EST(-0500)] <colinclark> http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742/ref=pd_bbs_sr_4?ie=UTF8&amp;s=books&amp;qid=1228407579&amp;sr=8-4
[11:20:36 EST(-0500)] <colinclark> It's really really good.
[11:20:49 EST(-0500)] <colinclark> Short but very dense.
[11:21:02 EST(-0500)] <sgithens342f> yeah, I saw that on the search and added it to my shopping list
[11:21:06 EST(-0500)] <sgithens342f> only 170 pages!
[11:21:19 EST(-0500)] <sgithens342f> doable in a weekend!
[11:21:54 EST(-0500)] <sgithens342f> really looking forward to the lisp comparison chapter
[11:21:54 EST(-0500)] <colinclark> Yep, exactly. You may want to read it twice, since there's a lot in there.
[11:24:02 EST(-0500)] <colinclark> Have you seen his page where he implements the Little Schemer code in JavaScript?
[11:24:24 EST(-0500)] <colinclark> http://javascript.crockford.com/little.html
[11:24:26 EST(-0500)] <sgithens342f> so, I've got fluid0.6beta1 and am trying to figure out which version of ui.draggable.js. I did a
[11:24:28 EST(-0500)] <sgithens342f> ~/code/fluid0.6beta1/fluid-components/js/jquery -> egrep -iR "version" ui.draggable.js
[11:24:36 EST(-0500)] <sgithens342f> but didn't see anything
[11:24:42 EST(-0500)] <sgithens342f> oh cool
[11:24:45 EST(-0500)] <sgithens342f> thanks for the link
[11:24:49 EST(-0500)] <sgithens342f> I haven't seen that
[11:24:52 EST(-0500)] <sgithens342f> that's really cool
[11:25:03 EST(-0500)] <colinclark> sgithens342f: Let me check. We should probably do a better job of versioning our dependencies.
[11:25:38 EST(-0500)] <michelled> I think we have a readme that states the version
[11:26:06 EST(-0500)] <colinclark> michelled: Ok, cool.
[11:26:34 EST(-0500)] <colinclark> Hmm, doesn't look like it does.
[11:26:40 EST(-0500)] * jessm_ (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined #fluid-work
[11:26:49 EST(-0500)] <colinclark> aha
[11:26:52 EST(-0500)] <sgithens342f> I checked in Fluid-0.6beta1/README.txt
[11:27:04 EST(-0500)] <colinclark> sgithens342f: That's where it should be.
[11:27:10 EST(-0500)] <colinclark> But we have deviously buried it elsewhere.
[11:27:29 EST(-0500)] <colinclark> https://source.fluidproject.org/svn/fluid/components/trunk/src/webapp/fluid-components/js/jquery/ui-FLUID-readme.txt
[11:27:40 EST(-0500)] <colinclark> I will file a bug to move that information into the main README.txt file.
[11:27:58 EST(-0500)] <sgithens342f> cool, that is probably the same from the beta then too
[11:29:51 EST(-0500)] <colinclark> Yep.
[11:30:08 EST(-0500)] <colinclark> We should probably update to UI 1.5.3 for the final release.
[11:31:01 EST(-0500)] <colinclark> anastasiac: I filed a JIRA with you for this issue.
[11:31:13 EST(-0500)] <anastasiac> cool, thanks colinclark
[11:31:15 EST(-0500)] <colinclark> I guess I'll file one for updating to the latest version of UI?
[11:31:21 EST(-0500)] <anastasiac> please
[11:31:27 EST(-0500)] <anastasiac> #s ?
[11:31:52 EST(-0500)] <colinclark> README changes: http://issues.fluidproject.org/browse/FLUID-1921
[11:32:28 EST(-0500)] <colinclark> There's a JIRA for upgrading to 1.6, but it's still not out.
[11:32:29 EST(-0500)] <colinclark> http://issues.fluidproject.org/browse/FLUID-1658
[11:33:26 EST(-0500)] <colinclark> Upgrade to 1.5.3: http://issues.fluidproject.org/browse/FLUID-1922
[11:33:57 EST(-0500)] <athena7> so probably not uprade to 1.6 then?
[11:38:41 EST(-0500)] <colinclark> athena7: Good question.
[11:38:54 EST(-0500)] <colinclark> Have you used 1.6 much yet?
[11:38:59 EST(-0500)] <colinclark> It's still in beta/
[11:39:19 EST(-0500)] <Bosmon> sgithens342f:
[11:39:29 EST(-0500)] <Bosmon> I am wondering how you ever got <tr> elements to work with JQuery sortable
[11:39:34 EST(-0500)] <athena7> nope i've held off on upgrading since i wasn't sure if fluid was going to upgrade
[11:39:37 EST(-0500)] <Bosmon> Since there is a ticket on them at the moment that they don't work
[11:39:48 EST(-0500)] <Bosmon> At least, they don't work in IE6
[11:40:43 EST(-0500)] <athena7> it would probably be better for us if fluid had 1.6 in it as of the 3.0 release, since we could avoid having to do the 1.5-1.6 and associated re-skinning in a minor dot release
[11:40:55 EST(-0500)] <sgithens342f> Bosmon: I haven't yet. Was just about to try it here. I was simultaneously moving to a table and the Fluid Reorderer. I was switching to a table because it's highly likely our designers are going to want to add another column or stuff of two in future iterations.
[11:41:17 EST(-0500)] <sgithens342f> if the jquery.sortable works in IE7 it's ok
[11:41:26 EST(-0500)] <Bosmon> Really?
[11:41:32 EST(-0500)] <Bosmon> You can drop IE6 support?
[11:41:39 EST(-0500)] <sgithens342f> I know it's lame but we're mostly focused on FF and IE7
[11:41:47 EST(-0500)] <sgithens342f> yes, please don't punch me
[11:41:55 EST(-0500)] <Bosmon> I will not punch you
[11:42:02 EST(-0500)] <Bosmon> Your users may punch you
[11:42:19 EST(-0500)] <Bosmon> Developers are always amongst the first people wanting to drop IE6 support
[11:42:28 EST(-0500)] <sgithens342f> Actually, I didn't really want to
[11:42:48 EST(-0500)] <sgithens342f> I definately did not choose to drop it
[11:42:53 EST(-0500)] <Bosmon>
[11:42:56 EST(-0500)] <athena7> how about drop all IE support
[11:42:58 EST(-0500)] <athena7> i'd do it!
[11:43:54 EST(-0500)] <sgithens342f> however, I have a hard hard deadline of December 12th, and it's actually taking me a while to get things working in just FF and IE7, so I'm not as outspoken about supporting other versions as I was a few months ago.
[11:44:34 EST(-0500)] <sgithens342f> will grab some lunch quick
[11:57:45 EST(-0500)] <athena7> so anyway colin, it'd be cool if jquery ui 1.6 was there since it would mean fewer changes further down the line, but we weren't counting on it, and it's not a big deal
[11:58:07 EST(-0500)] <colinclark> athena7: Ok, good to know.
[12:02:17 EST(-0500)] <Bosmon> colinclark: Justin and I are having an issue with writing the "live" tests targetted at the portlet layout
[12:02:44 EST(-0500)] <Bosmon> Justin has noticed, for example, that the "lightbox" portlet will drag to different positions on keyboard drag, in FF2 and FF3
[12:02:55 EST(-0500)] <Bosmon> This is due to differences in layout, which seem basically unavoidable
[12:03:22 EST(-0500)] <Bosmon> But in fact it might be almost impossible to place any constraints on what the "correct" position is for this portlet, when dragged to the right-hand column
[12:05:13 EST(-0500)] <Justin_o> one option would be to make the test less strict about where the portlet should be, but the less strict the test, the less valid it becomes
[12:05:59 EST(-0500)] <colinclark> Hmm.
[12:06:00 EST(-0500)] <Bosmon> Unfortunately, the only sound way I can think of to determine the "correct" place for the portlet is to run the same code which is in GeometricManager
[12:06:05 EST(-0500)] <Bosmon> Which is not really much of a test
[12:12:30 EST(-0500)] * jrnorman (n=john@ginger.caret.cam.ac.uk) has joined #fluid-work
[12:16:55 EST(-0500)] <Justin_o> Bosmon: I'm also having an issue with IE. I attempted to run my tests in IE7 on windows vista. It is giving me invalid argument error and is breaking on line 289 of jquery-1.2.6.js
[12:17:33 EST(-0500)] <Justin_o> I believe that it may have to do with the clone function i am calling
[12:17:51 EST(-0500)] <Bosmon> ok
[12:17:57 EST(-0500)] <Bosmon> What are you calling it on, and why?
[12:18:44 EST(-0500)] <Justin_o> i am calling it on the body of the page that the iframe brings in. I do this so that after each test case is run i can reset the page to it initial state
[12:18:56 EST(-0500)] <Bosmon> Hmm
[12:19:03 EST(-0500)] <Bosmon> I guess the iframe issue was already ringing bells
[12:19:04 EST(-0500)] <Justin_o> if you want to look at the code it is in the sandbox
[12:19:19 EST(-0500)] <Justin_o> iframes do make things difficult
[12:19:27 EST(-0500)] <Bosmon> I'm not sure that is going to be a reliable method
[12:20:07 EST(-0500)] <Bosmon> What about the state of event handlers, and Javascript, and other collateral stuff?
[12:20:16 EST(-0500)] <Justin_o> i do have to call the initialization functions of the components after replacing the body with the clone
[12:20:21 EST(-0500)] <Bosmon> ok
[12:20:32 EST(-0500)] <Bosmon> Well, I guess this is relying on the fact that all the code in the frame is "ours"
[12:20:36 EST(-0500)] <Bosmon> And going to be tolerably well-behaved
[12:20:57 EST(-0500)] <Justin_o> yes... at least for the time being i think that is an okay assumption
[12:21:09 EST(-0500)] <Bosmon> It won't be, when you come to write the tests for rich text inline edit
[12:22:16 EST(-0500)] <Justin_o> i thought uploader would be my only challenge, but it seems like there's much more to come
[12:22:30 EST(-0500)] <Bosmon> In any case, what I recommend for now is that you just switch to using innerHTML
[12:22:33 EST(-0500)] <Bosmon> The way JQUnit does
[12:23:30 EST(-0500)] <Justin_o> so instead of doing this
[12:23:31 EST(-0500)] <Justin_o> bodyClone = $("body", iFrame).clone();
[12:23:34 EST(-0500)] <Justin_o> i do something like
[12:23:41 EST(-0500)] <Justin_o> bodyClone = $("body", iFrame).innerHTML();
[12:24:33 EST(-0500)] * ecochran (n=ecochran@dhcp-169-229-212-44.LIPS.Berkeley.EDU) has joined #fluid-work
[12:24:55 EST(-0500)] <Bosmon> Well, is it a method?
[12:25:01 EST(-0500)] <Bosmon> You may as well just go for the raw one in the DOM
[12:25:12 EST(-0500)] <Bosmon> But yes, now I see your example, I can see where it is going wrong
[12:25:26 EST(-0500)] <Bosmon> I doubt JQuery understands how to clone nodes across iframes, since they are part of separate documents
[12:25:46 EST(-0500)] <Bosmon> All the more reason to go for innerHTML
[12:26:21 EST(-0500)] <Justin_o> okay... thanks... i'll give that a shot
[12:27:21 EST(-0500)] <Bosmon> Note that this whole approach is dangerous if the body contains any <script> blocks
[12:27:39 EST(-0500)] <Bosmon> I think that with innerHTML you will be safe from that too
[12:28:15 EST(-0500)] <Justin_o> so it should be better in a lot of respects, that's good...
[12:35:08 EST(-0500)] <Justin_o> Bosmon: after using innerHTML the page doesn't work
[12:36:04 EST(-0500)] <Justin_o> i'm not too sure why though as it seems to be giving me back the right information that i need. The page just isn't being reset properly. I wonder if this has to do with the fact that the initialization function is in the body
[12:51:17 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[12:58:29 EST(-0500)] <Bosmon> Is it?
[12:58:38 EST(-0500)] <Bosmon> How do you know to call it in the tests then...
[13:00:52 EST(-0500)] <Justin_o> those initialization functions are exposed and i can call them from my js
[13:01:40 EST(-0500)] <Justin_o> the error i'm getting in ff2 is doc.body has no properties line 3434 of jquery-1.2.6.js
[13:21:31 EST(-0500)] <famicom> EH YO
[13:21:34 EST(-0500)] <famicom> people!
[13:21:36 EST(-0500)] <famicom> hey
[13:21:44 EST(-0500)] <famicom> i was playin with liquid
[13:22:05 EST(-0500)] <famicom> and it seems as if some of the stuff us broken
[13:22:15 EST(-0500)] <famicom> as in buttons etc not doing anything
[13:24:47 EST(-0500)] <michelled> famicom: do you mean infusion?
[13:27:51 EST(-0500)] <famicom> could be
[13:28:51 EST(-0500)] <famicom> hold on
[13:28:57 EST(-0500)] <famicom> im, mentally AFK
[13:30:00 EST(-0500)] <famicom> I'm tring to clean this disk, but it's a bit worse than i though
[13:30:19 EST(-0500)] <colinclark> famicom: ?
[13:32:05 EST(-0500)] <famicom> im cleaning up the office my work station is in
[13:32:22 EST(-0500)] <famicom> but i'm burried in 10 tons of old paper invoices and tech manuals
[13:32:42 EST(-0500)] <colinclark> Wow.
[13:33:46 EST(-0500)] <famicom> i have the habit of using dead tree books for reference
[13:34:15 EST(-0500)] <famicom> which wouldnt be a big deal, if it wasnt for the fact that i just throw in the pile behind me, rather than putting them back on the shelf
[13:35:45 EST(-0500)] <famicom> coudl someone link me to the project homepage
[13:36:06 EST(-0500)] <Bosmon> Are you sure you have turned up to the right place?
[13:36:12 EST(-0500)] <michelled> well our web site is out of date so you're probably better to look at the wiki
[13:36:16 EST(-0500)] <michelled> wiki.fluidproject.org
[13:36:53 EST(-0500)] <michelled> http://fluidproject.org/ in case you want to check it out anyway
[13:38:17 EST(-0500)] <famicom> http://build.fluidproject.org/fluid/fluid-components/html/templates/Uploader.html
[13:39:53 EST(-0500)] <michelled> ecochran or colinclark are probably best to answer questions on uploader
[13:40:06 EST(-0500)] <michelled> although Justin_o seems to know the state of everything
[13:40:17 EST(-0500)] <ecochran> ok, I'm catching up...
[13:40:20 EST(-0500)] <anastasiac> famicon, are you having difficulty using the Uploader at the link you provided?
[13:40:21 EST(-0500)] <ecochran> give me a sec
[13:40:33 EST(-0500)] <famicom> actually
[13:40:33 EST(-0500)] <anastasiac> famicom ^ (sorry, misspelled)
[13:40:46 EST(-0500)] <famicom> it was an example of an issue that i encountered in various examples
[13:41:02 EST(-0500)] <famicom> buttons that dont really do anything, and no clear errors in my JS console
[13:41:03 EST(-0500)] <anastasiac> can you describe the issue a bit more?
[13:41:27 EST(-0500)] <anastasiac> which button, for example, in the Uploader example doesn't work?
[13:42:25 EST(-0500)] <ecochran> famicom: I suspect that I know what the issue is... since this is a template and there are no default behaviors for btns such as Cancel, things don't seem to work. Is that the issue?
[13:42:59 EST(-0500)] <ecochran> Stop Upload should have a default behavior but we haven't hooked it up yet
[13:43:12 EST(-0500)] <ecochran> Or are you seeing something else?
[13:43:41 EST(-0500)] <famicom> nah
[13:43:43 EST(-0500)] <famicom> thats the thing
[13:43:49 EST(-0500)] <famicom> but why didnt anyone provide a NOTE OF THAT
[13:45:21 EST(-0500)] <ecochran> part of the reason is that we're in the last stretch before a release, and things are changing faster than we can document them
[13:45:27 EST(-0500)] <ecochran> but that is no excuse
[13:46:01 EST(-0500)] <ecochran> If you'd like a little richer Uploader experience try: http://build.fluidproject.org:8080/sakai-imagegallery2-web/site/BrowseImages/
[13:46:32 EST(-0500)] <anastasiac> I would expect that the styling of the inactive buttons should make it clear that they're inactive
[13:47:16 EST(-0500)] <ecochran> the Cancel and Stop Upload buttons are not currently "inactive" because in a real integration they developer would provide behavior for them
[13:47:17 EST(-0500)] <famicom> anastasiac in that case you really need to study more about user interaction
[13:47:32 EST(-0500)] <ecochran> excuse me?
[13:48:08 EST(-0500)] <ecochran> anastasiac is correct
[13:48:28 EST(-0500)] <ecochran> the normal behavior should be that buttons that are inactive are dimmed
[13:48:36 EST(-0500)] <famicom> actually
[13:48:37 EST(-0500)] <famicom> http://build.fluidproject.org:8080/sakai-imagegallery2-web/site/AddImages/
[13:48:37 EST(-0500)] <anastasiac> famicom, you're right - I'm not an interaction designer, I'm a developer
[13:48:42 EST(-0500)] <ecochran> in this case they are not
[13:48:42 EST(-0500)] <famicom> disable css
[13:48:52 EST(-0500)] <famicom> "upload" is disable
[13:48:52 EST(-0500)] <famicom> d
[13:49:18 EST(-0500)] <ecochran> yes, and it becomes enabled when there are files in the queue
[13:49:45 EST(-0500)] <anastasiac> but it does seem active because when you hover a mouse over it, it changes appearance, and the cursor changes
[13:50:06 EST(-0500)] <ecochran> hmm, what browser and platform
[13:50:09 EST(-0500)] <ecochran> that would be a bug
[13:50:12 EST(-0500)] <famicom> not to sound like a nielssen wannabe
[13:50:15 EST(-0500)] <anastasiac> FF3 on OX X
[13:50:23 EST(-0500)] <anastasiac> OS X (obviously)
[13:50:24 EST(-0500)] <jacobfarber> FF3 on xp too
[13:50:25 EST(-0500)] <ecochran> yes, subtle
[13:50:31 EST(-0500)] <ecochran> I'll fix it
[13:50:34 EST(-0500)] <famicom> but rather than using the standard OS controlls
[13:50:38 EST(-0500)] <famicom> you customized it
[13:51:05 EST(-0500)] <famicom> to a user that pretty much means that he's sailing uncharted waters, and he will expect default behavior
[13:51:22 EST(-0500)] <anastasiac> actually, that's kind of the whole point of Fluid components - customization
[13:51:30 EST(-0500)] <jacobfarber> feel free to replace anything/everything with what you feel is more appropriate
[13:51:48 EST(-0500)] <jacobfarber> the functional demos are there to provide multiple instances
[13:51:54 EST(-0500)] <ecochran> components are completely customizable... and easily though
[13:51:57 EST(-0500)] <jacobfarber> of different layouts, looks, etc
[13:53:23 EST(-0500)] <famicom> http://build.fluidproject.org/fluid/fluid-components/html/InlineEdit.html
[13:53:46 EST(-0500)] <famicom> outline the editable parts by default rather than onhover
[13:53:55 EST(-0500)] <jacobfarber> thats your choice
[13:54:05 EST(-0500)] <jacobfarber> if you want to do it, the hooks are there
[13:54:25 EST(-0500)] <Bosmon> Famicom, would you care to tell us a little about yourself?
[13:54:31 EST(-0500)] <Bosmon> it is always good to get to know our users
[13:54:36 EST(-0500)] <anastasiac> famicom, the styling of the components can be customized by the site implementor
[13:54:51 EST(-0500)] <anastasiac> this allows them to have a consistent look and feel across their site
[13:55:17 EST(-0500)] <famicom> anastasiac in that cause, wouldnt it be better than to just add a very very minimal styling
[13:55:45 EST(-0500)] <jacobfarber> yes, we do that too
[13:56:07 EST(-0500)] <anastasiac> the Infusion packing includes default styles
[13:57:01 EST(-0500)] <famicom> anyway, Bosmon about me
[13:57:30 EST(-0500)] <famicom> I've been a webdeveloper for 6 years or so
[13:57:42 EST(-0500)] <famicom> right now project manager
[14:02:16 EST(-0500)] <jessm_> famicom: are you using Fluid components in your project? Do you have a link, if so?
[14:02:33 EST(-0500)] <famicom> actually
[14:02:49 EST(-0500)] * Jake1 (n=Jacob@142.150.154.106) has joined #fluid-work
[14:02:51 EST(-0500)] <famicom> it was on the list of potentiak options
[14:04:10 EST(-0500)] <Jake1> famicom: do you have a web designer or someone who knows CSS with you?
[14:06:11 EST(-0500)] <famicom> myself mostly
[14:06:12 EST(-0500)] <famicom> why
[14:07:09 EST(-0500)] <Jake1> take a look at some of the css files that are on the page, and you can see how the states for buttons etc are available for your customization
[14:07:49 EST(-0500)] <famicom> yeah i know, all you gotta do is draw a border and set the background color
[14:08:03 EST(-0500)] <Jake1> we're also building up a library of bare-bones demos
[14:08:16 EST(-0500)] <Jake1> to help showcase how far customization can go
[14:09:08 EST(-0500)] <famicom> Jake1 === jacob farber?
[14:09:20 EST(-0500)] <Jake1> yes, irc glitch
[14:09:30 EST(-0500)] <Jake1> had to re-login
[14:10:04 EST(-0500)] <famicom> ah ok
[14:10:15 EST(-0500)] <famicom> did you ever write a book, or hold a seminar
[14:10:28 EST(-0500)] <Jake1> evidently, there are a lot of jacobs out there....and many variations too
[14:10:32 EST(-0500)] <famicom> or do you frequently write blog posts
[14:10:43 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has left #fluid-work
[14:10:46 EST(-0500)] <Jake1> no posts for me, least not yet
[14:13:06 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[14:17:08 EST(-0500)] * Jake1 (n=Jacob@142.150.154.106) has left #fluid-work
[14:20:30 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[14:23:22 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[14:24:00 EST(-0500)] * Jake1 (n=Jacob@142.150.154.106) has joined #fluid-work
[14:24:49 EST(-0500)] * fj400 (n=Jacob@142.150.154.106) has joined #fluid-work
[14:29:17 EST(-0500)] <jessm_> fj400: pick-a-nick
[14:29:40 EST(-0500)] <jessm_>
[14:30:22 EST(-0500)] <fj400> im trying! What can I say, i have a popular name on the intertubes
[14:34:07 EST(-0500)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[14:45:40 EST(-0500)] * phiggins_ (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[14:53:28 EST(-0500)] * ecochran (n=ecochran@dwin-wlan-17.AirBears.Berkeley.EDU) has joined #fluid-work
[14:53:33 EST(-0500)] <Bosmon> Interesting Resig post on unlimited "max" invocation:
[14:53:34 EST(-0500)] <Bosmon> http://ejohn.org/blog/fast-javascript-maxmin/
[15:06:32 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[15:11:33 EST(-0500)] <colinclark> ecochran: Got a sec?
[15:12:04 EST(-0500)] <ecochran> sure, I'm sitting in an online UX seminar
[15:12:10 EST(-0500)] <colinclark> Cool.
[15:12:13 EST(-0500)] <colinclark> I am eating lunch.
[15:12:26 EST(-0500)] <ecochran> quick and easy (and cheap) user testing
[15:12:27 EST(-0500)] <colinclark> So I just wanted to catch you up on where I'm at with Uploader/Flash 10 thinking.
[15:12:30 EST(-0500)] <ecochran> very good stuff
[15:12:32 EST(-0500)] <ecochran> yes
[15:12:33 EST(-0500)] <ecochran> shoot
[15:12:35 EST(-0500)] <colinclark> Cool. I like quick and easy testing.
[15:12:57 EST(-0500)] <colinclark> Ok, so I think it's most important that we take small steps with this change to SWFUpload.
[15:13:14 EST(-0500)] <ecochran> yes
[15:13:26 EST(-0500)] <colinclark> So my first step will be to integrated SWFUpload 2.2 in an unobtrusive way...
[15:13:45 EST(-0500)] <colinclark> Currently it expects to get the id of the button element, along with an absolute height and width in pixels.
[15:14:10 EST(-0500)] <colinclark> I'll modify this code to be more DOM Binder-friendly.
[15:14:49 EST(-0500)] <colinclark> We'll calculate the current height and width on the fly, and then set the flash button accordingly.
[15:15:14 EST(-0500)] <ecochran> makes sense.... these are all changes to swfupload.js?
[15:15:25 EST(-0500)] <colinclark> ecochran: Sort of, yes.
[15:15:55 EST(-0500)] <colinclark> I think we can make the changes from the "outside." SWFUpload's methods are public, so we can override them on the fly.
[15:16:00 EST(-0500)] <ecochran> colinclark: yeah, I'm worried how we track changes on a beta implementation
[15:16:08 EST(-0500)] <ecochran> great
[15:16:37 EST(-0500)] <colinclark> So then in IE, we'll ensure that the button is not transparent.
[15:17:01 EST(-0500)] <colinclark> That gets us as close to an "accessible" experience we'll get with this particular solution today.
[15:17:01 EST(-0500)] <ecochran> can we do that with out hacking the swf?
[15:17:04 EST(-0500)] <colinclark> Yep.
[15:17:09 EST(-0500)] <ecochran> awesome
[15:17:10 EST(-0500)] <colinclark> It's just a configuration option, thankfully.
[15:17:44 EST(-0500)] <colinclark> Next step, if all goes well, will be to write a little bit of ActionScript to listen for keyboard events and surrender keyboard focus in Firefox.
[15:17:53 EST(-0500)] <colinclark> We may or may not get to this in time for Infusion 0.6's release.
[15:18:24 EST(-0500)] <colinclark> Last up will be to finish the Gears manager and suggest it as the best option for a pure DHTML, accessible experience.
[15:18:25 EST(-0500)] <ecochran> do we want to go as far as putting up a message in our template that displays for FF users that the page is not keyboard accessible? or is that overkill
[15:18:52 EST(-0500)] <colinclark> ecochran: Good question. It might be enough to list it as a known issue.
[15:18:58 EST(-0500)] <ecochran> cool
[15:19:04 EST(-0500)] <colinclark> Given that the user won't be able to do much with this message.
[15:19:21 EST(-0500)] <colinclark> Alternatively, we could provide them with a button that would let them fall back to the single file upload.
[15:19:28 EST(-0500)] <colinclark> Might not be a bad idea.
[15:20:01 EST(-0500)] <ecochran> and fairly easy
[15:20:21 EST(-0500)] <colinclark> So you'll be able to keep squashing bugs as much as possible while I wrestle with SWFUpload 2.2?
[15:20:48 EST(-0500)] <colinclark> Justin_o probably has a good sense of priority on the current issues.
[15:20:51 EST(-0500)] <colinclark> As I'm sure you do as well.
[15:20:56 EST(-0500)] <ecochran> I don't see any reason why not... although you may break things as you go
[15:20:59 EST(-0500)] <ecochran> I think so
[15:21:20 EST(-0500)] <colinclark> ecochran: I'll do my best.
[15:21:34 EST(-0500)] <ecochran> to break things?
[15:21:37 EST(-0500)] <colinclark> ha!
[15:21:56 EST(-0500)] <colinclark> Justin_o is watching me like a hawk anyway.
[15:22:07 EST(-0500)] <ecochran> I trust you... which is to say... I don't think that we need a branch
[15:22:23 EST(-0500)] <colinclark>
[15:22:37 EST(-0500)] <ecochran> that and I think that the changes should be localized and sparse [15:22:45 EST(-0500)] <ecochran> good luck [15:22:57 EST(-0500)] <colinclark> thanks [15:23:06 EST(-0500)] <colinclark> fingers crossed [15:23:18 EST(-0500)] <ecochran> let me know if you see a place where you think that there may be conflict and I will keep you posted where I'm working and which bugs I'm squashing [15:23:31 EST(-0500)] <ecochran> I'm going to get better about using "Start Progress" [15:23:37 EST(-0500)] <colinclark> cool [15:23:43 EST(-0500)] <colinclark> ecochran: Sounds good. [15:23:54 EST(-0500)] <ecochran> colinclark: thxs for the heads up [15:24:26 EST(-0500)] <colinclark> I'll also send a mail to the list or maybe write a blog post to explain all the crazy forces at work with this update. [15:24:38 EST(-0500)] <ecochran> oy [15:24:41 EST(-0500)] <colinclark> And just how bad the accessibility situation is with this Flash update. [15:24:47 EST(-0500)] <ecochran> yes [15:25:36 EST(-0500)] <Justin_o> colinclark, ecochran: I'm going to be sending out the bug parade list tonight. Please let me know if there is anything else that needs to be added [15:25:51 EST(-0500)] <colinclark> Justin_o: sure [15:25:58 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work [15:25:58 EST(-0500)] <Justin_o> thanks [15:33:43 EST(-0500)] <ecochran> Justin_o: will do [15:33:58 EST(-0500)] <Justin_o> thanks [15:45:49 EST(-0500)] <colinclark> ecochran: Interesting Uploader-related request I just got. [15:46:11 EST(-0500)] <ecochran> colinclark: yeah? [15:46:13 EST(-0500)] <colinclark> Do you see any reason why a user couldn't disable or remove the "Add More" button? [15:46:26 EST(-0500)] <ecochran> no reason [15:46:33 EST(-0500)] <colinclark> In this case, our colleague Heidi wants to use the Uploader in a case where users only upload one file. [15:46:50 EST(-0500)] <colinclark> But it's a big file, so of course she wants a nice display of progress. [15:46:59 EST(-0500)] <colinclark> But she doesn't want to allow users to add more. [15:47:05 EST(-0500)] <ecochran> we've thought about designing a flavor of uploader where the ui was designed specifically for a single file [15:47:14 EST(-0500)] <colinclark> Would it just be a case of listening for afterUploadComplete and hiding the button? [15:47:22 EST(-0500)] <colinclark> ecochran: That would be neat. [15:48:34 EST(-0500)] <ecochran> I assume that they would also want to restrict the user to select a single file then once the file was loaded in the queue, you would either immediately upload or dim the browse button [15:48:53 EST(-0500)] <ecochran> I need to make sure that the "single" selection is still in our options [15:49:05 EST(-0500)] <ecochran> I assume that it is... but I haven't looked for it [15:49:26 EST(-0500)] <colinclark> ecochran: That makes sense. [15:49:37 EST(-0500)] <colinclark> The single option is still there, definitely. [15:49:58 EST(-0500)] <ecochran> cool [15:50:21 EST(-0500)] <colinclark> ecochran: Assuming Heidi ends up using it, can I hook you up with her here or IM to give her some moral support, at least. [15:50:38 EST(-0500)] <ecochran> absolutely [15:51:08 EST(-0500)] <ecochran> this is a great opportunity to figure out how integrators are thinking about our APIs [15:51:48 EST(-0500)] <ecochran> the whole adding your own listeners stuff is soo cool but a bit radical for the un-initiated [15:52:16 EST(-0500)] <colinclark> Is it really radical? I mean, people are pretty used to putting stuff in an options object. [15:52:32 EST(-0500)] <colinclark> All you do with us is to specify some functions in there to listen for events. [15:53:01 EST(-0500)] <ecochran> most JS developers don't know that you can use patterns like this... if they did we wouldn't need books like Crockfords [15:53:43 EST(-0500)] <ecochran> anyway, Heidi is at the ATRC? [15:53:47 EST(-0500)] <colinclark> Patterns like "options?" [15:53:55 EST(-0500)] <colinclark> Every toolkit I've ever used works this way. [15:54:01 EST(-0500)] <colinclark> jQuery UI, Dojo, everything. [15:54:51 EST(-0500)] <colinclark> I'm confused. [15:54:52 EST(-0500)] <ecochran> not options... attaching functions to options [15:55:05 EST(-0500)] <ecochran> pass functions around as first class objects [15:55:09 EST(-0500)] <ecochran> passing [15:55:59 EST(-0500)] <colinclark> are you sure? [15:56:03 EST(-0500)] <ecochran> my sense is that this stuff is still pretty foreign to the average JS programmer [15:56:44 EST(-0500)] <sgithens342f> I wonder if that's because we're surrounded by sakai and java programmers. I'm guessing it would be pretty natural to folks who pump out Django and Rails apps [15:56:58 EST(-0500)] <colinclark> You're telling me that this unusual? [15:56:59 EST(-0500)] <colinclark> http://fluid.pastebin.com/d126f73d2 [15:57:22 EST(-0500)] <ecochran> yep [15:57:58 EST(-0500)] <colinclark> So you're saying that average JS programmers don't know how to use things like jQuery UI, SWFUpload, etc? Widgets that ask you to specify a function that will be called later? [15:58:10 EST(-0500)] <ecochran> yep [15:58:12 EST(-0500)] <colinclark> That seems strange to me. Otherwise, why would these tools be so popular? [15:58:18 EST(-0500)] <colinclark> sgithens342f: Yeah, that's a really good point. [15:58:52 EST(-0500)] <ecochran> the average user of jQuery UI uses these libraries out of the box [15:59:13 EST(-0500)] <colinclark> meaning average users just don't ever bother with listening to events or callbacks? [15:59:21 EST(-0500)] <ecochran> and gets very nervous when they have to customize stuff [15:59:26 EST(-0500)] <ecochran> yep [15:59:47 EST(-0500)] <ecochran> I'm projecting here from the kinds of questions that I see on the forums [16:00:11 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has left #fluid-work [16:00:34 EST(-0500)] <colinclark> I guess it's a reminder of why we try to aim for really good defaults. [16:03:27 EST(-0500)] <colinclark> ecochran: You were about to say something? [16:03:28 EST(-0500)] <ecochran> I do think that there is a whole new generation of JS developers. [16:05:20 EST(-0500)] <colinclark> Tell me about them. [16:05:48 EST(-0500)] <sgithens342f> hmm, looks like it will become natural for php developers too: http://en.wikipedia.org/wiki/PHP#5.3_and_newer [16:07:06 EST(-0500)] <colinclark> sgithens342f: Cool. [16:07:19 EST(-0500)] <colinclark> In this case, we're not even talking about closures or first class functions or anything. [16:07:39 EST(-0500)] <colinclark> We're just talking about giving them a name and passing them along in an options object to the constructor of a widget. [16:07:53 EST(-0500)] <sgithens342f> right [16:08:01 EST(-0500)] <colinclark> So I guess maybe ecochran's point is that a lot of JavaScript users aren't even comfortable writing their own functions? [16:08:10 EST(-0500)] <sgithens342f> you definately can't do that in java though [16:08:22 EST(-0500)] <sgithens342f> but you can in most other webby languages [16:08:28 EST(-0500)] <colinclark> Right, yes. [16:09:59 EST(-0500)] <colinclark> Oh well, he disappeared. [16:10:08 EST(-0500)] <colinclark> I was curious if he had suggestions on how to make it easier. [16:10:43 EST(-0500)] <colinclark> Seems hard to write an API that hides away the idea of writing your own functions from a user. [16:10:50 EST(-0500)] <colinclark> But maybe I'm confused. [16:12:11 EST(-0500)] * ecochran (n=ecochran@dhcp-169-229-212-28.LIPS.Berkeley.EDU) has joined #fluid-work [16:13:36 EST(-0500)] <ecochran> sorry. I ran out of power... did I miss anything? [16:14:22 EST(-0500)] <colinclark> ecochran: Not much. [16:14:29 EST(-0500)] <colinclark> anastasiac called me an elitist. [16:14:35 EST(-0500)] <colinclark> Even though I am earnestly trying to understand. [16:14:44 EST(-0500)] <anastasiac> but I meant it in a nice way [16:14:48 EST(-0500)] <colinclark> Clearly she hates earnest-ness. [16:14:48 EST(-0500)] <colinclark> [16:14:51 EST(-0500)] <colinclark> And freedom. [16:14:54 EST(-0500)] <colinclark> And puppies and kittens. [16:14:55 EST(-0500)] <colinclark> [16:15:17 EST(-0500)] <ecochran> colinclark: you are definitely an "earnestist" [16:15:26 EST(-0500)] <colinclark> I was asking if you thought that it was a question of JavaScript users not being comfortable writing their own functions? [16:15:57 EST(-0500)] <colinclark> ecochran: ^ [16:16:10 EST(-0500)] <ecochran> I think that they are very comfortable writing functions in a very function foo(bar) pattern [16:16:45 EST(-0500)] <colinclark> But then referring to them by name or nesting them inside an object is unfamiliar? [16:16:59 EST(-0500)] <ecochran> yep [16:17:03 EST(-0500)] <colinclark> Hmm/ [16:17:19 EST(-0500)] <colinclark> So ultimately, do you think there is a way to make it easier? [16:17:19 EST(-0500)] <sgithens342f> I think more examples of this stuff in the sample-code area would clear things up for a lot of people [16:17:24 EST(-0500)] <colinclark> sgithens342f: Totally. [16:17:37 EST(-0500)] <ecochran> sgithens342f: yes [16:17:44 EST(-0500)] <sgithens342f> ( just a rehash of what I said yesterday, since there weren't any reorderer examples with events attached ) [16:17:54 EST(-0500)] <colinclark> I think at heart, the people Eli is taking about are cut-and-pasters. They'll grab an example, mess around with it until it works, and then they're done. [16:18:00 EST(-0500)] <colinclark> In that case, examples are huge. [16:18:07 EST(-0500)] <colinclark> sgithens342f: Yep, that's a good point. [16:18:12 EST(-0500)] <colinclark> Our examples need to do that. [16:18:51 EST(-0500)] * clown (n=clown@bas1-cooksville17-1279271796.dsl.bell.ca) has joined #fluid-work [16:18:55 EST(-0500)] <ecochran> I am still that way to a certain extent. I'm coming along but I still look at some of our latest code and go "Wow!" [16:19:32 EST(-0500)] <ecochran> I'm going to the source to go grab some wow-code [16:20:19 EST(-0500)] <ecochran> still launching aptana [16:21:41 EST(-0500)] <ecochran> so this: [16:21:42 EST(-0500)] <ecochran> listeners: { [16:21:42 EST(-0500)] <ecochran> afterFileQueued: that.addFile, [16:21:53 EST(-0500)] <ecochran> is baffling at first [16:21:56 EST(-0500)] <Bosmon> [16:22:11 EST(-0500)] <ecochran> what is addFile? is it a function? where are it's args? [16:22:18 EST(-0500)] <ecochran> what's going on? [16:23:11 EST(-0500)] <ecochran> it took me a while to figure it all out... [16:23:22 EST(-0500)] <colinclark> You have an object called "that" that you are passing along to listen to the afterFileQueued event. [16:23:22 EST(-0500)] <ecochran> when I did ... Wow! [16:23:32 EST(-0500)] * apetro (n=apetro@68.156.43.202) has joined #fluid-work [16:23:35 EST(-0500)] <Bosmon> BLIMEY! [16:23:36 EST(-0500)] <ecochran> exactly [16:23:39 EST(-0500)] <Bosmon> Closures for PHP [16:23:54 EST(-0500)] <Bosmon> And guess what, there will be closures in C++0x too [16:23:56 EST(-0500)] <ecochran> but it's not a pattern that I'm familiar with [16:24:50 EST(-0500)] <colinclark> So, then the question is still, what can we do to make it easier for users. [16:25:07 EST(-0500)] <ecochran> colinclark: I think that sgithens342f hit it, we're going to need to be pretty explicit with our documentation [16:25:10 EST(-0500)] <colinclark> Assuming they have trouble with the idea of a listener or a callback. [16:25:17 EST(-0500)] <colinclark> So sample code rules. [16:25:34 EST(-0500)] <ecochran> and I wonder if we want to be a little more explicit with our comments in the areas where we expect folks to customize [16:25:46 EST(-0500)] <colinclark> Comments where? [16:26:02 EST(-0500)] <ecochran> along the lines of (and I hate it) // change this value here in this way to acheive x [16:26:10 EST(-0500)] <colinclark> But where would that go? [16:26:16 EST(-0500)] <ecochran> not sure [16:26:19 EST(-0500)] <anastasiac> ecochran, I invite you to try your hand at creating a nice illustrative example. [16:26:20 EST(-0500)] <colinclark> It seems like it would be best in the API documentation... [16:26:33 EST(-0500)] <colinclark> I mean, you don't go poking around in jQuery's code very often to learn how to do something. [16:26:42 EST(-0500)] <ecochran> no, that's for sure [16:26:44 EST(-0500)] <anastasiac> it's a good exercise in learning, as well as in finding flaws with our api [16:26:46 EST(-0500)] <Bosmon> I do [16:26:49 EST(-0500)] <colinclark> You go to docs.jquery.com and you read the page. [16:26:49 EST(-0500)] <Bosmon> [16:27:00 EST(-0500)] <colinclark> Bosmon: Well, yes. [16:27:09 EST(-0500)] <ecochran> Bosmon: yes, we know you do and we're thankful for it [16:27:11 EST(-0500)] <colinclark> So it seems to me that there are two things here: [16:27:28 EST(-0500)] <colinclark> 1. More sample code that covers the range of stuff you'd commonly do with a component. [16:27:34 EST(-0500)] <colinclark> Most notably registering your own handlers. [16:27:35 EST(-0500)] <Bosmon> Actually I think jQuery's codebase is a good deal more opaque than ours [16:27:42 EST(-0500)] <Bosmon> But I guess that is just personal opinion [16:27:43 EST(-0500)] <colinclark> Bosmon: Far more so, yes. [16:27:49 EST(-0500)] <ecochran> yes [16:27:59 EST(-0500)] <colinclark> 2. Better API docs that include comments about how/when you'd customize. [16:28:16 EST(-0500)] <Bosmon> One important aspect I believe of "that-ism" is that it simply makes code easier to read [16:28:21 EST(-0500)] <Bosmon> At least, once you understand what it is [16:28:28 EST(-0500)] <ecochran> I'm finding it so [16:28:29 EST(-0500)] <colinclark> [16:28:42 EST(-0500)] <Bosmon> You know exactly where to look, to find what a particular variable may refer to [16:28:49 EST(-0500)] <ecochran> although we're also break stuff up really well and that's going along way too [16:29:00 EST(-0500)] <colinclark> Again, the point that ecochran raises is that we're talking about a user group who would never look at our own code or understand it. They'd just want to grab an example and hack away a bit. [16:29:04 EST(-0500)] <Bosmon> Yes [16:29:06 EST(-0500)] <colinclark> So good examples really are huge. [16:29:10 EST(-0500)] <colinclark> But now I am sounding repetitive. [16:29:20 EST(-0500)] <Bosmon> I am already amazed at how many good examples we do have [16:29:27 EST(-0500)] <anastasiac> so what examples do we want? [16:29:33 EST(-0500)] <anastasiac> A) binding listeners [16:29:44 EST(-0500)] <Bosmon> I mean, famicom fished out our InlineEdit sample, and pooh-poohed the fact that the CSS styles weren't exactly the way he wanted [16:29:45 EST(-0500)] <anastasiac> B) customizing styles [16:29:46 EST(-0500)] <colinclark> anastasiac: I think a good first step is making sure our Functional Examples (aka Springboards) show how to listen for events. [16:29:50 EST(-0500)] <Bosmon> But actually I think that InlineEdit page is excellent [16:29:56 EST(-0500)] * jessm_ is hearing a theme from the last two days: mo' better documentation + keep puppies and kittens away from anastasiac [16:29:58 EST(-0500)] <colinclark> Yes [16:29:58 EST(-0500)] <anastasiac> oh: that should have been a B [16:30:00 EST(-0500)] <colinclark> Customizing styles. [16:30:07 EST(-0500)] <colinclark> B [16:30:09 EST(-0500)] <colinclark> B: [16:30:11 EST(-0500)] <colinclark> :B [16:30:12 EST(-0500)] <ecochran> they are not always all the same place... I find myself looking at samplecode, manual test and even automated tests sometimes to really grok all the options [16:30:29 EST(-0500)] <anastasiac> I welcome suggestions for restructuring the docs! [16:30:29 EST(-0500)] <ecochran> colinclark: what are you trying to type? [16:30:30 EST(-0500)] <anastasiac> please! [16:30:36 EST(-0500)] <Bosmon> Yes, especially for the renderer, some things are only currently presented in test cases [16:30:41 EST(-0500)] <colinclark> anastasiac has been working on some pages that have a sort of table describing all the options you can set. [16:30:53 EST(-0500)] <colinclark> ecochran: I have no idea. I was just copying anastasiac. [16:30:53 EST(-0500)] <ecochran> that's great! [16:30:57 EST(-0500)] <Bosmon> But it is hard for anyone to keep fully abreast of the "wavefront" [16:30:58 EST(-0500)] <jessm_> anastasiac: methinks you won't be alone much longer on this [16:31:07 EST(-0500)] <colinclark> jessm_: [16:31:16 EST(-0500)] <anastasiac> jessm_: that would be lovely [16:31:18 EST(-0500)] <colinclark> We are still very young. [16:31:23 EST(-0500)] * jessm_ passes out PFDs [16:31:24 EST(-0500)] <anastasiac> speak for yourself [16:31:31 EST(-0500)] <Bosmon> We must all bear in mind that we are trying the equivalent of trying to live in a building before the roof is on [16:31:31 EST(-0500)] <jessm_> ! [16:31:39 EST(-0500)] <colinclark> Well, when I say "we," I mean our code. [16:31:47 EST(-0500)] <colinclark> Infusion is sort of a raw, restless youth. [16:31:53 EST(-0500)] * anastasiac [16:31:55 EST(-0500)] <colinclark> Documentation is part of growing up. [16:32:01 EST(-0500)] <ecochran> anastasiac: I'd like to jump in on those examples after I get some bugs fixed [16:32:10 EST(-0500)] <Bosmon> Before 0.5 we didn't even have a solid basic framework API [16:32:11 EST(-0500)] <anastasiac> ecochran: excellent! [16:32:15 EST(-0500)] * jessm_ puts braces on the teeth of our code and passes out more PFDs [16:32:17 EST(-0500)] <colinclark> ecochran: We are going to have a big doco push as soon as the King freezes. [16:32:26 EST(-0500)] <Bosmon> Which day will the King freeze? [16:32:39 EST(-0500)] * Topic is 'Braces and PFDs' set by anastasiac on 2008-12-04 16:32:39 EST(-0500) [16:32:40 EST(-0500)] <jessm_> 15 [16:32:45 EST(-0500)] <colinclark> Dec. 15th, yes [16:32:49 EST(-0500)] <ecochran> colinclark: I'd also like to revive the uploader sample code if we have time to show how to do stuff like single uploaders and dialog uploaders [16:32:51 EST(-0500)] <colinclark> Monday a week from next. [16:33:01 EST(-0500)] <colinclark> ecochran: That will be awesome. [16:33:08 EST(-0500)] <ecochran> but not this release [16:33:16 EST(-0500)] <colinclark> We still have more work to do to break up the markup assumptions in Uploader before a lot of that will be possible. [16:33:20 EST(-0500)] <colinclark> But we're making amazing progress. [16:34:05 EST(-0500)] <colinclark> So after freeze, a couple of interesting things could be done: [16:34:12 EST(-0500)] <ecochran> except that we keep having really really interesting conversations and I lose track of my code ;-p [16:34:14 EST(-0500)] <colinclark> We should write some nice examples and tutorials. [16:34:31 EST(-0500)] <colinclark> And AC and I will start on a big picture walk-through: "Why Fluid?" [16:34:46 EST(-0500)] <colinclark> I think we've drifted out of sync with our API docs. [16:34:51 EST(-0500)] <ecochran> brb [16:34:57 EST(-0500)] <colinclark> So a good thorough "is this up to date" check will be helpful. [16:35:43 EST(-0500)] <Bosmon> Shall we talk about Pager a bit? [16:36:19 EST(-0500)] <ecochran> back [16:37:49 EST(-0500)] <colinclark> ecochran: Cool. [16:37:55 EST(-0500)] <colinclark> Well, help us post-freeze with documentation. [16:37:56 EST(-0500)] <ecochran> Bosmon: who do you need or want? [16:38:03 EST(-0500)] <colinclark> And as for being distracted from code, I agree. [16:38:10 EST(-0500)] <colinclark> Bosmon: You talking to me?!? [16:38:12 EST(-0500)] <colinclark> [16:38:13 EST(-0500)] <Bosmon> I dunno, people [16:38:22 EST(-0500)] <colinclark> there are a few people here [16:38:26 EST(-0500)] <Bosmon> People who are interested in what has happened to Pager, or will happen to it [16:38:26 EST(-0500)] <colinclark> anastasiac is one of them [16:38:32 EST(-0500)] <ecochran> pager peop,e [16:38:33 EST(-0500)] <colinclark> I am not of the people, however. [16:38:36 EST(-0500)] <colinclark> [16:38:38 EST(-0500)] <Bosmon> Yeah [16:38:44 EST(-0500)] <Bosmon> You are a filthy elitist [16:38:45 EST(-0500)] <colinclark> Or so anastasiac says. [16:38:55 EST(-0500)] <Bosmon> Watch him oppressing me with his elitism! [16:38:59 EST(-0500)] <colinclark> A theoretician of sorts, yes. [16:39:04 EST(-0500)] <Bosmon> It is elitism of a positively Rhizomic nature [16:39:19 EST(-0500)] <colinclark> Well, I'd be happy to talk Pager. [16:39:29 EST(-0500)] <colinclark> ecochran, you could tune us out if you want to squash Uploader bugs. [16:39:32 EST(-0500)] <colinclark> But only if you want. [16:39:34 EST(-0500)] <Bosmon> Can you kick a Fish? [16:39:39 EST(-0500)] <ecochran> I'm going to [16:39:44 EST(-0500)] <ecochran> tune out that it [16:39:45 EST(-0500)] <ecochran> is [16:39:50 EST(-0500)] <colinclark> I am reticent to kick the Fish at the moment... [16:40:00 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work [16:40:01 EST(-0500)] <colinclark> She appears to be immensely productive with Mr. FJ 400. [16:40:12 EST(-0500)] <jessm_> lol [16:40:15 EST(-0500)] <jessm_> what a crazy bunch [16:40:21 EST(-0500)] <colinclark> They just showed us a demo of UI Options and the skin running against Sakai 3.0 markup. [16:40:26 EST(-0500)] <Bosmon> Ah, cool [16:40:26 EST(-0500)] <colinclark> It is quite fantastic. [16:40:29 EST(-0500)] <anastasiac> it was awesome! [16:40:39 EST(-0500)] <colinclark> Refreshing compared to our "worst case examples." [16:40:41 EST(-0500)] <ecochran> who is fj400? [16:40:47 EST(-0500)] <colinclark> ecochran: Good question! [16:40:51 EST(-0500)] <jessm_> ecochran: jacob [16:40:55 EST(-0500)] <colinclark> I think he should be fj 4000 [16:40:58 EST(-0500)] <colinclark> that would be even cooler [16:41:01 EST(-0500)] <Bosmon> ? [16:41:37 EST(-0500)] <ecochran> fj400: you sly dog! hiding behind a pseudonym [16:41:42 EST(-0500)] * fj4000 (n=Jacob@142.150.154.106) has joined #fluid-work [16:41:52 EST(-0500)] <colinclark> fj4000 has been upgraded! [16:42:18 EST(-0500)] <colinclark> Bosmon: Do you want to wait for the Fish, or do you want to go for it. [16:42:27 EST(-0500)] <Bosmon> I guess we should wait for the Fish [16:42:45 EST(-0500)] <colinclark> I see some competition happening here. [16:42:57 EST(-0500)] <fj4000> i am liquid metal [16:43:07 EST(-0500)] <fj4000> mimetic poly allow [16:43:09 EST(-0500)] <fj6000> I am one-piece aluminum [16:43:12 EST(-0500)] <Bosmon> You are a loony [16:43:13 EST(-0500)] <fj6000> with a glass screen [16:43:13 EST(-0500)] <fj4000> with a cool police uniform [16:43:29 EST(-0500)] <fj4000> anyone seen terminator??? ANYONE???? [16:43:33 EST(-0500)] <fj4000> oh man [16:43:37 EST(-0500)] <fj4000> I am alone in the future [16:43:38 EST(-0500)] <ecochran> me me [16:43:40 EST(-0500)] <fj4000> so.....cold [16:43:41 EST(-0500)] <anastasiac> obviously not as often as you have [16:43:49 EST(-0500)] * fj6000 is nearly on the floor. [16:43:54 EST(-0500)] <fj4000> hey! [16:44:03 EST(-0500)] <fj4000> no more making fun of my name! [16:44:09 EST(-0500)] <Bosmon> You are a one-piece aluminium loony [16:44:11 EST(-0500)] <fj5000> fj* is a crazy bot [16:44:21 EST(-0500)] <fj4000> thats it.... [16:44:24 EST(-0500)] <Bosmon> I'm not sure if that is any better than being a multi-piece loony [16:44:30 EST(-0500)] <colinclark> ha [16:44:41 EST(-0500)] <colinclark> Bosmon: My time share cat is convinced that it is better. [16:44:48 EST(-0500)] <fj4000> the loonie is still worth less than the metal its made of [16:44:53 EST(-0500)] <Bosmon> hah [16:44:59 EST(-0500)] <Bosmon> Anyway, colinclark [16:45:02 EST(-0500)] <colinclark> i prefer Atlantean Tokens [16:45:07 EST(-0500)] <colinclark> they are worth nearly three loonies [16:45:09 EST(-0500)] <Bosmon> I found a way around this "early declaration annoyance" [16:45:12 EST(-0500)] <colinclark> ok [16:45:16 EST(-0500)] <Bosmon> You may or may not enjoy it [16:45:23 EST(-0500)] <Bosmon> fluid.pager = function() { [16:45:23 EST(-0500)] <Bosmon> fluid.pagerImpl.apply(null, arguments); [16:45:23 EST(-0500)] <Bosmon> } [16:45:24 EST(-0500)] <colinclark> I love it when you start off like that. [16:45:24 EST(-0500)] <colinclark> [16:45:53 EST(-0500)] <colinclark> I hate it already [16:45:55 EST(-0500)] <colinclark> where is pagerImpl defined? [16:45:56 EST(-0500)] <Bosmon> [16:46:01 EST(-0500)] <Bosmon> LATER ON IN THE FILE! [16:46:42 EST(-0500)] <colinclark> What is the correct term for this... ? [16:46:44 EST(-0500)] <colinclark> glarg? [16:46:46 EST(-0500)] <colinclark> something like that. [16:46:59 EST(-0500)] <Bosmon> Well? [16:47:06 EST(-0500)] <colinclark> glarg [16:47:19 EST(-0500)] <Bosmon> Are you going to make me insist that this solution is "uniquely correct"? [16:47:41 EST(-0500)] <colinclark> This is really all just to work around that fact that you don't want to have to declare your "static" functions after your creator function? [16:47:45 EST(-0500)] <Bosmon> Yes [16:47:57 EST(-0500)] <colinclark> I really don't think it's worth it. [16:48:01 EST(-0500)] <colinclark> It reads terribly. [16:48:18 EST(-0500)] <Bosmon> Well, what would you suggest [16:48:26 EST(-0500)] <Bosmon> Writing the creator function at the top of the file>? [16:48:30 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work [16:49:06 EST(-0500)] <colinclark> Well, I assume you're not going to have an insanely huge number of these functions that are like this. [16:49:18 EST(-0500)] <Bosmon> Well, typically just one per file [16:49:25 EST(-0500)] <Bosmon> "fluid.pager" seems like a very top-level concept [16:49:33 EST(-0500)] <colinclark> yes, yes [16:49:45 EST(-0500)] <colinclark> sorry, when I say these functions, I don't mean creator functions. [16:49:51 EST(-0500)] <colinclark> I mean things you want to hang off the creator function. [16:49:51 EST(-0500)] <Bosmon> Oh, the things inside it? [16:49:53 EST(-0500)] <Bosmon> I already have 6 [16:49:59 EST(-0500)] <colinclark> 6... [16:50:06 EST(-0500)] <Bosmon> And I imagine a positively unbounded collection of further ones [16:50:12 EST(-0500)] <colinclark> these are the subcomponent creator functions? [16:50:19 EST(-0500)] <colinclark> Or what do they do? [16:50:22 EST(-0500)] <Bosmon> Yes, and various alternative implementations of them [16:50:30 EST(-0500)] * colinclark goes to the code. [16:50:37 EST(-0500)] <Bosmon> Not all of this is checked in yet [16:50:42 EST(-0500)] <Bosmon> I think there are only 3 in SVN right now [16:50:53 EST(-0500)] <Bosmon> I mean, 3 sub-components [16:51:09 EST(-0500)] <colinclark> Right. [16:51:16 EST(-0500)] <Bosmon> And as they are in SVN, they all have sort of "ad hoc" names, since we can't do this namespacing trick [16:51:25 EST(-0500)] <Bosmon> They are not obviously associated with the top-level idea of the "pager" [16:51:30 EST(-0500)] <colinclark> So your point is that you want to be able to define subcomponents such as PagerBar within the "pager" namespace? [16:51:33 EST(-0500)] <Bosmon> Yes [16:51:44 EST(-0500)] <colinclark> This has struck me in the past as well... [16:51:47 EST(-0500)] <Bosmon> And we don't want to lose our prime "real estate" of the name fluid.pager [16:51:54 EST(-0500)] <colinclark> Something like a "FileQueueView" is hardly a top-level concept. [16:51:58 EST(-0500)] <Bosmon> Since it is naturally what the users will want to call, to instantiate something [16:52:04 EST(-0500)] <colinclark> It is only meaningful as part of an uploader namespace. [16:52:08 EST(-0500)] <Bosmon> Yes [16:52:27 EST(-0500)] <Bosmon> I realised that the crisis had reached fever pitch when I started to write something called fluid.selfRender [16:52:33 EST(-0500)] <Bosmon> And realised not only that we had one already [16:52:41 EST(-0500)] <Bosmon> But that what I really wanted to call it was fluid.pager.selfRender [16:52:51 EST(-0500)] <Bosmon> Or perhaps something even longer [16:52:54 EST(-0500)] <Bosmon> fluid.pager.body.selfRender [16:53:35 EST(-0500)] <colinclark> So at heart, though, it's an issue of the top-level creator function-the one serving as a namespace-floating to the top of the file eventually? [16:53:42 EST(-0500)] <Bosmon> Yes [16:54:16 EST(-0500)] <colinclark> Can you pastebin me the code as it looks in your local copy? [16:54:23 EST(-0500)] <Bosmon> Well, all of it? [16:54:31 EST(-0500)] <colinclark> Sure, why not? [16:54:40 EST(-0500)] <Bosmon> ok [16:54:47 EST(-0500)] <colinclark> Just so I can see the whole picture,. [16:55:03 EST(-0500)] <colinclark> I mean, it's convenient to know that you can go down to near the bottom of the file and find the creator function... [16:55:13 EST(-0500)] <Bosmon> Yes [16:55:21 EST(-0500)] <colinclark> but is it that important to us? Most of us do have a workable Outline view available to us. [16:55:25 EST(-0500)] <Bosmon> And aren't there a couple of issues that might be more important than convenience? [16:55:42 EST(-0500)] <Bosmon> Didn't you once talk about a couple of possible "define before use" wrinkles in some impls? [16:55:56 EST(-0500)] <Bosmon> http://pastebin.com/mf5ce370 [16:57:12 EST(-0500)] <Bosmon> I think it is important that a file has a "natural ordering" [16:57:28 EST(-0500)] <Bosmon> Whereby you can expect not to find any "direct calls" of functions that are declared later [16:57:41 EST(-0500)] <Bosmon> This is one important route to head off dependency tangles [16:58:10 EST(-0500)] <Bosmon> My suggestion of last night was to insist that anything that went "against the flow" was to use the event system [16:58:15 EST(-0500)] <Bosmon> But we didn't get to talk about that yet [16:59:30 EST(-0500)] <colinclark> i am just catchin up [16:59:34 EST(-0500)] <colinclark> catchin' [16:59:34 EST(-0500)] * apetro (n=apetro@68.156.43.202) has joined #fluid-work [17:00:35 EST(-0500)] <colinclark> I can't believe you used the variable names "pagerBar" and "pagerBarDuplicate"! [17:00:40 EST(-0500)] <Bosmon> OK [17:00:45 EST(-0500)] <colinclark> I mean, I guess you were trying to avoid specific spatial references. [17:00:46 EST(-0500)] <colinclark> [17:00:47 EST(-0500)] <Bosmon> The name of the 2nd one is up for grabs [17:00:48 EST(-0500)] <Bosmon> Yes, I was [17:00:50 EST(-0500)] <Bosmon> [17:00:56 EST(-0500)] <colinclark> That is just a bit funny. [17:01:01 EST(-0500)] <colinclark> Not a big deal. [17:01:02 EST(-0500)] <Bosmon> But it should be clear that one of these instances is "functionally optional" [17:01:05 EST(-0500)] <Bosmon> And one is not [17:01:10 EST(-0500)] <colinclark> anastasiac: Any suggestions? [17:01:22 EST(-0500)] <Bosmon> I mean, what if someone wants to leave out the bottom one, and another person wants to leave out the top one? [17:01:30 EST(-0500)] <colinclark> Bosmon: Yep, for sure. [17:01:48 EST(-0500)] <colinclark> This question of "optional" subcomponents is on that has been on my mind a lot. [17:01:50 EST(-0500)] * anastasiac mulls [17:02:01 EST(-0500)] <colinclark> And also peripherally relates to another thing. [17:02:12 EST(-0500)] <anastasiac> "pagerBar" and "otherPagerBar" [17:02:16 EST(-0500)] <Bosmon> !!!!! [17:02:19 EST(-0500)] <Bosmon> OTHER CATT?! [17:02:29 EST(-0500)] <colinclark> yes [17:02:35 EST(-0500)] <colinclark> OTHER cat [17:02:48 EST(-0500)] <colinclark> so i was saying [17:02:50 EST(-0500)] <colinclark> optional subcomponents [17:02:57 EST(-0500)] <colinclark> and then optional binding [17:03:00 EST(-0500)] <colinclark> here's an example [17:03:06 EST(-0500)] <Bosmon> I am eager [17:03:08 EST(-0500)] <colinclark> if our component binds an event handler to a button [17:03:12 EST(-0500)] <Bosmon> "For your example" [17:03:16 EST(-0500)] <colinclark> but the end-user doesn't actually want the button [17:03:24 EST(-0500)] <colinclark> and they just leave it out of the markup [17:03:27 EST(-0500)] <colinclark> we do something horrible [17:03:30 EST(-0500)] <colinclark> inherited from jQuery [17:03:35 EST(-0500)] <Bosmon> Oh dear [17:03:38 EST(-0500)] <colinclark> we end up binding that handler to the whole document [17:03:38 EST(-0500)] <colinclark> [17:03:43 EST(-0500)] * michelled (n=team@142.150.154.197) has left #fluid-work [17:03:44 EST(-0500)] <colinclark> It is really terrible. [17:03:45 EST(-0500)] <Bosmon> YOu don't mean to say, we bind something to the document [17:03:45 EST(-0500)] <Bosmon> yes [17:03:48 EST(-0500)] <colinclark> [17:03:51 EST(-0500)] <colinclark> We'll have to fix it. [17:03:59 EST(-0500)] <Bosmon> Well [17:04:00 EST(-0500)] <anastasiac> indeed [17:04:03 EST(-0500)] <Bosmon> Doesn't the DOM binder already fix it? [17:04:05 EST(-0500)] <colinclark> But I wondered about a sort of "bindIfPresent" [17:04:10 EST(-0500)] <colinclark> Bosmon: Not last I looked, no. [17:04:26 EST(-0500)] <colinclark> Or at least ensuring that we return an empty jQuery [17:04:33 EST(-0500)] <colinclark> not one wrapping the document [17:04:40 EST(-0500)] <colinclark> So then the other thing is an optional subcomponent. [17:04:55 EST(-0500)] <colinclark> Say, what if I don't want progress bars for each file in the upload queue. Just one for the whole thing. [17:04:58 EST(-0500)] <Bosmon> I see [17:05:00 EST(-0500)] <Bosmon> How awful [17:05:03 EST(-0500)] <colinclark> At this point, there's nothing you can do. [17:05:16 EST(-0500)] <Bosmon> I'm just looking at the code [17:05:29 EST(-0500)] <colinclark> Again, it feels funny to have a sort of "stubby implmentation" of a subcomponent if it's not wanted [17:05:31 EST(-0500)] <Bosmon> Of course, we fixed it in fluid.container [17:05:40 EST(-0500)] <Bosmon> But we didn't fix it in our general searching for things [17:05:45 EST(-0500)] <colinclark> but we also don't want to have a whole set of checks "if this subcomponent is wanted, then do this." [17:05:48 EST(-0500)] <colinclark> If you know what I'm saying. [17:05:51 EST(-0500)] <Bosmon> Yes [17:05:59 EST(-0500)] <Bosmon> Well [17:06:22 EST(-0500)] <colinclark> Both are required to finally fully deliver on DOM agnosticism [17:06:37 EST(-0500)] <Bosmon> We can hack initSubcomponent(s) and dom.locate [17:06:38 EST(-0500)] <colinclark> Since we figure users should be allowed to leave certain things out. [17:06:48 EST(-0500)] <Bosmon> So that they are both capable of returning nothing, if required [17:06:52 EST(-0500)] <colinclark> Bosmon: Yes, definitely dom.locate make sense [17:07:02 EST(-0500)] <colinclark> but what about calls to the result of initSubcomponent()? [17:07:06 EST(-0500)] <Bosmon> initSubcomponents I think can already return an empty list [17:07:15 EST(-0500)] <colinclark> I mean, otherwise we're doing a lot of this: [17:07:18 EST(-0500)] <Bosmon> But initSubcomponent will surely blow up [17:07:30 EST(-0500)]