fluid-work IRC Logs-2008-12-04

[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)]

[17:07:31 EST(-0500)] <colinclark> which is uglyt
[17:07:45 EST(-0500)] <Bosmon> Should we just not insist that if there is something that does not have a cardinality of exactly 1, that the user use a list?
[17:07:48 EST(-0500)] <colinclark> initSubcomponent will undoubtedly blow up now.
[17:08:16 EST(-0500)] <colinclark> Bosmon: But I don't think that really covers the case I'm talking about.
[17:08:24 EST(-0500)] <Bosmon> Well yes
[17:08:38 EST(-0500)] <Bosmon> If your case really comprises not wanting to disturb the implementor's code at all
[17:08:49 EST(-0500)] <Bosmon> This requires as you say, supplying a default "nully" implementation of something
[17:09:00 EST(-0500)] <Bosmon> We could create a nice factory function for generating these
[17:09:02 EST(-0500)] <colinclark> That wouldn't be terribly difficult.
[17:09:07 EST(-0500)] <colinclark> You don't think it's a bit awkward?
[17:09:12 EST(-0500)] <Bosmon> That might also serve as useful documentation of what the contract of something actually is
[17:09:44 EST(-0500)] <Bosmon> fluid.createNullaryImpl("doSomething", "doSomethingElse", "otherCATT");
[17:10:02 EST(-0500)] <colinclark> I would have called it fluid.createStubbySubcomponent()
[17:10:02 EST(-0500)] <colinclark>
[17:10:13 EST(-0500)] <Bosmon> StubbyPaws
[17:10:40 EST(-0500)] <colinclark> I guess it's a bit like our framework providing specific support for mocks.
[17:10:50 EST(-0500)] <Bosmon> yes
[17:10:57 EST(-0500)] <colinclark> Well, a feature for 0.8.
[17:11:17 EST(-0500)] <colinclark> I am glad we've talked about it. It has been bugging me ever since Jacob asked for it while building the Uploader springboard.
[17:11:19 EST(-0500)] <Bosmon> Yes
[17:11:28 EST(-0500)] <Bosmon> So, to get back to "pagerImpl"
[17:11:31 EST(-0500)] <colinclark> yes
[17:12:58 EST(-0500)] <colinclark> I really find this immensely awkward.
[17:13:06 EST(-0500)] <colinclark> I see exactly what you're doing, and why.
[17:13:21 EST(-0500)] <colinclark> And yes, I have pushed on the "theoretical" risks of use before definition.
[17:13:50 EST(-0500)] <colinclark> I just don't feel like it's worth it. As I say, we do all have decent outline views in our IDEs.
[17:14:56 EST(-0500)] <colinclark> I mean, it's not the end of the world either way. But it is a bit more mental parsing to do before understanding the structure in front of you.
[17:15:02 EST(-0500)] <Bosmon>
[17:15:39 EST(-0500)] <colinclark> I wonder if we miscalculated our namespacing strategy and should have ensured that components had a specific namespace object and an "init" function or something.
[17:15:50 EST(-0500)] <Bosmon> Well, maybe
[17:15:58 EST(-0500)] <Bosmon> But that would seem to imply more mental work for our users
[17:16:00 EST(-0500)] <colinclark> Still, that would have been rather.dot.prone.if.you.know.what.i.mean
[17:16:10 EST(-0500)] <colinclark> Bosmon: Yep.
[17:16:15 EST(-0500)] <Bosmon> Surely they really want to just invoke a function called fluid.pager
[17:17:11 EST(-0500)] <colinclark> Yes, definitely.
[17:17:21 EST(-0500)] <Bosmon> fluid.pager.init or fluid.pager.construct just looks crappy
[17:17:28 EST(-0500)] <colinclark> I agree.
[17:17:31 EST(-0500)] <Bosmon> And would just lead to further confusion with the other things we put inside fluid.pager
[17:17:42 EST(-0500)] <colinclark> For sure.
[17:17:47 EST(-0500)] <Bosmon> For example, what would the relation be between fluid.pager.directPageList and fluid.pager.construct?
[17:18:01 EST(-0500)] <colinclark> Yep. I take back that wondering. We are good.
[17:18:03 EST(-0500)] <colinclark>
[17:18:10 EST(-0500)] <Bosmon>
[17:18:44 EST(-0500)] * anastasiac has to go paint hallways
[17:18:51 EST(-0500)] <anastasiac> good night, gentlemen!
[17:18:55 EST(-0500)] <Bosmon> Of course, the stub implementation itself is a violation of the "no forward call" policy
[17:18:56 EST(-0500)] <colinclark> See you, anastasiac.
[17:19:00 EST(-0500)] <Bosmon> Good night
[17:19:14 EST(-0500)] <Bosmon> But, at least, it is a small one, all in one place
[17:19:18 EST(-0500)] <colinclark> Since you've defined pagerImpl later in the file.
[17:19:23 EST(-0500)] <Bosmon> Yes
[17:19:52 EST(-0500)] <Bosmon> I don't know, the alternative would seem to be to create yet another framework utility to do this for us
[17:20:02 EST(-0500)] <colinclark> what would it look like?
[17:20:36 EST(-0500)] <Bosmon> fluid.makeComponent(fluid.pager, function( blargs blargs) { });
[17:20:49 EST(-0500)] <colinclark> ha!
[17:20:51 EST(-0500)] <Bosmon> well, it would actually look like this, which is not so happy
[17:21:03 EST(-0500)] <Bosmon> fluid.pager = fluid.makeComponent(fluid.pager, function( blargs blargs) {});
[17:21:16 EST(-0500)] <colinclark> yeah
[17:21:38 EST(-0500)] <Bosmon> The second argument would become the return value
[17:21:46 EST(-0500)] <colinclark> At some point in the pre-thatism days, I had thought of doing something along these lines.
[17:21:46 EST(-0500)] <Bosmon> With all the members of the first argument assigned to it
[17:21:48 EST(-0500)] <colinclark> It is dorky.
[17:21:53 EST(-0500)] <Bosmon> Yes
[17:21:57 EST(-0500)] <Bosmon> It is dorky
[17:22:12 EST(-0500)] <Bosmon> It is also potentially dangerous
[17:22:19 EST(-0500)] <Bosmon> Although not, if everyone remains a strict that-ist
[17:22:46 EST(-0500)] <Bosmon> Well
[17:22:53 EST(-0500)] <Bosmon> I guess there is no "real" danger
[17:23:02 EST(-0500)] <Bosmon> Given what we do already do ensure our namespacing policy works
[17:23:27 EST(-0500)] <Bosmon> Noone will bake assumptions that fluid.x and fluid.x.y written at various different points will refer to objects that have a particular inclusion relationship that remains stable
[17:23:33 EST(-0500)] <colinclark> So then why did you choose to put your stubby fluid.pager() implementation as the third function from the top?
[17:23:37 EST(-0500)] <colinclark> Just random luck?
[17:23:52 EST(-0500)] <Bosmon> It had to go before any use of fluid.pager
[17:23:56 EST(-0500)] <Bosmon> And that is the last possible point
[17:24:23 EST(-0500)] <Bosmon> I guess its position there is slightly unfortunate
[17:24:41 EST(-0500)] <Bosmon> You're right that it should really be first
[17:24:48 EST(-0500)] <colinclark> No reason it couldn't be first.
[17:24:57 EST(-0500)] <colinclark> And, I suspect, in nearly every case it could be.
[17:25:05 EST(-0500)] <Bosmon> Well, yes
[17:25:14 EST(-0500)] <Bosmon> Unless there were more than one "top-level entity" within a file
[17:25:18 EST(-0500)] <colinclark> yes
[17:25:26 EST(-0500)] <colinclark> Which is probably inadvisable.
[17:25:43 EST(-0500)] <Bosmon> Anyway, do you feel better or worse about fluid.makeComponent, than about fluid.pagerImpl.apply() ?
[17:26:02 EST(-0500)] <colinclark> I feel worse about makeComponent.
[17:26:10 EST(-0500)] <colinclark> Do you have a preference?
[17:26:22 EST(-0500)] <Bosmon> I guess I also feel worse about makeComponent
[17:26:33 EST(-0500)] <Bosmon> This at least narrows our discussion somewhat
[17:26:40 EST(-0500)] <colinclark> so that second argument to makeComponent would be the creator function?
[17:26:46 EST(-0500)] <Bosmon> Yes
[17:27:02 EST(-0500)] <colinclark> And the first argument is an object containing all the stuff that should be attached to it?
[17:27:08 EST(-0500)] <Bosmon> Yes
[17:27:24 EST(-0500)] <Bosmon> Which, as it would be written in the file, is the "old occupant" of fluid.pager
[17:27:30 EST(-0500)] <Bosmon> Which under this model would start off as a {}
[17:27:34 EST(-0500)] <colinclark> Yeah
[17:27:36 EST(-0500)] <Bosmon> Rather than as a function
[17:27:36 EST(-0500)] <colinclark> It's not idael
[17:27:38 EST(-0500)] <colinclark> ideal
[17:27:50 EST(-0500)] <colinclark> I would call it fluid.defineCreator() or something like that.
[17:27:58 EST(-0500)] <Bosmon> It's a shame Javascript doesn't allow operator overloading
[17:28:09 EST(-0500)] <Bosmon> The one thing you can't do in the language is change the meaning of the function call operator
[17:28:15 EST(-0500)] <colinclark> But it does require the component author to know that they have to make this thing which will eventually be replaced by another things.
[17:28:17 EST(-0500)] <colinclark> thing
[17:28:31 EST(-0500)] <Bosmon> And the other thing you can't do, is mix up the distinction between something which is a Function and something which isn't
[17:28:51 EST(-0500)] <colinclark> Bosmon: Yeah, that's something that is interesting about JS.
[17:28:56 EST(-0500)] <Bosmon> You can't "bequeath functionity" to something after the fact
[17:29:17 EST(-0500)] <colinclark> So, were we in C++, we'd just go ahead and overload the function call operator?
[17:29:22 EST(-0500)] <colinclark> (), in other words?
[17:29:26 EST(-0500)] <Bosmon> Well, yeah
[17:29:30 EST(-0500)] <Bosmon> Lots of the STL depends on that trick
[17:29:35 EST(-0500)] <colinclark> yes, i remember
[17:29:57 EST(-0500)] <Bosmon> You can make an "object", which then can become after the fact, functionally identical to a function
[17:30:04 EST(-0500)] <colinclark> yep
[17:30:10 EST(-0500)] <colinclark> It's not a terrible concept.
[17:30:10 EST(-0500)] <Bosmon> Since it can participate in things which are syntactically identical to function call expressions
[17:30:45 EST(-0500)] <Bosmon> It's certainly an even more baffling one than any we have yet tried to foist on our users
[17:30:56 EST(-0500)] <Bosmon> C++ calls them "function objects"
[17:31:00 EST(-0500)] <Bosmon> Anyway, we don't have them
[17:31:14 EST(-0500)] <colinclark>
[17:31:17 EST(-0500)] <Bosmon> We can't make fluid.pager into a function, if it wasn't one to start with....
[17:31:58 EST(-0500)] <colinclark> So makeComponent() would require the component dev to understand that they had to declare a "namespace object" first. And then they will have to pass it along with an unnamed function in order to define a real creator function within that namespace.
[17:32:00 EST(-0500)] <colinclark> So to speak.
[17:32:03 EST(-0500)] <Bosmon> Who would have thought we would find the JS type system insufficiently flexible
[17:32:07 EST(-0500)] <Bosmon> Well, right
[17:32:14 EST(-0500)] <Bosmon> And also this is a thing which they "needn't have to do"
[17:32:27 EST(-0500)] <Bosmon> Although to be sure, they "needn't" initialise themselves with initView
[17:32:29 EST(-0500)] <Bosmon> As an instance
[17:32:31 EST(-0500)] <colinclark> Whereas the otherThing.apply() approach means that they have to either understand the problem at hand...
[17:32:43 EST(-0500)] <colinclark> or copy by example this block of code that appears at the top of each file.
[17:32:50 EST(-0500)] <Bosmon> But explaining to them that calling "fluid.makeComponent" is something that they can do also implies they understand this issue
[17:33:02 EST(-0500)] <Bosmon> And have also made a component "large enough" to comprise a significant family of subcomponents
[17:33:25 EST(-0500)] <colinclark> yeah
[17:33:27 EST(-0500)] <colinclark> this is really not ideal
[17:33:30 EST(-0500)] <Bosmon> No
[17:33:38 EST(-0500)] <Bosmon> Every solution so far seems a bit unfortunate
[17:33:56 EST(-0500)] <colinclark> This sounds very silly, but I want to understand the options very clearly...
[17:33:59 EST(-0500)] <colinclark> So what if we dismissed concerns about use before definition as entirely theoretical?
[17:34:05 EST(-0500)] <Bosmon> Right, that is option 3
[17:34:10 EST(-0500)] <colinclark> And simply ignored the issue altogether.
[17:34:18 EST(-0500)] <colinclark> Crockford is very fuzzy in his argument on it.
[17:34:44 EST(-0500)] <colinclark> Ignoring issues is always the last resort...
[17:35:06 EST(-0500)] <Bosmon> Well, makeComponent() is the only option that allows us to write code that has no apparent violation of use before definition
[17:35:22 EST(-0500)] <colinclark> yes, true
[17:35:35 EST(-0500)] <Bosmon> But it seems that neither of us really likes it
[17:35:37 EST(-0500)] <colinclark> in which case, if we really think this is a serious issue, it's probably the only option
[17:37:13 EST(-0500)] <colinclark> His only point is that use before declaration is sloppy...
[17:37:16 EST(-0500)] <colinclark> which I agree with.
[17:37:29 EST(-0500)] <colinclark> All he says here is:
[17:38:16 EST(-0500)] <colinclark> "Hoisting... also prohibits the use of function statements in if statements. It turns out that most browsers allow function statements in if statements, but they vary in how that should be interpreted."
[17:38:44 EST(-0500)] <Bosmon> I'm not sure I completely understand that point
[17:38:48 EST(-0500)] <Bosmon> I know you explained it to me once
[17:38:56 EST(-0500)] <colinclark> I wish we had recorded that...
[17:39:01 EST(-0500)] <colinclark> since I no longer have any clue.
[17:39:04 EST(-0500)] <Bosmon>
[17:39:14 EST(-0500)] <colinclark> I dunno.
[17:39:30 EST(-0500)] <colinclark> This feels like the imposition of added structure for little concrete gain, assuming we're right.
[17:39:31 EST(-0500)] <Bosmon> Anyway, I would argue that it is more than "sloppy"
[17:39:35 EST(-0500)] <colinclark> Me too.
[17:39:39 EST(-0500)] <Bosmon> But as you know, I am an elitist theoretician
[17:39:42 EST(-0500)] <colinclark> haha
[17:39:42 EST(-0500)] <colinclark> yes
[17:40:07 EST(-0500)] <Bosmon> Who believes that code which inherently has a clearer and guaranteed construction is better than code which could just be any old junk-heap
[17:40:21 EST(-0500)] <colinclark> Yes
[17:40:25 EST(-0500)] <colinclark> For sure.
[17:40:33 EST(-0500)] <colinclark> I suppose this is worthy of at least one shower.
[17:40:44 EST(-0500)] <Bosmon> Insisting on "no forward function calls" also guarantees absence of cyclic code knowledge
[17:40:48 EST(-0500)] <colinclark> yep
[17:41:04 EST(-0500)] <Bosmon> Which I think we had a fair amount of in "old pager"
[17:41:32 EST(-0500)] <colinclark> Could we imagine makeComponent() buying us anything else down the road? I suppose it would allow us to invisibly add framework logic before or after the creator function. Though that is entirely abstract.
[17:41:44 EST(-0500)] <colinclark> old pager was cyclic, yes
[17:41:52 EST(-0500)] <Bosmon> It sounds like having it buy anything for us down the road could be really devastating
[17:41:55 EST(-0500)] <Bosmon>
[17:41:59 EST(-0500)] <colinclark> ha
[17:42:13 EST(-0500)] <Bosmon> Its worst problem already is its untransparency
[17:42:30 EST(-0500)] <Bosmon> Creating the possibility that it might do anything else other than one simple thing seems to just compound its worst fault
[17:42:42 EST(-0500)] <colinclark>
[17:42:46 EST(-0500)] <colinclark> that is hilarious
[17:43:01 EST(-0500)] <Bosmon> One of the things that makes JQuery hard to read as a codebase is its extensive use of self-manipulation
[17:43:14 EST(-0500)] <colinclark> yes, for sure
[17:43:36 EST(-0500)] <colinclark> It definitely reads awkwardly because of that.
[17:43:38 EST(-0500)] <Bosmon> After a while you just "know by experience" where various functions are defined
[17:43:50 EST(-0500)] <Bosmon> And what you actually get, when you invoke a thing with a particular name
[17:44:01 EST(-0500)] <Bosmon> But it is practically impossible to anticipate in advance, simply through reading it
[17:44:01 EST(-0500)] <colinclark> We have an awkward balancing act here...
[17:44:15 EST(-0500)] <colinclark> Since obviously the least inconvenience should be given to the end-user.
[17:44:16 EST(-0500)] <Bosmon> And makeComponent starts to represent a kind of step down this route
[17:44:20 EST(-0500)] <colinclark> The component implementor.
[17:44:46 EST(-0500)] <colinclark> But then, we would love to see people writing their own components and not having to know everything we have learned over the past couple years of JS development.
[17:45:15 EST(-0500)] <Bosmon> To be sure, makeComponent represents no overhead, compared to what you have to learn for JQuery UI plugin development
[17:45:23 EST(-0500)] <colinclark> The impl.apply() approach really does just end up looking like "oh, I have to stick this at the beginning of my file, whatever it does."
[17:45:24 EST(-0500)] <Bosmon> Their model is far more malign and involved
[17:45:36 EST(-0500)] <colinclark> ach
[17:45:37 EST(-0500)] <colinclark> ack
[17:45:39 EST(-0500)] <Bosmon> Well, surely they would know what impl.apply() does
[17:45:43 EST(-0500)] <colinclark> i'm nearly late for a chiropractor appointment
[17:45:47 EST(-0500)] <Bosmon>
[17:45:48 EST(-0500)] <colinclark> shoot
[17:45:58 EST(-0500)] <Bosmon> x.apply() is surely almost the #1 most useful Javascript idiom
[17:46:01 EST(-0500)] <colinclark> jessm_ knows how my chiropractor is on the verge of firing me
[17:46:02 EST(-0500)] <Bosmon> Sorry
[17:46:05 EST(-0500)] <colinclark> no, no
[17:46:07 EST(-0500)] <colinclark> this was very interesting
[17:46:09 EST(-0500)] <Bosmon> You had better run
[17:46:12 EST(-0500)] <colinclark> we will have to pick up tomorrow
[17:46:12 EST(-0500)] <jessm_> colinclark: gogogo
[17:46:14 EST(-0500)] <colinclark> i have to really run
[17:46:15 EST(-0500)] <colinclark> see you
[17:46:21 EST(-0500)] <Bosmon> I mean, you could say it is like the same boilerplate we have for global namespacing
[17:46:30 EST(-0500)] <Bosmon> Which is already somewhat bizarre and involved-looking
[17:46:32 EST(-0500)] <jessm_> Bosmon: let's talk about CMS made simple is neither a CMS nor is it simply made
[17:46:33 EST(-0500)] <Bosmon> And versioning, etc.
[17:46:45 EST(-0500)] <Bosmon> Glarg to you, O CATT
[17:46:51 EST(-0500)] <jessm_>
[17:47:31 EST(-0500)] <jessm_> Bosmon: go sleep – Ms. Piglet Pants and I have a date we must attend
[17:47:40 EST(-0500)] <Bosmon> ,,,?!?!?!
[17:48:00 EST(-0500)] <jessm_> i have to walk the dog, so I too am leaving you
[17:48:12 EST(-0500)] <Bosmon> I don't need people to talk to
[17:48:14 EST(-0500)] <Bosmon>
[17:48:18 EST(-0500)] <jessm_> lol
[17:48:28 EST(-0500)] <Bosmon> Anyway, Dan is also still in the office here...
[17:48:41 EST(-0500)] <jessm_> hi to Dan!
[17:49:07 EST(-0500)] <jessm_> and for my next trick, tomorrow will be Yoshimi vs. the Robot or Jess vs. the Webpage
[17:53:14 EST(-0500)] * famicom (i=famicom@5ED2FF2D.cable.ziggo.nl) has joined #fluid-work
[18:00:24 EST(-0500)] * clown (n=clown@bas1-cooksville17-1279271796.dsl.bell.ca) has left #fluid-work
[19:00:26 EST(-0500)] * phiggins (n=dante@74.11.156.6) has joined #fluid-work
[19:09:26 EST(-0500)] * ecochran (n=ecochran@dhcp-169-229-212-28.LIPS.Berkeley.EDU) has left #fluid-work
[19:49:50 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined #fluid-work
[20:12:50 EST(-0500)] * phiggins (n=dante@74.11.156.6) has joined #fluid-work
[20:17:22 EST(-0500)] * phiggins (n=dante@74.11.156.6) has joined #fluid-work
[20:29:11 EST(-0500)] * phiggins (n=dante@74.11.156.6) has joined #fluid-work
[22:11:08 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[22:28:24 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work