fluid-work IRC Logs-2011-03-25

[08:37:16 CDT(-0500)] <cindyli> Justin_o: cannot access wiki. have to stop the doc updating. what else can i help with
[08:37:48 CDT(-0500)] <cindyli> Justin_o: one sec, seems wiki is back again. ignore my question pls
[08:38:51 CDT(-0500)] <Justin_o> fluid-everyone: wiki seems to be back up
[08:39:18 CDT(-0500)] <anastasiac> Justin_o, great! good to hear...
[08:42:20 CDT(-0500)] <heidi_> works for me too
[08:42:51 CDT(-0500)] <anastasiac> jamon, whatever you did to fix the network, thanks!
[08:44:10 CDT(-0500)] <jamon> hey all, so it turns out both our nameservers ran out of memory last night, separately at different times
[08:45:37 CDT(-0500)] <jamon> thankfully our sites were all still resolvable via our third nameserver for outside connections
[08:54:45 CDT(-0500)] <anastasiac> wow, odd, jamon
[09:16:38 CDT(-0500)] <jameswy> fluid-everyone: anyone know where jessm is today?
[09:33:29 CDT(-0500)] <heidi_> anastasiac can the dom binder be defined in one or two sentences? i'm having trouble. it's a way for a component to quickly locate elements in the DOM?
[09:33:47 CDT(-0500)] * anastasiac ponders
[09:34:25 CDT(-0500)] <heidi_> reading http://wiki.fluidproject.org/display/fluid/DOM+Binder but hmm
[09:35:07 CDT(-0500)] <harriswong> anastasiac: i notice pager pageSize is already done on this page: http://wiki.fluidproject.org/display/fluid/Pager+Tutorial
[09:35:10 CDT(-0500)] <heidi_> also it says it comes with initView but ... renderer too?
[09:35:16 CDT(-0500)] <harriswong> anastasiac: under "model" header
[09:35:28 CDT(-0500)] <anastasiac> heidi_, I think your summary is pretty good, actually, but I might add the fact that they're named elements: A dome binder allows components to quickly locate named elements in the DOM
[09:35:52 CDT(-0500)] <heidi_> and by named ... class name or id ?
[09:35:58 CDT(-0500)] <anastasiac> heidi_, if you mean "does it come with renderer components?" then yes, it does
[09:36:07 CDT(-0500)] <mlam> anastasiac: are there any documentation topics that haven't been accounted for yet?
[09:36:11 CDT(-0500)] <anastasiac> named means named in the "selectors" defaults block i.e. NOT by class name or id
[09:36:14 CDT(-0500)] <harriswong> anastasiac: for FAQ: "Pager: How to set initial page size"
[09:36:22 CDT(-0500)] <heidi_> anastasiac aha...
[09:36:24 CDT(-0500)] <heidi_> thanks
[09:36:25 CDT(-0500)] <anastasiac> mlam, sure - there are LOTS!
[09:36:46 CDT(-0500)] <mlam> which do you suggest?
[09:37:47 CDT(-0500)] <anastasiac> mlam, if you have any understanding of some of the new framework features, in particular the IoC related ones, we're lacking in docs there
[09:38:29 CDT(-0500)] <anastasiac> I know Bosmon2 has his name next to a few on the planning page - you could check in with him if there's anything you think you could help with, mlam
[09:38:41 CDT(-0500)] <anastasiac> or write up something else
[09:39:00 CDT(-0500)] <anastasiac> mlam, for ideas, you could look at the docs architecture plans: http://wiki.fluidproject.org/display/fluid/Documentation+Architecture+-+Round+2
[09:39:13 CDT(-0500)] <anastasiac> any of the boxes in those diagrams need a page
[09:39:13 CDT(-0500)] <mlam> Ok, I think I'll try to find something non-framework related. I think it's better that Bosmon2 handle the framework docs
[09:39:43 CDT(-0500)] <anastasiac> mlam, do you know anything about renderer cutpoints?
[09:39:59 CDT(-0500)] <anastasiac> or the fluid.selfRender function? or fluid.reRender?
[09:40:05 CDT(-0500)] <mlam> No, I don't, but i can learn Is there already a starter page?
[09:40:26 CDT(-0500)] <mlam> No, I haven't used either of the functions yet
[09:40:28 CDT(-0500)] <anastasiac> actually, yes, all three of those have a start - linked to from the sprint planning page
[09:40:51 CDT(-0500)] <anastasiac> mlam: http://wiki.fluidproject.org/display/docs/Cutpoints
[09:41:07 CDT(-0500)] <heidi_> anastasiac looks like we don't have a general page about selectors http://wiki.fluidproject.org/display/fluid/Selectors
[09:41:11 CDT(-0500)] <heidi_> yet
[09:41:42 CDT(-0500)] <mlam> anastasiac: weird, I don't have permission to view the setRender and reRender pages
[09:41:46 CDT(-0500)] <anastasiac> heidi_, good point - it's one of the basic concepts that we want to explain in the docs
[09:41:51 CDT(-0500)] <anastasiac> mlam, odd: I'll look into that
[09:41:57 CDT(-0500)] <mlam> Thanks anastasiac, looking at the cutpoints page now
[09:45:42 CDT(-0500)] <anastasiac> ok, mlam, you should have permissions to edit in the new space now
[09:45:50 CDT(-0500)] <mlam> thanks!
[09:48:33 CDT(-0500)] <harriswong> anastasiac: ping
[09:48:40 CDT(-0500)] <anastasiac> harriswong, pong
[09:48:48 CDT(-0500)] <harriswong> anastasiac: ^
[09:49:38 CDT(-0500)] <anastasiac> harriswong, sorry - multitasking. I missed that. yes, if you'd like to work on that, that would be great!
[09:51:32 CDT(-0500)] <harriswong> anastasiac: where do I post answers to the FAQ?
[09:51:49 CDT(-0500)] <anastasiac> harriswong, we don't have a faq yet
[09:52:24 CDT(-0500)] <anastasiac> I'd suggest you start a new page for the question, call it "How do I set the page size in Pager?" or something like that
[09:52:47 CDT(-0500)] <harriswong> anastasiac: okay.
[09:55:27 CDT(-0500)] <harriswong> anastasiac: should i make a general FAQ page or a new page for every FAQ question?
[09:56:03 CDT(-0500)] <anastasiac> harriswong, for now, go ahead and start a page for each question. Eventually that's how it will be organized. We can create a parent FAQ page linking to them
[09:56:16 CDT(-0500)] <harriswong> anastasiac: got it!
[09:56:21 CDT(-0500)] <anastasiac> thanks
[10:02:52 CDT(-0500)] <heidi_> anastasiac do we have a page that explains all the option possibilities? i.e. selectors, styles, events, strings, etc etc... or does that even make sense? it's specific to the component? tho there seems to be some consistent ones
[10:03:19 CDT(-0500)] <heidi_> i guess a page that explains how options work
[10:03:47 CDT(-0500)] <anastasiac> heidi_, no, we don't, and it's something we need. Each component API page now lists the available options, but there are some consistencies across all component, like selectors, etc. and those could be explained on their own.
[10:03:57 CDT(-0500)] <anastasiac> also yes, a general page about options
[10:04:02 CDT(-0500)] <heidi_> ok
[10:04:06 CDT(-0500)] <anastasiac> michelled is working on improving the options merging docs
[10:04:32 CDT(-0500)] <anastasiac> it's possible that a basic explanation of options and what they're for would be appropriate there
[10:04:37 CDT(-0500)] <anastasiac> or at least associated with it
[10:05:03 CDT(-0500)] <anastasiac> heidi_: http://wiki.fluidproject.org/display/fluid/Options+Merging+for+Fluid+Components
[10:05:14 CDT(-0500)] <anastasiac> not sure how far michelled has got with this page
[10:05:18 CDT(-0500)] <heidi_> interesting, ok
[10:05:28 CDT(-0500)] <michelled> not far at all
[10:05:42 CDT(-0500)] <michelled> I've discovered how far away I've been from all the code so I've been reading code
[10:05:52 CDT(-0500)] <anastasiac> excellent!
[10:05:55 CDT(-0500)] <michelled> I will write that page anastasiac, but I intend to understand what I'm writing first
[10:06:00 CDT(-0500)] <heidi_> i think a high level what are options and how they work would be great
[10:06:19 CDT(-0500)] <anastasiac> heidi_, I agree - do you think you could write something up?
[10:06:28 CDT(-0500)] <anastasiac> the purpose, general idea, etc?
[10:06:45 CDT(-0500)] <heidi_> anastasiac yeah thinking about adding something general to this introy page
[10:06:50 CDT(-0500)] <anastasiac> perfect
[10:16:07 CDT(-0500)] <cindyli> mlam: trying to update "uploader api" with the new parameter sets for onFileSuccess & onFileError. however, i don't really know what the "status" in onFileError means. can you complement? pls also correct me if anything else i understand wrongly
[10:16:44 CDT(-0500)] <mlam> cindyli: i'm taking a look now
[10:16:53 CDT(-0500)] <cindyli> mlam: thx
[10:17:03 CDT(-0500)] <cindyli> anastasiac: done with updating uploader doc. what else can i help with?
[10:18:12 CDT(-0500)] <anastasiac> cindyli, yesterday you mentioned the test plan for the image gallery, I wonder if Justin_o would appreciate that help?
[10:18:38 CDT(-0500)] <Justin_o> anastasiac, cindyli: yes i would
[10:18:55 CDT(-0500)] <cindyli> great, i will go ahead with it
[10:18:59 CDT(-0500)] <mlam> cindyli: status of the uploader is the current state of the uploader. ie. is the uploader uploading? has the uploader finished, etc
[10:19:31 CDT(-0500)] <cindyli> mlam: ok, do u want me to update or u r doing it?
[10:20:23 CDT(-0500)] <mlam> also, cindyli with the onFileSuccess and onFileError arguments, we're not actually shipping onFileSuccess with the responseText and xhr , and the onFileError with error, status, and xhr
[10:20:50 CDT(-0500)] <cindyli> mlam: ?
[10:20:54 CDT(-0500)] <mlam> the onFileSuccess and onFileError event listeners only take in a file as an argument by default
[10:21:18 CDT(-0500)] <cindyli> i'm confused
[10:21:21 CDT(-0500)] <mlam> the additional parameters are there for the implementer's use in case they need them
[10:21:37 CDT(-0500)] <cindyli> ok, optional
[10:21:40 CDT(-0500)] <mlam> but are not shipped by default in our own uploader
[10:24:51 CDT(-0500)] <Justin_o> michelled, anastasiac: here are the two git pages i've been working on http://wiki.fluidproject.org/display/fluid/GIT+Tips+and+Tricks http://wiki.fluidproject.org/display/fluid/Github+Tips+and+Tricks
[10:24:56 CDT(-0500)] <Justin_o> anything else needed?
[10:25:15 CDT(-0500)] <anastasiac> Justin_o, there's always more needed
[10:25:17 CDT(-0500)] <Justin_o> There's not much covered on the github page, as their help page covers most things
[10:25:25 CDT(-0500)] <anastasiac> oh, you mean with git...
[10:25:30 CDT(-0500)] <Justin_o> yes..
[10:25:51 CDT(-0500)] <anastasiac> I'll have a look
[10:40:07 CDT(-0500)] <bhavya> Hello everyone
[10:40:19 CDT(-0500)] <bhavya> Hi jessm
[10:40:39 CDT(-0500)] <bhavya> can I talk to michelleright now
[10:44:53 CDT(-0500)] <mlam> cindyli: i misunderstood your question about the status. so to clarify and correct myself, the status is the current status of the XHR object.
[10:45:12 CDT(-0500)] <cindyli> mlam: thx mike
[10:46:23 CDT(-0500)] <Justin_o> bhavya: hello... michelled is away at the moment, but should be back shortly
[10:47:44 CDT(-0500)] <bhavya> sure thanks
[10:53:14 CDT(-0500)] <michelled_> I'm back now bhavya
[10:53:18 CDT(-0500)] <bhavya> gr8
[10:53:32 CDT(-0500)] <bhavya> I saw your work on the link u gave
[10:53:57 CDT(-0500)] <bhavya> I wanted to tell you that I am not that good with javascript and php
[10:54:07 CDT(-0500)] <bhavya> although I know them
[10:54:15 CDT(-0500)] <bhavya> I never did a major project
[10:54:19 CDT(-0500)] <bhavya> on them
[10:54:34 CDT(-0500)] <michelled_> thanks for letting me know that.
[10:54:41 CDT(-0500)] <bhavya> but I am on a sem break due to this intern I am on
[10:54:56 CDT(-0500)] <bhavya> and I do not have any commitments for next 5 months
[10:55:10 CDT(-0500)] <michelled_> if you're interested in learning javascript I'd suggest watching Douglas Crockford's javascript videos
[10:55:20 CDT(-0500)] <bhavya> ok
[10:55:30 CDT(-0500)] <michelled_> Fluid uses the subset of javascript that Crockford dubs "The Good Parts"
[10:55:38 CDT(-0500)] <michelled_> he's also got a book which is very good
[10:55:41 CDT(-0500)] <bhavya> ok
[10:55:46 CDT(-0500)] <michelled_> called "The Good Parts"
[10:55:51 CDT(-0500)] <michelled_> most of our work is in javascript
[10:56:20 CDT(-0500)] <bhavya> so can I still apply (I am completely free )
[10:56:26 CDT(-0500)] <bhavya> and I am keen to learn it
[10:57:32 CDT(-0500)] <jessm> bhavya: you'll have to meet the application requirements for GSoC – we don't determine eligibility, they do
[10:58:00 CDT(-0500)] <bhavya> well I am eligible according to them
[10:58:20 CDT(-0500)] <jessm> bhavya: excellent
[10:58:59 CDT(-0500)] <bhavya> gr8 so i'll apply then
[10:59:07 CDT(-0500)] <michelled_> cool
[10:59:09 CDT(-0500)] <bhavya> I have already mailed my codes
[10:59:20 CDT(-0500)] <bhavya> hope u'll like them
[10:59:35 CDT(-0500)] <michelled_> here's an old presentation that we gave about writing javascript: http://wiki.fluidproject.org/display/fluid/Fearless+JavaScript+1.0
[10:59:48 CDT(-0500)] <michelled_> the intended audience was developers who are comfortable in other languages
[10:59:58 CDT(-0500)] <bhavya> niceeee
[11:00:04 CDT(-0500)] <michelled_> I think it's still got a lot of relevant information
[11:00:14 CDT(-0500)] <bhavya> i'll go through it over this weekend
[11:00:17 CDT(-0500)] <bhavya> thanks!
[11:00:24 CDT(-0500)] <bhavya>
[11:00:32 CDT(-0500)] <michelled_> no problem!
[11:00:47 CDT(-0500)] <michelled_> feel free to ask any questions you have about javascript or how we use it in here
[11:00:54 CDT(-0500)] <bhavya> sure...
[11:00:56 CDT(-0500)] <michelled_> people are always willing to answer
[11:01:18 CDT(-0500)] <bhavya> well that's the beauty of FOSS community
[11:01:21 CDT(-0500)] <michelled_>
[11:01:38 CDT(-0500)] <michelled_> colinclark is the tech lead of the project - you should see him in here a fair bit
[11:01:51 CDT(-0500)] <bhavya> ok
[11:01:57 CDT(-0500)] <michelled_> Bozmon - also known as Antranig is the main framework developer
[11:02:11 CDT(-0500)] <bhavya> i'll talk to him then
[11:02:26 CDT(-0500)] <michelled_> Justin_o is the QA lead but we usually call him the King as he does a lot of community leadership
[11:02:53 CDT(-0500)] <michelled_> but as I said, lots of folks will be happy to answer questions
[11:03:34 CDT(-0500)] <bhavya> well thanks a lot
[11:03:49 CDT(-0500)] <bhavya> i'll post you a proposal after this weekend then
[11:04:03 CDT(-0500)] <michelled_> sounds good
[11:04:52 CDT(-0500)] <harriswong> anastsaic: I have finished the 2 pager FAQ, should i work on the other FAQs?
[11:05:19 CDT(-0500)] <harriswong> anastasiac* ^
[11:05:45 CDT(-0500)] <anastasiac> harriswong, sure, that would be great!
[11:05:47 CDT(-0500)] <anastasiac> thanks
[11:07:10 CDT(-0500)] <harriswong> anastasiac i will be working on the "My Uploaded files aren't saving where I want them to - why? (asked on infusion-users)" and also "Reorderer: How do I send new order back to the server? (asked twice on infusion-users)".
[11:07:26 CDT(-0500)] <michelled_> bhavya: we are in the middle of a documentation sprint. if you have suggestions or feedback for us based on what you've been reading that would be great!
[11:07:29 CDT(-0500)] <anastasiac> harriswong, that's great, thanks - perfect
[11:08:19 CDT(-0500)] <michelled_> bhavya: anastasiac is leading up the doc sprint and I know she loves when she hears from people new to the community
[11:09:31 CDT(-0500)] <anastasiac> bhavya, yes: we are working to improve our documentation, so any comments about what you think of the docs - good or bad - is helpful. If you can't find some information, please ask in the channel. Someone will help you, and we'll find out where our docs are lacking
[11:40:24 CDT(-0500)] <anastasiac> Justin_o, in your search for svn references, this is a good one: http://wiki.fluidproject.org/display/fluid/Contributing+to+a+Fluid+Component
[11:40:51 CDT(-0500)] <Justin_o> anastasiac: okay.. i'll take a look at that one
[11:53:46 CDT(-0500)] <michelled_> Justin_o: I thought of a good use of the third party tests - we could write a set that fail for things we've ended up creating our own versions of
[11:54:01 CDT(-0500)] <michelled_> Justin_o: then when we upgrade, if any of those pass we can ditch our own version of the function
[11:59:17 CDT(-0500)] <Justin_o> fluid-everyone: anyone mind if i cleanup our contributor list
[11:59:36 CDT(-0500)] <michelled_> what sort of cleanup?
[11:59:39 CDT(-0500)] <jessm> Justin_o: link?
[11:59:42 CDT(-0500)] <Justin_o> http://wiki.fluidproject.org/display/fluid/List+of+Current+Fluid+Committers
[12:00:22 CDT(-0500)] <Justin_o> There are a bunch of people who aren't actively contributing, I'm wondering if we can remove them from this list. That should make it easier to see how many people someone is actually mentoring
[12:01:07 CDT(-0500)] <Justin_o> I'm thinking we could probably drop about 8 - 9 of them
[12:01:49 CDT(-0500)] <michelled_> Justin_o: can you ping them to ask them what they want?
[12:02:05 CDT(-0500)] <michelled_> I wouldn't want to drop a contributor who intends to start up again
[12:02:06 CDT(-0500)] <jessm> Justin_o: maybe we should do an emeriti list like we have for committers
[12:02:37 CDT(-0500)] <Justin_o> I'm not sure it matters.. they don't really have any special access that anyone else has
[12:02:47 CDT(-0500)] <Justin_o> it's more for us to track mentorship i think
[12:03:45 CDT(-0500)] <jessm> Justin_o: it might also be nice to somehow mention them as having contributed – is what i was thinking
[12:04:26 CDT(-0500)] <Justin_o> jessm: ah i se
[12:04:27 CDT(-0500)] <Justin_o> see
[12:04:29 CDT(-0500)] <michelled_> jessm: that makes sense
[12:04:39 CDT(-0500)] <Justin_o> so we could have a list for active and past contriburos
[12:04:44 CDT(-0500)] <Justin_o> contributors
[12:05:09 CDT(-0500)] <jessm> yeah
[12:05:14 CDT(-0500)] <jessm> something like that
[12:05:32 CDT(-0500)] <jessm> and that might also give us an easy way to get folks back on the "active" list like michelled_ is mentioning
[12:05:35 CDT(-0500)] <jessm> michelled_: what do you think?
[12:05:55 CDT(-0500)] <michelled_> I think it's a good idea
[12:14:37 CDT(-0500)] <Justin_o> jessm, michelled_ you can check that page again if you want to see how i've separated them
[12:15:22 CDT(-0500)] <michelled_> Justin_o: maybe put the lists in alphabetical order
[12:15:36 CDT(-0500)] <Justin_o> michelled_: i was just starting to do that
[12:16:43 CDT(-0500)] <michelled_> Justin_o, jessm: do you think it would be worth while to put a line in beside each past contributor with what they worked on?
[12:16:44 CDT(-0500)] <jessm> Justin_o: +1
[12:17:41 CDT(-0500)] <Justin_o> michelled_: i'm not sure how easy that would be,
[12:19:44 CDT(-0500)] <michelled_> I forget how to unjinx you two Justin_o and jessm
[12:21:46 CDT(-0500)] <michelled_> Justin_o: you might want to split out the design committers too
[12:22:09 CDT(-0500)] <Justin_o> michelled_: i'll have to chat with jameswy about that
[12:22:18 CDT(-0500)] <Justin_o> since they all still have access to the svn repo
[12:22:19 CDT(-0500)] <jessm> split out, really?
[12:22:47 CDT(-0500)] <michelled_> meaning split the past contributors from the active contributors
[12:22:55 CDT(-0500)] <michelled_> they are already in a separate section on the page
[12:23:13 CDT(-0500)] <jessm> ah
[12:23:19 CDT(-0500)] <jessm> doign two things at once – both badly
[12:24:19 CDT(-0500)] <Justin_o> michelled_, jessm : the design committers are sort of a cross between what the code side would call contributors and committers
[12:25:05 CDT(-0500)] <michelled_> what makes them contributors in the code side sense?
[12:25:59 CDT(-0500)] <Justin_o> i guess the fact that there was no formal process for granting access
[12:26:04 CDT(-0500)] <Justin_o> at least none that i know of
[12:26:50 CDT(-0500)] <michelled_> I guess on the code side there is formal process for granting both contributor and commit access
[12:27:04 CDT(-0500)] <michelled_> although now that we've moved to git contributor access is moot
[12:27:31 CDT(-0500)] <Justin_o> michelled_: yes.. there is no such thing really
[12:27:42 CDT(-0500)] <Justin_o> i do list the contributors in our github organization though
[12:28:47 CDT(-0500)] <Justin_o> it's funny, now that I've alphabetized the names, the mentors are all grouped together too
[12:30:06 CDT(-0500)] <michelled_> hmm.... and I've lost my mentor status
[12:31:22 CDT(-0500)] <Justin_o> michelled_: sorry.. we'll have to find some more contributors
[12:31:38 CDT(-0500)] <michelled_>
[12:31:46 CDT(-0500)] <Justin_o> actually we should probably reorganize that a bit anyways...
[12:32:04 CDT(-0500)] <Justin_o> there may be better ways to split it up now, based on what we're all working on
[12:32:33 CDT(-0500)] <michelled_> perhaps
[12:34:25 CDT(-0500)] <jessm> michelled_: you are the de facto mentor
[12:34:31 CDT(-0500)] <jessm> it's part of your very being
[12:34:44 CDT(-0500)] <michelled_> lol
[12:34:49 CDT(-0500)] <jessm> Justin_o: i see what we're talking about wrt the design committers
[12:34:55 CDT(-0500)] <jessm> hrm, what to do there
[12:35:06 CDT(-0500)] <jessm> i like keeping them there
[12:35:15 CDT(-0500)] <jessm> a list of active designers on the project
[12:35:24 CDT(-0500)] <jessm> in the same place as dev contributors and committers
[12:35:31 CDT(-0500)] <jessm> the meaning of it is a little different now with GIT
[12:35:54 CDT(-0500)] <jessm> i think we can lose the reference to SVN and keep a designers list
[12:36:05 CDT(-0500)] <jessm> though calling them "committers" is probably confusing
[12:36:12 CDT(-0500)] <jameswy> michelled_, Justin_o, jessm: Now that the developers have left to git, isn't svn all design land more or less?
[12:36:40 CDT(-0500)] <jameswy> Yes, the notion of design "committers" is a bit flawed--it's not analogous to a code committer.
[12:37:42 CDT(-0500)] <jameswy> The original purpose of design-svn was to provide a working space to share files between designers (it also acts now as an archive/library of design assets like the logos)
[12:42:48 CDT(-0500)] <jessm> jameswy: how do you recommend the designers be listed?
[12:44:43 CDT(-0500)] <jameswy> jessm: I'm not really sure... I think the proposed "community members" directory for the public site might be sufficient.
[12:45:47 CDT(-0500)] <jameswy> jessm: It would also make sense to mark dev committers on said directory. People looking for this sort of information would probably look for it in a directory of members.
[12:45:48 CDT(-0500)] <jessm> jameswy: i'm a-thinking we might be better served getting this right now and then dreaming dreams about a directory laterz
[12:45:56 CDT(-0500)] <jameswy> Haha.
[12:46:24 CDT(-0500)] <jameswy> Fair enough. Then lop the designers in with the dev commiters page, . Where's the page right now?
[12:46:26 CDT(-0500)] <jessm> spring cleaning and keepin' it simple, that's what March and April are all about
[12:46:28 CDT(-0500)] <jameswy> Justin_o ^
[12:46:42 CDT(-0500)] <jessm> http://wiki.fluidproject.org/display/fluid/List+of+Current+Fluid+Committers
[12:47:00 CDT(-0500)] <jessm> jameswy: designers are there – at the bottom
[12:47:05 CDT(-0500)] <Justin_o> jkkremer: you can try running though this tutorial http://wiki.fluidproject.org/display/fluid/Developer+Introduction+to+Infusion+Framework
[12:47:12 CDT(-0500)] <anastasiac> jkkremer, I was thinking you could be an early tester of the Infusion starter docs heidi_ has been working on
[12:47:16 CDT(-0500)] <anastasiac> which Justin_o just posted the link to
[12:47:58 CDT(-0500)] <anastasiac> heidi_'s still working on it, so maybe she could let you know if any parts are still pretty mushy, but early feedback is always helpful to shape docs-in-progress, jkkremer
[12:49:15 CDT(-0500)] <jkkremer> heidi_ np
[12:49:24 CDT(-0500)] <Justin_o> i think the question is about separating active and non-active though
[12:50:21 CDT(-0500)] <michelled_> jameswy: if we pull out the non-active then we should probably also remove their commit access
[12:50:32 CDT(-0500)] <michelled_> jameswy: does that make sense to you?
[12:50:43 CDT(-0500)] <jessm> Justin_o: jameswy: all together now let's split the designers list – rename it 'designers' and make an active and past column – consistent with the contributors
[12:50:51 CDT(-0500)] <michelled_> jameswy: is there process around design committers? how does one get access, how is it removed?
[12:50:57 CDT(-0500)] <jessm> michelled_: eek!
[12:51:13 CDT(-0500)] <jessm> we have not heretofore had a process
[12:51:59 CDT(-0500)] <jameswy> michelled_, jessm: the process is, "I'd like design commit, please, with sugar on top.",
[12:52:08 CDT(-0500)] <jameswy> (and a cherry)
[12:52:24 CDT(-0500)] <jessm> jameswy: you got it wrong! it's "dear James, ..."
[12:52:49 CDT(-0500)] <jameswy> Lol, that's probably true.
[12:52:51 CDT(-0500)] <jessm> but seriously, it should probably be this http://wiki.fluidproject.org/display/fluid/Process+for+Granting+Commit+Access
[12:53:06 CDT(-0500)] <jessm> we should probably expect the same process from both devs and designers
[12:53:23 CDT(-0500)] <jessm> and therefore the list of designers there should be treated as we treat the committers list
[12:53:52 CDT(-0500)] <jessm> we'll need to email past design "committers" and ask them if they want to keep their access and then split w/ a list of emeriti and current
[12:54:15 CDT(-0500)] <jameswy> jessm, michelled_, Justin_o: I'm agreeable to that ^
[12:54:24 CDT(-0500)] <michelled_> sounds good to me
[12:54:31 CDT(-0500)] <mlam> anastasiac: the cutpoints documentation seems to be complete. what is missing?
[12:55:16 CDT(-0500)] <anastasiac> mlam, we could use some more examples
[12:56:16 CDT(-0500)] <mlam> ah ok. i also see that the createRendererFunction being used to create cutpoints is missing an example
[12:56:16 CDT(-0500)] <anastasiac> there's not much there about how cutpoints are generated, mlam, and that's the direction we'd like people to go
[12:56:20 CDT(-0500)] <jkkremer> heidi: just read through and it is clear and understandable - explains things well and fits it together in a way that is easy to follow. good stuff!
[12:56:48 CDT(-0500)] <anastasiac> also, there might be other ways to generate cutpoints, mlam - you might check with yura_, he might have some suggestions for other things that are good to know about cutpoints
[12:57:03 CDT(-0500)] <mlam> ok, thanks anastasiac
[12:57:26 CDT(-0500)] <heidi_> jkkremer - awesome! any suggestions on making it better?
[12:57:55 CDT(-0500)] <jkkremer> hiedi: under Sub-components - Inversion of Control is empty and the types of components as well are empty
[12:58:13 CDT(-0500)] <heidi_> jkkremer or what would be nice to go to after reading this? yes i know, have to fill that in still
[12:58:18 CDT(-0500)] <anastasiac> mlam, there may also be other occasions (i.e other than fluid.initRendererComponent) where cutpoints are relevant - I'm a bit behind in knowing what's in the framework
[12:59:52 CDT(-0500)] <jkkremer> heidi: from here, it would be nice to head into a bit of code - and maybe keeping the example you started with of the bar graph may be a good idea
[13:00:16 CDT(-0500)] <heidi_> jkkremer - excellent, that's what i was aiming to do. a 'how to create a component' thing for the bar graph
[13:00:50 CDT(-0500)] <jkkremer> heidi: yeah that'd be perfect
[13:00:58 CDT(-0500)] <heidi_> cool thanks
[13:01:42 CDT(-0500)] <jkkremer> heidi: i assume that you will get into the the re-purposing, relating data, using events, etc. all around the graph too?
[13:08:31 CDT(-0500)] <Justin_o> anastasiac: when jkkremer is finished with that page we pointed him at, is there another one you want him to look at?
[13:08:52 CDT(-0500)] * anastasiac ponders
[13:08:55 CDT(-0500)] <heidi_> jkkremer you mean while building the component? yeah i think so... and use some of the tools mentioned as well (change applier etc) ... lots of work there
[13:10:40 CDT(-0500)] <anastasiac> jkkremer (and Justin_o): heidi_ is planning to move on to the "how to create a component" docs soon - that would likely be the next place a new Infusion developer would go anyway, so perhaps you could have a look at what we have now, and let heidi_ know what questions you have about what you read i.e. what still doesn't make sense, or what confuses you, or what info seems missing, etc.
[13:10:52 CDT(-0500)] <anastasiac> heidi_, do you have a link to the particular page
[13:10:53 CDT(-0500)] <anastasiac> ?
[13:11:04 CDT(-0500)] <jkkremer> heidi: yeah i think we are on the same page
[13:11:18 CDT(-0500)] <heidi_> there does exist a tutorial now.. http://wiki.fluidproject.org/display/fluid/How+to+Create+a+Fluid+Component
[13:11:43 CDT(-0500)] <heidi_> but i was going to try from scratch and build a little slower, integrating some of the ideas mentioned in intro
[13:12:17 CDT(-0500)] <heidi_> but jkkremer let me know what you think of that tutorial... what should be added or stripped down etc
[13:12:52 CDT(-0500)] <jkkremer> heidi: i'll work my way through it now and let you know
[13:13:07 CDT(-0500)] <heidi_> great
[13:14:58 CDT(-0500)] <heidi_> Bosmon2 or yura_ , possible to explain IOC in one or two sentences, in the context of components and options?
[13:15:30 CDT(-0500)] <heidi_> i guess how the new way of using subcomponents differs to old way?
[13:17:47 CDT(-0500)] <yura_> heidi_: well the new way is declarative, all the subcomponent needs now can be specified in the parent component defaults or demand blocks
[13:18:21 CDT(-0500)] <heidi_> yura_ instead of setting the subcomponents options, it inherits them kinda thing?
[13:19:00 CDT(-0500)] <michelled_> inherit isn't quite right
[13:19:08 CDT(-0500)] <heidi_> adopts?
[13:19:10 CDT(-0500)] <yura_> subcomponent options can be resolved against anything in the IOC resolution stack, so you can refer to any component that was already created (not just parent)
[13:19:53 CDT(-0500)]

