[08:19:25 CST(-0600)] <heidi_> hey Justin_o ... did we decide the ellipses/shortened text thing was not fss? http://issues.fluidproject.org/browse/FLUID-3214 <heidi_> and i imagine in that stylesheet they just have h1 h2 etc... so there are no special class names <colinclark> onFileSuccess.addListener(function () ); <colinclark> onFileSuccess.addListener(function (file) ); <colinclark> onFileSuccess.addListener(function (file, serverData) );
[08:26:05 CST(-0600)] <Justin_o> heidi_: ah yes... I think you were right.. would you mind updating that for me
[08:26:20 CST(-0600)] <heidi_> sure, np
[08:26:51 CST(-0600)] <Justin_o> thanks
[08:26:54 CST(-0600)] <heidi_> Justin_o what category would make sense? it feels like one of those little helper extras... do we have a section for that
[08:28:03 CST(-0600)] <Justin_o> heidi_: hmm.. not sure.. michelled might have an idea.. i think you might also file it under the uploader or cross file it against that..since it is needed there
[08:28:17 CST(-0600)] <heidi_> k
[08:28:49 CST(-0600)] <heidi_> Justin_o still a 1.4 thing?
[08:56:03 CST(-0600)] <Justin_o> heidi_: sorry about the late reply, not sure
[08:56:14 CST(-0600)] <Justin_o> you can leave it at 1.4 and we can move it later if need be
[08:56:45 CST(-0600)] <heidi_> cool thanks
[09:00:18 CST(-0600)] <Justin_o> heidi_: i've removed FLUID-3214 from this page http://wiki.fluidproject.org/display/fluid/FSS+1.4+-+1.5+Roadmap
[09:00:35 CST(-0600)] <heidi_> cool
[09:04:47 CST(-0600)] <heidi_> michelled i'm thinking of starting the !important jira for FSS (FLUID-4022)... just starting by removing all of them and then seeing how it effects UIO - cool?
[09:04:58 CST(-0600)] <heidi_> affects
[09:05:08 CST(-0600)] <heidi_> no effect ahh..
[09:09:03 CST(-0600)] <michelled> heidi_: sounds good - are you working in your fork?
[09:09:11 CST(-0600)] <heidi_> michelled yep
[09:11:45 CST(-0600)] <colinclark> heidi_: So here's my theory about what it will affect...
[09:11:54 CST(-0600)] <colinclark> I think for most FSS-using pages, it'll probably be just fine
[09:12:14 CST(-0600)] <colinclark> So, for example, if you tested with the IDI site or whatever, the lack of !important will really have no impact
[09:12:26 CST(-0600)] <colinclark> I think it's cases where you've got non-FSS using styles
[09:12:33 CST(-0600)] <colinclark> The classic example is in uPortal...
[09:12:41 CST(-0600)] <colinclark> where you've got a whole bunch of mixed content in there
[09:12:47 CST(-0600)] <colinclark> The portal itself uses FSS
[09:12:48 CST(-0600)] <heidi_> right ya
[09:12:52 CST(-0600)] <colinclark> some of the portlets do, too
[09:13:02 CST(-0600)] <colinclark> but others will just be random stuff from the Web
[09:13:21 CST(-0600)] <colinclark> michelled and Bosmon2 and I were trying to remember last week
[09:13:35 CST(-0600)] <colinclark> and we're pretty sure this is precisely the reason why !important was added everywhere
[09:13:45 CST(-0600)] <colinclark> to override other people's styles, no our own styles
[09:13:47 CST(-0600)] <colinclark> if that makes sense
[09:13:48 CST(-0600)] <michelled> colinclark, heidi_: I think we were looking at a portlet that pulled in other websites
[09:13:53 CST(-0600)] <colinclark> right
[09:13:56 CST(-0600)] <michelled> so it was content that we didn't have any control over
[09:14:00 CST(-0600)] <colinclark> Like the Web Content portlet, etc.
[09:14:34 CST(-0600)] <heidi_> this is in a uportal demo or website or?
[09:14:40 CST(-0600)] <jessm> golam: can you do skype?
[09:15:21 CST(-0600)] <colinclark> heidi_: The mockup we have might show the issue
[09:15:25 CST(-0600)] <golam> sure let me check my headset..let me get back to you in few minutes
[09:15:34 CST(-0600)] <colinclark> but we're of course best to try with a real live instance of uPortal
[09:16:21 CST(-0600)] <heidi_> colinclark do you know what things in particular it was having trouble over-riding?
[09:16:27 CST(-0600)] <heidi_> it would i mean
[09:16:50 CST(-0600)] <michelled> heidi_: colours were an issue
[09:17:00 CST(-0600)] <michelled> especially when trying to deal with high contrast
[09:17:04 CST(-0600)] <michelled> and inverted high contrast
[09:17:26 CST(-0600)] <heidi_> okay. i'll play and document what i find
[09:17:40 CST(-0600)] <Justin_o> heidi_, colinclark, michelled: Here's jQuery UI's style sheet that includes the .ui-helper-clearfix https://github.com/jquery/jquery-ui/blob/master/themes/base/jquery.ui.core.css
[09:18:02 CST(-0600)] <michelled> heidi_: I think font style and size were ok, but I'd need to look at that carefully - I don't have jameswy and fj's skill of seeing pixel perfection
[09:20:50 CST(-0600)] <Justin_o> here's what we currently use .fl-fix https://github.com/fluid-project/infusion/blob/master/src/webapp/framework/fss/css/fss-layout.css
[09:20:52 CST(-0600)] <colinclark> michelled, heidi_: I wonder if we should put together a fairly thorough test page
[09:21:06 CST(-0600)] <colinclark> Perhaps we have something that will be sufficient
[09:21:32 CST(-0600)] <colinclark> but it seems pretty useful to have a page that uses a variety of FSS features as well as markup and styles that don't use the FSS
[09:21:42 CST(-0600)] <heidi_> Justin_o that clearfix styling is interesting, thanks
[09:21:51 CST(-0600)] <colinclark> slap UIO in there, and we can clearly measure the impact of any changes on FSS
[09:22:17 CST(-0600)] <michelled> colinclark: that makes sense. we used to have a test page in the integration examples - it was a long time ago
[09:22:20 CST(-0600)] <heidi_> colinclark i think a solid test page would be good
[09:22:28 CST(-0600)] <michelled> I can't even remember where fj grabbed the content from
[09:22:49 CST(-0600)] <heidi_> maybe even a new manual test in /tests
[09:24:01 CST(-0600)] <Justin_o> heidi_: i find the clearfix styling to be a bit strange and confusing, i'm not sure why they are adding content for example
[09:24:18 CST(-0600)] <heidi_> Justin_o it's definitely... creative. i'd have to think on it more
[09:24:58 CST(-0600)] <Justin_o> heidi_: okay
[09:25:29 CST(-0600)] <heidi_> Justin_o the not nice way of handling this problem (a container of floating divs not containing the elements) was just <br style="clear:both" /> ...i.e. a block element that clears
[09:25:49 CST(-0600)] <heidi_> Justiin_o so i think this is just introducing a hidden thing vs a <br>
[09:26:25 CST(-0600)] <Justin_o> heidi_: okay...
[09:27:02 CST(-0600)] <colinclark> yes, i think that is correct
[09:27:17 CST(-0600)] <heidi_> their hidde-accessible style is interesting too
[09:28:00 CST(-0600)] <cindyli> hi, anastasiac, is this the most recent uploader api: http://wiki.fluidproject.org/display/fluid/Uploader+API
[09:28:41 CST(-0600)] <anastasiac> cindyli, I believe that should be the correct API for 1.3.1 - maybe mlam can confirm that?
[09:28:56 CST(-0600)] <heidi_> Justin_o instead of sending some hidden text content off-screen with a huge text-indent, they're just making it a 1px thing. i think i like that
[09:29:05 CST(-0600)] <mlam> cindyli: anastasiac: checking the link to confirm...
[09:29:32 CST(-0600)] <heidi_> Justin_o i might add a jira for that as well (right now we do the off-screen thing in fss)
[09:29:52 CST(-0600)] <mlam> cindyli: anastasiac: yes, that's the latest uploader API
[09:29:59 CST(-0600)] <anastasiac> thanks, mlam
[09:30:01 CST(-0600)] <mlam> np
[09:30:22 CST(-0600)] <Justin_o> heidi_: yes.. i was looking at that too
[09:30:33 CST(-0600)] <cindyli> anastasiac: mlam, thx.
[09:30:45 CST(-0600)] <Justin_o> heidi_: why do you think they have "clip" there twice
[09:31:20 CST(-0600)] <heidi_> Justin_o must be for cross-browser? one has commas
[09:31:48 CST(-0600)] <Justin_o> heidi_: okay.. that makes sense
[09:31:54 CST(-0600)] <colinclark> Justin_o: You might find this helpful for explaining more or less how jQuery UI's clearfix works: http://perishablepress.com/press/2009/12/06/new-clearfix-hack/
[09:32:06 CST(-0600)] <heidi_> Justin_o another interesting thing is they have a reset CLASS ... so you can reset what you want. that's kind of cool
[09:32:25 CST(-0600)] <colinclark> And then here's some background reading on layout in IE: http://www.satzansatz.de/cssd/onhavinglayout.html
[09:32:29 CST(-0600)] <Justin_o> heidi_: that's a good point, it's pretty short too
[09:34:51 CST(-0600)] <Justin_o> colinclark: thanks for the links
[09:35:13 CST(-0600)] <cindyli> mlam: have a quesiton that i come across with the new uploader demo. i'm returning the URL to the uplaoded image at server side so that the js can add it to the viewer. the only parameter of onFileSuccess() is "file", is there a way I can retrieve the returned server message as well?
[09:36:11 CST(-0600)] <mlam> Cindy, yes. You can retrieve a series of server feedback through the XHR object in the HTML5 version of the uploader
[09:36:44 CST(-0600)] <cindyli> mlam: how? in onFileSuccess()?
[09:36:54 CST(-0600)] <colinclark> mlam: Which means the answer is really "no", since it'll only work in one configuration and it's not exposed publicly to users of the Uploader, right?
[09:37:28 CST(-0600)] <mlam> right. The SWF hasn't been helpful at all with server responses
[09:37:44 CST(-0600)] <colinclark> cindyli: Can you elaborate on what you want to do?
[09:44:00 CST(-0600)] <cindyli> colinclark: mlam, the uploader html page has 2 parts, the uploader at the left and a viewer at right, the uploaded images are dynamically added and displayed in the viewer. the html page sends a session token along with the upload request so that the php server is able to distinguish the upload from the different users. the server side receives the uploaded file, places into a temp folder named by the session token from the client, sends back the message
[09:47:32 CST(-0600)] <cindyli> colinclark: mlam, if anything goes wrong at server side, for instance, no file is received, session token is not provided, etc, the server returns a error message with http status code 400, the client side displays the error on the interface along with the according file name. so, another problem i have is with onFileError() event. although uploader api says 3 parameters for this event: file, errorCode, message, i actually only get 2 "file, errorCode", al
[09:51:54 CST(-0600)] <mlam> colinclark: cindyli: since the uploader doesn't provide server responses in both uploader strategies, could our new php server handle these messages itself instead?
[09:53:14 CST(-0600)] <Justin_o> michelled, colinclark, heidi_ : I'm just reading the documentation on fl-fx http://wiki.fluidproject.org/display/fluid/FSS+API it says "Forces an element to encapsulate its children"
[09:53:32 CST(-0600)] <Justin_o> I'm not sure i really understand what that means, does it sound the same to you as what clearfix is trying to do
[09:54:05 CST(-0600)] <bsparks> which file contains the changeApplier code?
[09:55:42 CST(-0600)] <heidi_> Justin_o yeah so a common scenario would be if you have a container div with a background colour or border, and inside of it (its children) are a bunch of floating divs, you'll see the border/bg doesn't go to the bottom of those divs. so clearfix is something you tack on at the bottom to "clear" the div, and force the container to encapsulate the floating stuff
[09:55:47 CST(-0600)] <golam> michelled: please let me know what you think of my inline-edit manual to automated code changes.
[09:55:49 CST(-0600)] <bsparks> nm found it, DataBinding.js
[09:55:57 CST(-0600)] <colinclark> bsparks: Beat me to it 
[09:56:07 CST(-0600)] <bsparks> thx
[09:56:09 CST(-0600)] <michelled> golam: are your changes in your fork?
[09:56:37 CST(-0600)] <golam> michelled: I have send you the diff on Thursday
[09:57:10 CST(-0600)] <michelled> golam: what should I apply the patch too? the fork?
[09:57:48 CST(-0600)] <golam> michelled: sure
[09:57:55 CST(-0600)] <Justin_o> heidi_: okay.. thanks...
[09:58:04 CST(-0600)] <heidi_> Justin_o does that make sense?
[09:58:16 CST(-0600)] <michelled> golam: ok, I'll take a look
[09:58:17 CST(-0600)] <golam> michelled: I haven't pushed my changes to githum
[09:58:28 CST(-0600)] <Justin_o> heidi_: yep it does... i'm sort of puzzling over why fl-fix is so different from the clearfix method
[09:58:30 CST(-0600)] <golam> michelled: github*
[09:59:32 CST(-0600)] <golam> michelled: I just send you the changes between two files
[10:00:17 CST(-0600)] <heidi_> Justin_o the fl-fix is a little weird. i think overflow might force something to be a block element (clear at the end of it). it's kind of round 'about and doesn't directly solve the problem without adding some extra stuff (i.e scrollbars)
[10:00:41 CST(-0600)] <michelled> golam: I think it will be easier for me to review it in the context of the whole files so I'm going to apply it to your fork and then take a look at it
[10:00:53 CST(-0600)] <Justin_o> heidi_: okay...
[10:01:20 CST(-0600)] <Justin_o> colinclark: just to double check, was overflow: auto causing the FF4 bug where you can tab to elements that shouldn't be tabable
[10:02:06 CST(-0600)] <golam> michelled: ok
[10:05:10 CST(-0600)] <Justin_o> heidi_: okay.. so according the site colinclark sent, overflow:auto (should work in IE7) and zoom should trigger the hasLayout in IE
[10:05:17 CST(-0600)] <golam> michelled: I just pushed my changes to github
[10:05:24 CST(-0600)] <Justin_o> but that stuff i guess won't take into account other browsers
[10:05:53 CST(-0600)] <michelled> golam: ok, so I shouldn't look at the patch you sent me?
[10:06:14 CST(-0600)] <golam> michelled: that's right, you can just fork FLUID-4044
[10:06:52 CST(-0600)] <heidi_> Justin_o i wonder if clearfix works in Ie7?
[10:07:14 CST(-0600)] <golam> michelled: https://github.com/gchowdhury/infusion/tree/FLUID-4044
[10:08:18 CST(-0600)] <golam> michelled: https://github.com/gchowdhury/infusion/blob/FLUID-4044/src/webapp/tests/component-tests/inlineEdit/js/InlineEditTests.js
[10:08:21 CST(-0600)] <Justin_o> heidi_: i guess if the part that's commented as being for opera works for it... since it seems that IE7 doesn't support :after
[10:09:40 CST(-0600)] <Justin_o> heidi_: i think the height: 1% should work for IE
[10:09:54 CST(-0600)] <heidi_> ahh
[10:11:35 CST(-0600)] <Justin_o> colinclark, heidi_ : is there a preference for grabbing the code that jquery ui uses, versus deprecating fl-fix and shipping jquey ui's base css file?
[10:12:12 CST(-0600)] <heidi_> Justin_o maybe the latter since the -hidden-accessible and -reset classes are also prob soemthing we'd like to use
[10:12:50 CST(-0600)] <heidi_> but i'm not sure if making fss self-contained is important
[10:13:45 CST(-0600)] <Justin_o> heidi_: i'm also wondering if .ui-helper-reset does everything that we want
[10:14:04 CST(-0600)] <heidi_> yeah i wonder if that's a nicer way to go... not sure
[10:15:39 CST(-0600)] <Justin_o> we could also scope our reset file, so that you would have to have fl-reset on a parent element before or something?
[10:15:51 CST(-0600)] <Justin_o> oops, didn't mean to put a "?" there
[10:18:37 CST(-0600)] <heidi_> yeah that might be a good way of doing it too...
[10:19:18 CST(-0600)] <colinclark> just catching up here
[10:20:04 CST(-0600)] <cindyli> mlam: colinclark, sorry, was away in a chat with greg. mlam, ur question "could our new php server handle these messages itself instead?", do u mean pass the message in another way not via onFileSuccess() or onFileError()? i will think about it
[10:21:13 CST(-0600)] <colinclark> Justin_o: Yes, overflow:auto will cause elements to be added to the tab order in Firefox 4
[10:21:24 CST(-0600)] <colinclark> and it doesn't look like this behaviour will be fixed until Firefox 5
[10:21:37 CST(-0600)] <colinclark> though keep in mind that Mozilla is planning to substantially speed up their release cycle
[10:21:51 CST(-0600)] <Justin_o> colinclark: that's probably reason enough to make a change to fl-fix
[10:22:04 CST(-0600)] <Justin_o> colinclark: right... so it may not be that far off
[10:22:22 CST(-0600)] <colinclark> Justin_o, heidi_: Do we have a good piece of test markup that clearly shows the behaviour we're trying to fix with fl-fix and other clearfix strategies?
[10:22:37 CST(-0600)] <colinclark> This might sound a bit like my comment earlier about UI Options and !important
[10:22:43 CST(-0600)] <colinclark> We should put together a simple clearfix test page
[10:22:46 CST(-0600)] <Justin_o> colinclark: i'm not sure i was going to look through our code base to see where we use it
[10:22:51 CST(-0600)] <colinclark> So we can try it out in multiple browsers
[10:23:01 CST(-0600)] <colinclark> and then I think we are probably looking at a few different options:
[10:23:14 CST(-0600)] <colinclark> 1. Sticking with fl-fix or tweaking it a bit
[10:23:31 CST(-0600)] <colinclark> 2. Including jQuery UI's base CSS file as-is and asking FSS users to use it
[10:23:55 CST(-0600)] <colinclark> 3. Including jQuery's implementation for our own fl-fix class name
[10:24:06 CST(-0600)] <colinclark> 4. Evaluating other clearfix solutions, such as the one in the blog post I mentioned earlier
[10:24:29 CST(-0600)] <colinclark> It sounds like, Justin_o, you're saying that #1 is not a great solution, particularly because of the overflow:auto bug in FF4
[10:24:48 CST(-0600)] <colinclark> hey golam
[10:24:50 CST(-0600)] <colinclark> quick question for you
[10:25:05 CST(-0600)] <colinclark> I just saw that you moved the Affects Version of FLUID-4018 to 1.3.1
[10:25:16 CST(-0600)] <golam> colinclark: hey just updating some jira's affect version to 1.3.1
[10:25:26 CST(-0600)] <colinclark> I thought that one was fixed in 1.3.1. Did you test it before upgrading the Affects Version?
[10:26:18 CST(-0600)] <golam> colinclark: no I didn't test,
[10:26:25 CST(-0600)] <heidi_> Justin_o let me know what other clearfix solutions you find.
[10:26:28 CST(-0600)] <Justin_o> colinclark: those sound like reasonable approaches... the one in jquery seemed more general, but since we don't support opera either we could switch to the one from the blogpost you sent
[10:26:56 CST(-0600)] <Justin_o> heidi_: okay.. the one colin mentioned is from http://perishablepress.com/press/2009/12/06/new-clearfix-hack/
[10:27:28 CST(-0600)] <golam> colinclark: let me test FLUID-4018
[10:27:38 CST(-0600)] <colinclark> golam: I think we should be sure to test each issue, or check with the component leads, before bumping the Affects Version up
[10:27:55 CST(-0600)] <colinclark> mlam and cindyli: Your issue from earlier... it's an interesting one, and a big one
[10:28:29 CST(-0600)] <colinclark> So, if I can summarize, I think the problem is due to the fact that we don't pass back any information about the server's response on any of the upload-related events
[10:28:37 CST(-0600)] <colinclark> In particular onFileSuccess and onFileError
[10:28:46 CST(-0600)] <colinclark> Is that correct, cindyli and mlam?
[10:28:52 CST(-0600)] <cindyli> colinclark: mlam, correct
[10:28:56 CST(-0600)] <colinclark> Okay, great
[10:29:02 CST(-0600)] <golam> colinclark: I thought since we released 1.3.1 already then all those issues were tested already
[10:29:03 CST(-0600)] <mlam> colinclark: I think handling server responses is very tough simply because server responses will differ depending on the platform being used to build the server
[10:29:37 CST(-0600)] <colinclark> So, in the abstract (in other words, independently of how SWFUpload or our own HTML5 version work), can we think of any argument for why we'd want to shield the user from this response information?
[10:29:46 CST(-0600)] <colinclark> Does it make any sense at all?
[10:30:07 CST(-0600)] <colinclark> mlam: Well, what does that really mean, though? HTTP certainly provides a standard for the format of server responses.
[10:30:22 CST(-0600)] <colinclark> What the client does with the response may depend largely on the nature of the application
[10:46:45 CST(-0600)] <mlam> colinclark: You're right. I guess a better question from me would be...which server errors would we want to listen for? And how extensive do we want our server error support to be?
[10:49:53 CST(-0600)] <colinclark> Well, off the top of my head
[10:50:01 CST(-0600)] <heidi_> Justin_o that clearfix hack url looks similar to jquery's
[10:50:50 CST(-0600)] <colinclark> I'm wondering if we should simply pass back the response info in a comparable manner to what you'd get back from a jQuery.ajax() request, mlam
[10:51:06 CST(-0600)] <colinclark> I guess no one can think of any compelling reasons why we'd hide response info from our users, right/
[10:51:14 CST(-0600)] <colinclark> Seems like a fairly bad bug to me
[10:51:15 CST(-0600)] <mlam> Would you be opposed to having our new image gallery handling these server errors itself, rather than having the uploader listen for them?
[10:51:30 CST(-0600)] <colinclark> How would it do that?
[10:53:35 CST(-0600)] <mlam> Create a lightweight front end for the image gallery itself to listen for the server errors, have a template that will serve these error messages and we can place this template above the uploader template so that the uploader template itself won't be affected in any way?
[10:58:35 CST(-0600)] <colinclark> sorry, in a quick meeting
[10:58:37 CST(-0600)] <colinclark> will respond shortly
[11:05:06 CST(-0600)] <cindyli> mlam: r u suggesting a separate independent listener out of the uploader object? as i understand, the interaction between the client and server is all via uploader object, how can we make this independent listner. Moreover, is this the right way to go in the long run? my point is onSuccess and onFaill events seem to be right places returning server response/message.
[11:05:26 CST(-0600)] <colinclark> okay, sorry
[11:05:39 CST(-0600)] <colinclark> cindyli: I agree with you
[11:07:41 CST(-0600)] <cindyli> mlam: colinclark: thx. if we can do similar thing as u said like jquery ajax() onSuccess, onFail, that would be good enough
[11:10:01 CST(-0600)] <colinclark> I'm just taking a look at the SWFUpload source code to figure out why we're not getting much in the way of useful information back from it
[11:10:29 CST(-0600)] <cindyli> thx
[11:20:20 CST(-0600)] <colinclark> So, Flash is going to be our weakest link here, I think
[11:20:31 CST(-0600)] <colinclark> In this case, it's not even SWFUpload, but Flash's limits
[11:20:36 CST(-0600)] <colinclark> We'll just have to cross our fingers
[11:20:53 CST(-0600)] <colinclark> According to the source code, it looks like the we can expect the following signatures for our two events:
[11:21:18 CST(-0600)] <colinclark> For success, here's what SWFUpload's ActionScript code look like:
[11:21:22 CST(-0600)] <colinclark> ExternalCall.UploadSuccess(this.uploadSuccess_Callback, file.ToJavaScriptObject(), serverData, responseReceived);
[11:22:07 CST(-0600)] <colinclark> This will call the uploadSuccess_Callback (which is the equivalent of our onFileSuccess or whatever we call it) with three arguments: 1. the File, 2. the "server data", and 3. The response code
[11:22:25 CST(-0600)] <colinclark> "server data" is a bit ambiguous to me, but it likely contains the response data
[11:22:43 CST(-0600)] <colinclark> Here's the error case:
[11:22:48 CST(-0600)] <colinclark> ExternalCall.UploadError(this.uploadError_Callback, this.ERROR_CODE_HTTP_ERROR, this.current_file_item.ToJavaScriptObject(), event.status.toString());
[11:23:29 CST(-0600)] <colinclark> This'll call the uploadError_Callback (our onFileError event) with three arguments: 1. the HTTP response code, 2. the file, and 3. a string containing the response status message
[11:24:01 CST(-0600)] <colinclark> I'll need to do a bit of testing with the Image Gallery to be sure we actually get these things correctly in the Uploader, and pass them on to the user
[12:18:40 CST(-0600)] <heidi_> hey michelled could you tell me how uio applies styles? you make a site with fss, include all the fss stylesheets.. then how does the switching styles get implemented
[12:19:41 CST(-0600)] <michelled> the engine is UIEnhancer so you should be able to read the code. For the most part, classes get added and removed from the body which causes the restyling
[12:19:51 CST(-0600)] <michelled> heidi_ ^
[12:20:30 CST(-0600)] <heidi_> ill check out enhancer documentation. so for example, to switch a theme, what does it do
[12:20:33 CST(-0600)] <heidi_> michelled
[12:20:38 CST(-0600)] <michelled> golam: I have some comments for you on your last push. what works best for you? Should I comment on the commit on github? Or would you rather come over here and chat in person
[12:20:40 CST(-0600)] <michelled> ?
[12:20:57 CST(-0600)] <michelled> heidi_: I doubt you'll find all that much in the documentation
[12:21:13 CST(-0600)] <heidi_> ok
[12:21:13 CST(-0600)] <michelled> for sure the themes are done by putting a class on the body
[12:21:27 CST(-0600)] <heidi_> right ya
[12:21:37 CST(-0600)] <golam> michelled: I will come over, let me know when
[12:21:44 CST(-0600)] <michelled> now is good
[12:21:47 CST(-0600)] <michelled> golam ^
[12:21:55 CST(-0600)] <golam> michelled: coming over
[12:23:47 CST(-0600)] <heidi_> colinclark thinking about UIO. the way web dev toolbar adds styles is to inject a stylesheet above </head> so it over-rides previous styles. was there a reason this method wasn't used?
[12:24:20 CST(-0600)] <colinclark> heidi_: Yeah, inlining was one of the potential strategies we talked about at last week's FSS meeting
[12:24:39 CST(-0600)] <heidi_> inline styles?
[12:24:47 CST(-0600)] <colinclark> It will win against anything other than someone else's !important declarations and other inline styles deeper in the document.
[12:24:58 CST(-0600)] <colinclark> <style> tags
[12:25:08 CST(-0600)] <heidi_> ok
[12:25:19 CST(-0600)] <colinclark> I assume that's what you're referring to
[12:25:22 CST(-0600)] <heidi_> yep
[12:25:24 CST(-0600)] <heidi_> well
[12:25:41 CST(-0600)] <heidi_> just adding another <link our stylesheet> in the <head>
[12:26:38 CST(-0600)] <heidi_> you wouldn't have to use fss for UIO then.
[12:26:49 CST(-0600)] <colinclark> hmm
[12:26:54 CST(-0600)] <heidi_> i mean, we will
[12:26:56 CST(-0600)] <colinclark> I'm not sure, then, I fully follow you
[12:27:38 CST(-0600)] <heidi_> sorry just thinking out loud. that stylesheet we inject (at the bottom so it overrides others) doesn't have to ref fss classnames
[12:27:54 CST(-0600)] <heidi_> cos it could use html tags instead of classes.
[12:28:00 CST(-0600)] <heidi_> for some things
[12:28:20 CST(-0600)] <heidi_> i'm not explaining this well...
[12:29:14 CST(-0600)] <heidi_> i'll try to compose my thoughts better and get back to you.
[12:29:28 CST(-0600)] <heidi_> i'm thinking about dynamic stylesheets - something UIO creates and injects
[12:38:56 CST(-0600)] <heidi_> colinclark: if you turn on outline>headings in web dev toolbar, it injects a stylesheet at the bottom of yr <head> "chrome://webdeveloper/content/stylesheets/outline_headings.css" ...so just thinking about that approach. UIO has so many options it would be too many stylesheets to have one for each thing, but we could prob dynamically create one that reflects the users choices. thinking about how this would influence fss..
[12:40:03 CST(-0600)]
[12:40:36 CST(-0600)] <colinclark> hang on, in a meeting
[12:40:40 CST(-0600)] <heidi_> np
[12:42:56 CST(-0600)] <colinclark> So, we've definitely done some dynamic CSS generation in the past
[12:43:08 CST(-0600)] <colinclark> That's how PreferAble worked, back in the days of TransformAble
[12:43:16 CST(-0600)] <colinclark> Or rather, StyleAble
[12:43:36 CST(-0600)] <colinclark> You can think of UIEnhancer (the thing that actually applies the styling changes for UI Options) as the next generation of StyleAble
[12:43:41 CST(-0600)] <colinclark> StyleAble was a stylesheet generator
[12:43:46 CST(-0600)] <colinclark> It worked for simple things
[12:43:58 CST(-0600)] <colinclark> It was very poor at many other things
[12:44:11 CST(-0600)] <colinclark> In part due to the lack of semantics in HTML
[12:44:18 CST(-0600)] <colinclark> It's really easy to override the styling for, say, a header
[12:44:36 CST(-0600)] <colinclark> much harder to correctly override styling for things that generally have a consistent meaning in a stylesheet
[12:44:41 CST(-0600)] <colinclark> say a menubar or something
[12:44:49 CST(-0600)] <colinclark> when there's no equivalent semantics
[12:44:58 CST(-0600)] <colinclark> We ended up having to build this kind of "hinting" system
[12:45:17 CST(-0600)] <colinclark> where an implementor of StyleAble would have to describe, in a fair bit of detail, many of the quirks of their site
[12:45:18 CST(-0600)] <colinclark> so
[12:45:29 CST(-0600)] <colinclark> so that we knew what stylesheet selectors to generate
[12:45:48 CST(-0600)] <colinclark> I can imagine that we'll get back to this
[12:46:00 CST(-0600)] <colinclark> We have a kind of funny name for this style of working
[12:46:09 CST(-0600)] <colinclark> Called "Ramanism," in homage to T.V. Raman
[12:46:28 CST(-0600)] <colinclark> who regularly advocates for this "Web developers never bother with accessibility, so inject it from the outside" approach
[12:46:37 CST(-0600)] <colinclark> It's a pretty fascinating approach
[12:46:44 CST(-0600)] <colinclark> On the other hand, it's wrought with challenges
[12:46:51 CST(-0600)] <colinclark> Brittleness in particular
[12:47:15 CST(-0600)] <colinclark> So I think the goal for our first pass of UI Options was always to assume the FSS' presence as much as possible
[12:47:24 CST(-0600)] <colinclark> clearly that only applies to some small portion of the sites out there
[12:47:30 CST(-0600)] <colinclark> but it serves as a kind of best case scenario
[12:47:45 CST(-0600)] <colinclark> Then, with time, to dive deeper into some of the more promising Ramanistic techniques
[12:52:17 CST(-0600)] <heidi_> colinclark another thought was that instead of including all the fss files in the header, and adding/removing classnames, was to make fss more... fish-able. so UIO could pick out of FSS what was needed, and inject that stylesheet
[12:52:38 CST(-0600)] <heidi_> still thinking about that one
[12:53:03 CST(-0600)] <colinclark> cool
[12:54:47 CST(-0600)] <heidi_> colinclark agreed we need the semantic-y layer fss provides in markup
[12:58:38 CST(-0600)] <heidi_> colinclark a lot of !importants in fss-text, but i see in the UIO demo for changing text size, it doesn't use fss fl-font-size but an inline "font-size: 16pt;" on the body tag.
[12:59:40 CST(-0600)] <colinclark> Take a look at the implementation of UI Enhancer to see what it's doing
[13:09:30 CST(-0600)] <heidi_> i see the "to do"
[13:10:27 CST(-0600)] <colinclark> Looks to me like it's doing both
[13:10:50 CST(-0600)] <colinclark> setting the fl-font-size class and injecting an inline style
[13:15:10 CST(-0600)] <heidi_> colinclark and i should be able to see my current uio model in a cookie right?
[13:16:50 CST(-0600)] <colinclark> Yep, as far as I remember
[13:24:27 CST(-0600)] <colinclark> okay, cindyli and mlam
[13:24:34 CST(-0600)] <colinclark> I have some more information
[13:24:47 CST(-0600)] <colinclark> So it seems like SWFUpload does what it says it does
[13:25:18 CST(-0600)] <colinclark> For onFileError, I received the following arguments from it:
[13:26:03 CST(-0600)] <colinclark> 1. The File object, 2. An error code of -200, which is SWFUpload's HTTP_ERROR, and 3. The HTTP response code as a String, in this case "500"
[13:26:41 CST(-0600)] <colinclark> For onFileSuccess, here are the arguments I received from SWFUpload:
[13:28:10 CST(-0600)] <colinclark> 1. The File object, 2. the response from the server (in the case of the Image Gallery, it simple returns the image's ID), and 3. For whatever reason, the Boolean value true
[13:28:22 CST(-0600)] <colinclark> Which appears to redundantly tell us that the upload was successful
[13:28:35 CST(-0600)] <colinclark> So, cindyli, is this enough for you to do what you want to do?
[13:29:31 CST(-0600)] <mlam> That's really good news
[13:31:07 CST(-0600)] <colinclark> It's worth comparing this with what we get from an ordinary jQuery.ajax() call
[13:31:16 CST(-0600)] <colinclark> 1. They provide a pointer to the raw XHR
[13:31:41 CST(-0600)] <colinclark> 2. They provide a text error message: "timeout", "error", "abort", that kind of thing
[13:31:58 CST(-0600)] <colinclark> For success, jQuery provides these arguments:
[13:32:04 CST(-0600)] <colinclark> 1. The server response data
[13:32:15 CST(-0600)] <colinclark> 2. The text status
[13:32:18 CST(-0600)] <colinclark> 3. The raw XHR
[13:32:55 CST(-0600)] <colinclark> The text status in this case is probably just going to be the string "success"
[13:33:19 CST(-0600)] <colinclark> So I guess this is comparable to what we have in the Uploader, if not quite identical
[13:33:46 CST(-0600)] <colinclark> So, mlam, this is good news but points out a bug or two in our HTML5 strategy
[13:33:52 CST(-0600)] <colinclark> events.onFileError.fire(file, fluid.uploader.errorConstants.UPLOAD_FAILED);
[13:34:10 CST(-0600)] <colinclark> That should probably pass along the HTTP response code as well
[13:34:12 CST(-0600)] <colinclark> and this...
[13:34:20 CST(-0600)] <colinclark> events.onFileSuccess.fire(file);
[13:34:25 CST(-0600)] <colinclark> should pass along the server data
[13:34:40 CST(-0600)] <colinclark> I'd also suggest that the last argument in the case of the HTML5 strategy should be the raw XHR
[13:34:42 CST(-0600)] <mlam> and I guess we can ignore the boolean value for the onFileSuccess?
[13:34:54 CST(-0600)] <colinclark> mlam: I suppose I should understand 100% what that boolean is
[13:34:59 CST(-0600)] <colinclark> but it seems awfully superfluous
[13:36:10 CST(-0600)] <colinclark> It seems to be a boolean telling the user if the server responded with any data
[13:36:17 CST(-0600)] <colinclark> it's an artifact of Flash's DataEvents
[13:36:22 CST(-0600)] <colinclark> which are a bizarre design
[13:36:23 CST(-0600)] <colinclark> a
[13:36:33 CST(-0600)] <colinclark> and so it seems to be an implementation detail leaking out into their public API
[13:36:49 CST(-0600)] <colinclark> I'm almost on the verge of arguing that we should remove it entirely from our events
[13:37:34 CST(-0600)] <colinclark> But I guess we can argue here that the third argument to onFileSuccess is "implementation-specific"
[13:37:35 CST(-0600)] <colinclark> ick
[13:37:36 CST(-0600)] <colinclark>
[13:38:38 CST(-0600)] <mlam> I guess there's no harm to include it since we wouldn't even need that boolean value for anything. It's a good way of maintaining consistency across the strategies
[13:39:03 CST(-0600)] <cindyli> colinclark: mlam, sorry i was out. really good news
[13:39:56 CST(-0600)] <colinclark> the problem with including it, mlam, is in explaining it to our users
[13:40:10 CST(-0600)] <colinclark> If I'm understanding that argument correctly, we'd have to document it as:
[13:40:41 CST(-0600)] <colinclark> "This third argument will always be true, except if you're using the SWFUpload strategy and an obscure and unrecoverable error occurs, in which case it will be false."
[13:40:52 CST(-0600)] <colinclark> aka
[13:41:05 CST(-0600)] <colinclark> "This particular argument is completely useless to you, and you should ignore it"
[13:43:14 CST(-0600)] <colinclark> mlam: Can you file a bug about the HTML5 strategy not conforming to the API semantics for onFileError and onFileSuccess?
[13:43:27 CST(-0600)] <mlam> Yes, I can do that
[13:43:36 CST(-0600)] <colinclark> And let's go with, for now, the notion that this third argument is implementation-specific and something a user shouldn't count on being present
[13:43:52 CST(-0600)] <colinclark> In other words, our stable, cross-strategy API is really two arguments (if that makes sense)
[13:43:54 CST(-0600)] <mlam> Ok.
[13:44:00 CST(-0600)] <mlam> yah, makes sense
[13:45:35 CST(-0600)] <colinclark> anastasiac: You asked about feedback for documentation systems today at standup
[13:45:51 CST(-0600)] <colinclark> Is there any particular feedback you feel like you need from anyone before you can dive in and make a decision?
[13:45:53 CST(-0600)] <anastasiac> yes
[13:46:43 CST(-0600)] <anastasiac> no, nothing in particular. I just want to make sure that anyone interested has the opportunity to add any information they think might help
[13:47:33 CST(-0600)] <anastasiac> for example, experience with one of the systems, questions about the priorities, disagreements with the preliminary evaluation, etc. colinclark
[13:48:18 CST(-0600)] <jamon_> anastasiac: did you have a change to look at ikiwiki?
[13:48:50 CST(-0600)] <anastasiac> jamon_, no - thanks for the reminder! see, that's the kind of feedback I'm looking for 
[13:49:21 CST(-0600)] <jamon> i think that it sits in an interesting place in your grid
[13:50:32 CST(-0600)] <anastasiac> yes, definitely worth looking at further
[14:03:42 CST(-0600)] <Justin_o> colinclark, heidi_ : I've added in a manual test to the FLUID-4023 branch in my github repo https://github.com/jobara/infusion/blob/FLUID-4023/src/webapp/tests/manual-tests/html/fl-fix.html
[14:03:53 CST(-0600)] <colinclark> cool, Justin_o
[14:03:57 CST(-0600)] <Justin_o> this can be used to toggle between the various clear fix options
[14:04:02 CST(-0600)] <heidi_> nice
[14:04:04 CST(-0600)] <jessm> anastasiac: markdown is made by the same group as moveable type?
[14:04:29 CST(-0600)] <jessm> anastasiac: and has it been updated since 2004?
[14:05:09 CST(-0600)] <anastasiac> jessm: yes, and I don't believe so, but not sure
[14:05:40 CST(-0600)] * jessm remembers when moveable type didn't cost $$
[14:09:30 CST(-0600)] <jessm> anastasiac: what are your personal top 3 choices?
[14:10:36 CST(-0600)] <anastasiac> jessm, I'm not sure I've formed that opinion yet. I'm still gathering data.
[14:10:55 CST(-0600)] <anastasiac> I'll say I place a high priority on the ability to have a staging area for editing non-stable docs, separate from the stable docs
[14:11:07 CST(-0600)] <jessm> anastasiac: just tell me right now, w/o data – which 3?
[14:11:09 CST(-0600)] <anastasiac> based on my experience so far managing our docs to-date
[14:11:12 CST(-0600)] <jessm> why the staging area?
[14:11:19 CST(-0600)] <jessm> because it's messy?
[14:11:33 CST(-0600)] <anastasiac> because managing updates to the docs without it is difficult, messy, annoying, time-consuming, error-prone
[14:12:20 CST(-0600)] <colinclark> What are some helpful examples of that messiness, anastasiac?
[14:13:11 CST(-0600)] <anastasiac> the pager tutorial: for 1.3.1, the api changed, so the tutorial had to change, but I didn't want to change the "public" tutorial before the release, or it would have been wrong for the 'current' release
[14:13:36 CST(-0600)] <jessm> anastasiac: ah, right – the "more than versioning" use case
[14:13:45 CST(-0600)] <anastasiac> so I had to duplicate the page, change the name to 'draft', make the changes; then at release, I had to 'swap' the pages, and mark the older one as 'for 1.3 and before'
[14:13:48 CST(-0600)] <anastasiac> right
[14:13:51 CST(-0600)] <anastasiac> that was just one page
[14:14:36 CST(-0600)] <anastasiac> for API docs, we've just been marking individual options/etc as "new in vX.X", which is not as difficult a process, but it gets messier and messier as we go along
[14:15:12 CST(-0600)] <jessm> do we have any hopes of shipping documentation?
[14:15:29 CST(-0600)] <anastasiac> not sure what you mean, jessm?
[14:15:53 CST(-0600)] <jessm> anastasiac: maybe i'm asking a dumb question – any intentions of bundling it and shipping it via github?
[14:16:54 CST(-0600)] <anastasiac> well, it hasn't been raised as a high priority. I did investigate the options for exporting PDF in the wiki table. Whether or not we can do it easily will depend on whatever system we choose.
[14:17:13 CST(-0600)] <anastasiac> if it's a high-priority requirement, jessm, we should take that into account. Till now, it hasn't been
[14:17:23 CST(-0600)] <jessm> nah, just a question
[14:17:37 CST(-0600)] <jessm> anastasiac: i seem to recall in my use of wordpress the ability to tag – am i high?
[14:17:59 CST(-0600)] <anastasiac> jessm, I can't speak to you being high or not, but I believe you can tag in wordpress
[14:18:10 CST(-0600)] <colinclark> yes, you can
[14:18:17 CST(-0600)] <anastasiac> you definitely have categories, I know that
[14:18:20 CST(-0600)] <colinclark> which implies jessm lack of high-ness
[14:18:24 CST(-0600)] <jessm> anastasiac: i'm not high and there's a red X in the tagging box on wordpress
[14:19:02 CST(-0600)] <anastasiac> well, then, I guess my wordpress knowledge is not up-to-date. Remember, this is a sketchy preliminary table. This is exactly why I appreciate the feedback!
[14:19:25 CST(-0600)] <jessm> ok, let's try a bar game in the channel here... everyone grab a quarter and a beer
[14:19:33 CST(-0600)] <jessm> just kidding – just wanted to get your attention...
[14:19:53 CST(-0600)] <jessm> everyone type in their IRC bar the name of one doc platform from the chart
[14:19:55 CST(-0600)] * anastasiac puts her beer away
[14:20:02 CST(-0600)] <jessm> everyone ready?
[14:20:07 CST(-0600)] <jessm> did you type it in?
[14:20:17 CST(-0600)] <jessm> press <enter>
[14:20:22 CST(-0600)] <anastasiac> wordpress
[14:20:27 CST(-0600)] <jessm> wordpress
[14:20:48 CST(-0600)] <jessm> anastasiac: are others drinking beer?
[14:20:58 CST(-0600)] <anastasiac> they didn't hear you
[14:21:05 CST(-0600)] <jessm> hrm
[14:21:05 CST(-0600)] <anastasiac> probably scotch, then
[14:21:35 CST(-0600)] <jessm> my experiment failed
[14:21:43 CST(-0600)] <anastasiac> what were you trying to accomplish?
[14:21:49 CST(-0600)] <jessm> anastasiac: i think wordpress is a fine selection
[14:22:21 CST(-0600)] <jessm> i wanted folks to just let fly what they thought w/o penalty
[14:22:42 CST(-0600)] <jessm> colinclark: are you drinking beer and what do you think of wordpress?
[14:22:48 CST(-0600)] <anastasiac> it's definitely worthy of deeper experimentation, but I wouldn't say settle on it yet. The process of converting the database to HTML involves some work, and we don't yet know quite what that will be like
[14:22:49 CST(-0600)] <jessm> Justin_o: beer or wordpress?
[14:23:28 CST(-0600)] <colinclark> man, i'm too wasted to type
[14:23:34 CST(-0600)] <colinclark> let me catch up
[14:23:39 CST(-0600)] <colinclark> out of context, this game is confusing
[14:23:59 CST(-0600)] <jessm> anastasiac: converting what DB to HTML?
[14:24:03 CST(-0600)] <colinclark> okay, so I could type in a name
[14:24:16 CST(-0600)] <colinclark> would it imply my interest in it, if I did?
[14:24:19 CST(-0600)] <colinclark> jessm: ^
[14:24:37 CST(-0600)] <jessm> it implies only that you were asked to type in one name that you thought might be nice and that's it
[14:24:50 CST(-0600)] <jessm> from the list
[14:24:55 CST(-0600)] <anastasiac> jessm: the WordPress plan involves using wordpress as the staging area, then using an XSLT to transform the content of the WordPress database into static HTML at release time, for the stable docs coinciding with the release
[14:24:56 CST(-0600)] <colinclark> ah
[14:24:59 CST(-0600)] <colinclark> i'm going to cheat
[14:25:05 CST(-0600)] <colinclark> Here goes, beer and all
[14:25:10 CST(-0600)] <colinclark> MindTouch
[14:25:12 CST(-0600)] <colinclark> WordPress
[14:26:14 CST(-0600)] <jessm> anastasiac: and we'd create the XSLT?
[14:26:19 CST(-0600)] <anastasiac> so I'd agree that those two are on the short list. My plan for the short list is to actually set them up, try them out: create some typical pages, try the full process, explore the capabilities on an actual system
[14:26:30 CST(-0600)] <anastasiac> jessm, yes, we'd have to create that XSLT - not a small task
[14:26:36 CST(-0600)] <jessm> anastasiac: bleh
[14:26:40 CST(-0600)] <Justin_o> jessm: i have a bit more experience with wordpress than i do with beer, so i'll have to pick wordpress
[14:26:58 CST(-0600)] <jessm> Justin_o: a fine approach to the game!
[14:27:29 CST(-0600)] <jessm> anastasiac: i think the set these two up and try 'em out sounds good
[14:27:30 CST(-0600)] <anastasiac> it is attractive: offers both community editing and stable docs. There's just an up-front workload of setting up the conversion process
[14:27:44 CST(-0600)] <jessm> is it just me or is XSLT like eating chocolate and then drinking beer?
[14:28:05 CST(-0600)] <jessm> complicated XSLTs make me want to cry
[14:28:17 CST(-0600)] <anastasiac> chocolate and beer makes you want to cry???
[14:28:19 CST(-0600)] <anastasiac> why??
[14:28:20 CST(-0600)] <Justin_o> jessm, anastasiac: i'm a bit interested in markdown, since it might be easier to ship if that's what we decide
[14:28:24 CST(-0600)] <Justin_o> since it will already be in git
[14:28:29 CST(-0600)] <colinclark> why XSLT, anastasiac?
[14:28:35 CST(-0600)] <Justin_o> anastasiac: by the way, have you looked at the wiki on github?
[14:28:47 CST(-0600)] * anastasiac digs through her notes
[14:29:01 CST(-0600)] <anastasiac> and Justin_o, I don't quite know what you mean
[14:29:04 CST(-0600)] <jessm> Justin_o: did we have any intentions of shipping docs?
[14:29:56 CST(-0600)] <anastasiac> colinclark: the wordpress DB is XML - so XSLT to produce HTML
[14:30:36 CST(-0600)] <jessm> anastasiac: i'm not into big, ugly XSLTs nor eating chocolate with beer
[14:30:50 CST(-0600)] <Justin_o> jessm: not sure... we do
[14:30:58 CST(-0600)] <anastasiac> jessm, you clearly haven't tried the right chocolate with the right beer
[14:31:07 CST(-0600)] <jessm> clearly
[14:31:18 CST(-0600)] <colinclark> anastasiac: Are there examples of other similar XSLTs that do this sort of thing for WordPress?
[14:31:20 CST(-0600)] <colinclark> I'd love to check it out
[14:31:26 CST(-0600)] <jessm> anastasiac: wordpress itself is in HTML
[14:31:29 CST(-0600)] <Justin_o> jessm: that last comment from me was confusing.. i don't know if we plan to ship the docs, but if we ever do.. it would may be easier
[14:31:51 CST(-0600)] <Justin_o> anastasiac: github also has there own wiki, i just turned it off for ours
[14:31:57 CST(-0600)] <colinclark> anastasiac: On the topic of my other beer, did Janet or Sheppy have any helpful comments on MindTouch?
[14:32:03 CST(-0600)] <anastasiac> colinclark, the wordpress-xslt scheme is what jQuery uses. They wrote their own xslt. They sent me some info, I'll pass it on
[14:32:18 CST(-0600)] <colinclark> Who's they?
[14:32:20 CST(-0600)] <anastasiac> sheppy did give me some comments on MindTouch
[14:32:40 CST(-0600)] <anastasiac> sorry: they = my jQuery docs contact - I can get his name/email, if you like
[14:32:57 CST(-0600)] <colinclark> Is there a wiki page where you've posted all these interesting documentation correspondences?
[14:33:04 CST(-0600)] <colinclark> I had no idea--sounds like a goldmine of interesting information
[14:33:17 CST(-0600)] <anastasiac> colinclark, jessm, I have a 3:30 meeting I'm late for...
[14:33:38 CST(-0600)] <anastasiac> do continue to discuss - the channel is logged
[14:33:49 CST(-0600)] <colinclark> how unsatisfying
[14:33:55 CST(-0600)] <colinclark> talking to a robot
[14:34:04 CST(-0600)] <anastasiac> sorry about that
[14:34:09 CST(-0600)] <anastasiac> we can continue after my meeting...
[14:35:09 CST(-0600)] <colinclark> When's that?
[14:47:14 CST(-0600)] <cindyli> hi, colinclark, mlam, Justin_o, with the new image gallery demo, i've reached a point that i cannot proceed until the issue we talked earlier about the server response being able to retrieved in onFileSuccess and onFileFail is done. The pieces around this part have been finished, hopefully.... It would be nice if someone can look at what i've done so far giving some suggestions, verifying if i'm on the right track. would be nicer if someone can review the
[14:49:26 CST(-0600)] <colinclark> cindyli: Do you have a Github repo with the new code in it?
[14:49:44 CST(-0600)] <cindyli> colinclark: no, everything on localhost
[14:50:07 CST(-0600)] <colinclark> Post it on Github, and I'll be happy to take a look
[14:50:13 CST(-0600)] <colinclark> Do you know how to do this with git?
[14:50:30 CST(-0600)] <cindyli> colinclark: ok. not yet, will find out, opportunity to learn git
[14:50:33 CST(-0600)] <cindyli>
[14:50:36 CST(-0600)] <colinclark> cool
[14:50:45 CST(-0600)] <colinclark> michelled or Justin_o can probably offer some advice
[14:50:55 CST(-0600)] <colinclark> It's pretty straightforward...
[14:51:15 CST(-0600)] <colinclark> you'll need to use "git init" to initialize a new git repo in your local copy of the code
[14:51:25 CST(-0600)] <colinclark> and Github has a "new repository" feature that will create a new, empty repo
[14:51:34 CST(-0600)] <cindyli> ok
[14:51:39 CST(-0600)] <cindyli> thx
[14:51:48 CST(-0600)] <colinclark> and then, roughly, you just need to commit your changes and then push your local master up to your Github repo
[14:52:08 CST(-0600)] <cindyli> ic
[14:52:33 CST(-0600)] <mlam> cindyli: I can change the onFileSuccess and onFileError event function signatures soon for you
[14:52:52 CST(-0600)] <cindyli> mlam: that would be great. THANKS!
[14:53:40 CST(-0600)] <mlam> I'm just fixing up some errorHandler test cases and then I'll to get it
[15:20:10 CST(-0600)] <golam> michelled: here are my changes https://github.com/gchowdhury/infusion/commit/89019d76e4f484aa9f3d9e12d7adf3734605aa4a
[15:23:14 CST(-0600)] <michelled> thanks golam
[15:26:33 CST(-0600)] <mlam> colinclark: for the onFileSuccess event, you found that SWFUpload returns the file itself and the image gallery returns the file's ID as serverData. What do you think is appropriate serverData? Should we maintain consistency and return the file's ID?
[15:26:55 CST(-0600)] <colinclark> The serverData should be whatever the server returns
[15:26:59 CST(-0600)] <colinclark> It's not something we control at all
[15:27:21 CST(-0600)] <colinclark> cindyli, for example, is planning to return a URL from her server
[15:31:13 CST(-0600)] <mlam> so in the HTML5 strategy, we would be returning the XHR status?
[15:33:55 CST(-0600)] <colinclark> I think you probably want the responseText, rather than the status
[15:35:17 CST(-0600)] <mlam> ok
[15:36:24 CST(-0600)] <cindyli> colinclark: pushed the demo into github: https://github.com/cindyli/image-gallery
[15:36:30 CST(-0600)] <colinclark> cool
[15:38:59 CST(-0600)] <anastasiac> colinclark, fyi, my meeting is over now
[15:39:19 CST(-0600)] <colinclark> I forget where we were
[15:39:30 CST(-0600)] <colinclark> I spent some time on the MindTouch website this afternoon
[15:39:39 CST(-0600)] <colinclark> It seems like they've gone through a slightly creepy rebranding
[15:39:45 CST(-0600)] <anastasiac> and what was your impression?
[15:40:02 CST(-0600)] <colinclark> from having been more openly an "open source company" to sort of burying the open source version in favour of their commercial products
[15:40:14 CST(-0600)] <colinclark> I don't really see that as a show stopper, but it is interesting
[15:40:30 CST(-0600)] <colinclark> I also don't know if there are any downsides to a .NET-based code base
[15:40:30 CST(-0600)] <anastasiac> exactly -I find it confusing to figure out which product is the open source one
[15:40:46 CST(-0600)] <colinclark> Certainly deployment on Mono isn't a big deal for most server platforms
[15:40:56 CST(-0600)] <colinclark> but it strikes me as a slightly obscure choice
[15:41:12 CST(-0600)] <colinclark> I'd love to see an instance of it that we can play around with
[15:41:27 CST(-0600)] <anastasiac> for a product geared toward documentation, I find their documentation to be poor
[15:41:35 CST(-0600)] <colinclark> I guess those two, MindTouch and WordPress, lead it up for me
[15:41:42 CST(-0600)] <colinclark> with MediaWiki trailing in third
[15:41:51 CST(-0600)] <colinclark> MediaWiki is one of those things...
[15:42:05 CST(-0600)] <colinclark> it's pretty non-ideal, but it's also quite ubiquitous
[15:42:24 CST(-0600)] <colinclark> The whole XML/XSLT thing with WordPress is all a bit of a surprise to me
[15:42:38 CST(-0600)] <colinclark> I wonder why you made this chart, but didn't really share any of the insights you got from communities
[15:42:58 CST(-0600)] <colinclark> Perhaps I'm imagining it, but it seems like there might be some useful information in there
[15:43:29 CST(-0600)] <anastasiac> I can certainly put stuff together into something presentable
[15:43:44 CST(-0600)] <colinclark> My sense from looking briefly at Ikiwiki is that it probably doesn't have the polish of user experience and features we'd want
[15:43:57 CST(-0600)] <colinclark> The delegated version control is a nice technical touch
[15:44:01 CST(-0600)] <anastasiac> that's my first impression, too
[15:44:06 CST(-0600)] <colinclark> but it's very much a classic style wiki
[15:44:18 CST(-0600)] <colinclark> for technical folk
[15:44:57 CST(-0600)] <colinclark> The biggest flag I see in all of this is the WordPress XSLT conversion process
[15:45:06 CST(-0600)] <colinclark> without knowing what other people do, how involved it will be, etc.
[15:45:11 CST(-0600)] <colinclark> it's hard to know if it's really a viable option or not
[15:45:30 CST(-0600)] <anastasiac> yes, that's my feeling, too - I'd want to try it out before committing, at least in simple form
[15:45:45 CST(-0600)] <colinclark> So, this is one of those decisions...
[15:45:49 CST(-0600)] <colinclark> I'm glad you're being scientific about it
[15:45:53 CST(-0600)] <colinclark> Good to have pros and cons and the like
[15:46:05 CST(-0600)] <colinclark> We could spend our lives trying to gather data
[15:46:11 CST(-0600)] <colinclark> but you might also want to listen to your gut
[15:46:31 CST(-0600)] <colinclark> given your experience over the past while with Confluence, etc.
[15:47:15 CST(-0600)] <colinclark> I was puzzled by your comment earlier about WordPress' database being XML...
[15:47:27 CST(-0600)] <colinclark> last I looked it was a MySQL relational thingy
[15:48:00 CST(-0600)] <anastasiac> I'm not actually familiar with the internals yet, I'm going by what jQuery told me - that's why I'd want to investigate further, because I don't have all the details yet
[15:48:03 CST(-0600)] <colinclark> but perhaps there's some XML under the covers there
[15:48:07 CST(-0600)] <anastasiac> but I agree with going with your gut
[15:48:21 CST(-0600)] <anastasiac> at least to narrow it down to a couple of pilots
[15:49:57 CST(-0600)] <anastasiac> I can certainly contact the jQuery docs guy (his name is Karl Swedberg) to follow up with more questions - he was quite helpful
[15:51:07 CST(-0600)] <colinclark> I know Karl
[15:51:09 CST(-0600)] <colinclark> He's really, really nice
[15:51:20 CST(-0600)] <colinclark> He wrote one of the first books on jQuery
[15:52:03 CST(-0600)] <colinclark> anastasiac: Seems like your next step is to get that feedback into a form that you can share it with our community
[15:52:18 CST(-0600)] <anastasiac> yep
[15:52:22 CST(-0600)] <colinclark> With more information, people are likely in a better position to give you feedback
[15:53:51 CST(-0600)] <colinclark> And then I imagine it might make sense to get instances of MindTouch and WordPress (with any plugins or XSLT workflow we'll need) up and running to experiment with
[15:54:00 CST(-0600)] <anastasiac> right
[15:54:03 CST(-0600)] <colinclark> it'd be nice to decide on this sooner rather than later
[15:54:11 CST(-0600)] <colinclark> This is one of those things that could drag on
[15:54:17 CST(-0600)] <colinclark> you'll know
[15:54:22 CST(-0600)] <colinclark>
[15:54:42 CST(-0600)] <mlam> colinclark: I've created a branch with the changes needed to synchronize the HTML5 onFileSuccess and onFileError event function signatures with SWFUpload: https://github.com/mlam/infusion/commits/FLUID-4134
[15:54:54 CST(-0600)] <anastasiac> yes, definitely - sooner than later. with the push to rework all the websites, demos, etc., the less we do in confluence, the less we have to port over
[15:55:36 CST(-0600)] <colinclark> mlam: Have you tried it out with the server?
[15:56:27 CST(-0600)] <colinclark> mlam: So, I can see you wore your Java Mind while writing this code
[15:56:31 CST(-0600)] <mlam> yes, I have. I passed in the response Text for the onFileSuccess. With the onFileError, I passed in a generic error message that is hard-coded.
[15:56:42 CST(-0600)] <colinclark> cool!
[15:56:54 CST(-0600)] <mlam> It's been impossible to escape OO thinking 
[15:56:56 CST(-0600)] <colinclark> So, the changes you made to Uploader.js are interesting...
[15:57:17 CST(-0600)] <colinclark> Take a look at line 263 and 272
[15:57:34 CST(-0600)] <colinclark> You modified the signature of Uploader's onFileSuccess and onFileError listeners
[15:57:41 CST(-0600)] <colinclark> How come?
[15:58:14 CST(-0600)] <colinclark> I might be missing it, but it doesn't look like you actually use these arguments you added
[15:58:41 CST(-0600)] <mlam> If it's part of SWFUpload's API, I thought it would be best if we followed the function signatures to avoid further confusion between the 2 strategies
[15:58:49 CST(-0600)] <colinclark> It's interesting, though
[15:58:56 CST(-0600)] <colinclark> Uploader.js is, in a sense, "user code"
[15:59:14 CST(-0600)] <colinclark> In other words, those functions you changed are listening for the event, not firing the event
[15:59:30 CST(-0600)] <colinclark> Unlike in Java, argument lists aren't fixed in JavaScript
[15:59:49 CST(-0600)] <mlam> No, you didn't miss it. I'm just not sure what to do with the serverData and the error message. If we're not rendering this information or using this information to render specific data, then I'm not sure what do with it yet.
[16:00:08 CST(-0600)] <colinclark> Well, that's the thing
[16:00:12 CST(-0600)] <colinclark> We're not doing anything with it
[16:00:23 CST(-0600)] <colinclark> But our users' listeners might want to do something with it
[16:00:52 CST(-0600)] <colinclark> So, if you want, you can give a function fewer named arguments than the calling code provides
[16:01:00 CST(-0600)] <colinclark> meaning, it's perfectly legitimate to write a listener like this:
[16:01:22 CST(-0600)]
[16:01:24 CST(-0600)] <colinclark> or
[16:01:38 CST(-0600)]
[16:01:40 CST(-0600)] <colinclark> or whatever
[16:01:56 CST(-0600)] <colinclark> In Cindy's case, she'll create a listener that matches the full signature
[16:02:27 CST(-0600)]
[16:02:46 CST(-0600)] <mlam> I thought if you provide more arguments than the function signature allows, then those additional arguments just get ignored.
[16:02:51 CST(-0600)] <colinclark> They do
[16:02:59 CST(-0600)] <colinclark> but why include them, only to ignore them?
[16:03:20 CST(-0600)] <colinclark> In Java, you'd have to include them--the type system would require it
[16:03:23 CST(-0600)] <colinclark> but here, it's your choice
[16:03:28 CST(-0600)] <colinclark> include them if you use them, don't if you don't
[16:05:10 CST(-0600)] <mlam> I see. so in our case (without the cindy's new image gallery), we don't need to change the argument list at all and i can leave them the way they were. And when I'm firing the event , I provide the full list of arguments in case a new listener is created to match the full signature?
[16:05:32 CST(-0600)] <colinclark> Yep
[16:05:46 CST(-0600)] <colinclark> So, it's just as you say...
[16:06:01 CST(-0600)] <colinclark> The Uploader itself doesn't need this extra argument (at least, for now it doesn't)
[16:06:12 CST(-0600)] <colinclark> But Cindy's Image Gallery will want to it
[16:06:22 CST(-0600)] <colinclark> She can include the extra arguments in her signature, and she'll get them
[16:06:25 CST(-0600)] <mlam> I see I see. It's all making more sense now
[16:06:28 CST(-0600)] <colinclark> Cool
[16:06:33 CST(-0600)] <colinclark> So, one other thing...
[16:06:41 CST(-0600)] <colinclark> I wonder if our semantics match
[16:06:55 CST(-0600)] <colinclark> In SWFUpload, in the case of an error, I get the HTTP response code as a string
[16:07:00 CST(-0600)] <colinclark> I'm not sure I really want it, but that's what I get
[16:07:17 CST(-0600)] <colinclark> Whereas in your HTML5 strategy code, you're giving a human-readable message
[16:07:54 CST(-0600)] <colinclark> This is what I found when I encountered a file error in SWFUpload:
[16:07:57 CST(-0600)] <colinclark> [13:26:03 CST(-0600)] <colinclark> 1. The File object, 2. An error code of -200, which is SWFUpload's HTTP_ERROR, and 3. The HTTP response code as a String, in this case "500"
[16:08:19 CST(-0600)] <colinclark> I have no idea why the value is a string
[16:08:26 CST(-0600)] <colinclark> I guess it's pretty useful to have an HTTP response code
[16:08:39 CST(-0600)] <colinclark> Then we know if, for example, we tried to POST the file to an invalid URL, or whatever
[16:09:01 CST(-0600)] <colinclark> Whereas the human-readable message is probably not terribly useful
[16:09:07 CST(-0600)] <colinclark> since it would need to be localized anyway
[16:09:15 CST(-0600)] <colinclark> I don't know... does that seem reasonable?
[16:09:19 CST(-0600)] <colinclark> I might be missing something
[16:10:19 CST(-0600)] <mlam> Yah, it seems reasonable. There's a weird situation though when we're stopping the upload. Nothing's really broken, so I"m not expecting an HTTP response code in this situation
[16:10:34 CST(-0600)] <mlam> I'll have to test tomorrow to see if we do get an error code from stopping an upload to be sure
[16:11:14 CST(-0600)] <colinclark> make sense
[16:11:23 CST(-0600)] <colinclark> you're right, there really isn't a sensible HTTP code for that case
[16:13:45 CST(-0600)] <colinclark> mlam: We also talked about the prospect of passing along the XHR as an "implementation-specific extra argument" for both onFileError and onFileSuccess
[16:14:36 CST(-0600)] <mlam> to be shipped by default?
[16:15:16 CST(-0600)] <colinclark> I would
[16:15:20 CST(-0600)] <mlam> I guess it's another step towards eliminating Flash
[16:15:26 CST(-0600)] <colinclark> Can't see any reason why it's a bad idea
[16:15:35 CST(-0600)] <colinclark> For HTML5-only users, it'll be helpful
[16:15:40 CST(-0600)] <mlam> Yes
[16:15:52 CST(-0600)] <colinclark> and once we get rid of Flash fully, it'll just be a standard part of the API
[16:16:05 CST(-0600)] <mlam> That makes good sense to me
[16:16:11 CST(-0600)] <colinclark> Cool
[16:16:32 CST(-0600)] <mlam> Shall I make that change then?
[16:19:05 CST(-0600)] <colinclark> Yep, make those changes and then make a pull request
[16:19:10 CST(-0600)] <colinclark> and I'll get it into the project repo
[16:32:29 CST(-0600)] <mlam> ok, cool
[16:35:01 CST(-0600)] <mlam> colinclark: i have to head out. I'll make those changes first thing tomorrow morning and get them up on github
[16:35:07 CST(-0600)] <colinclark> sure, no rush
Unknown macro: { outline}
Unknown macro: {outline}
Unknown macro: { // No arguments, because we do nothing. }
Unknown macro: { // Only a file argument, because that's all we use. }
Unknown macro: { // Do something with serverData }
Manage space
Manage content
Integrations