[13:19:56 CDT(-0500)] <heidi_> the "resolution stack" is like the big list of components being used at the moment?
[13:20:04 CDT(-0500)] <yura_> heidi_: exactly
[13:20:21 CDT(-0500)] <yura_> there's a special component that is called instantiator
[13:20:42 CDT(-0500)] <yura_> it keeps track of every component that it have seen
[13:21:09 CDT(-0500)] <heidi_> interesting...
[13:21:36 CDT(-0500)] <yura_> so when the framework tries to resolve this contextual reference (within the component options/defaults) it actually tries to look that reference up within the current instantiator
[13:22:16 CDT(-0500)] <michelled_> I think it would be fair to say that the IoC system asks as a go between - handing components their options when they are created based upon demands that have been defined. Does that seem about right yura_?
[13:22:41 CDT(-0500)] <heidi_> yura_ so its sort of making all the "checked in" components (i.e. in stack)'s options transparent and usable to all the other components
[13:22:53 CDT(-0500)] <yura_> mlam: do you need any details regarding the cutpoint utilities within the rendererComponent
[13:23:11 CDT(-0500)] <heidi_> michelled_ that makes sense
[13:23:56 CDT(-0500)] <mlam> yura_: I think I will....i'm just going through some of hte renderer code right now
[13:24:05 CDT(-0500)] <yura_> michelled_: yes that sounds right
[13:24:18 CDT(-0500)] <heidi_> and the pluses to IOC are that you don't have to copy the same options to all the relevant components? just define it in one place? other pros?
[13:24:46 CDT(-0500)] <yura_> heidi_: not just options, but components themselves
[13:24:51 CDT(-0500)] <mlam> yura_: question, why would an integrator want to create their own fluid.renderer.selectorsToCutpoints function? [13:25:51 CDT(-0500)] <heidi_> yura_ options, functions, events, models ? [13:25:53 CDT(-0500)] <mlam> if it's any different, then the createRendererFunction tree won't be properly constructed? [13:25:56 CDT(-0500)] <yura_> heidi_: yes [13:26:03 CDT(-0500)] <heidi_> pretty rad [13:26:47 CDT(-0500)] <heidi_> so the IOC is like a helper that you can ask to peek into other components and get stuff [13:27:47 CDT(-0500)] <yura_> mlam: well i never used it . but i used to override it [13:27:59 CDT(-0500)] <yura_> i mean i never provided different [13:28:06 CDT(-0500)] <mlam> but cutpoints are cutpoints right? [13:28:13 CDT(-0500)] <yura_> mlam: yes [13:28:14 CDT(-0500)] <mlam> ahh ok [13:29:10 CDT(-0500)] <mlam> I was trying to provide an alternative example to the selectorsToCutpoints function, but I don't know if there can ever be one. [13:29:12 CDT(-0500)] <yura_> i think it might be useful when our selectorsToCutpoints in combination with selectorsToIgnore is not sufficient enough and the component requires some crazy way of generating those [13:29:28 CDT(-0500)] <anastasiac> heidi_, another advantage of IoC is that different subcomponents can be used in different contexts, without the parent component even being aware of it; for example when testing [13:29:34 CDT(-0500)] <yura_> mlam: well there might be [13:29:41 CDT(-0500)] <anastasiac> you can declare "use x in production" and "use y when testing" [13:29:53 CDT(-0500)]