[08:37:16 CDT(-0500)] <cindyli> Justin_o: cannot access wiki. have to stop the doc updating. what else can i help with <yura_> you would refer to it by specifying contextual elPath's such as " .options.someOption" <yura_> assuming you have a selectors <mlam> yura_: so for a cutpoint, if a component needs to be mapped to 2 selectors, how would the cutpoints look? , ? <yura_> i think actually you will have a cutpoints tree like tihs : and then you ll have multiple selectors in the component tree but they will be mapped to the same class, it will just be rendered multiple times in the html <mlam> how would translate to the component mapping to multiple selectors?
[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)]
[13:30:09 CDT(-0500)] <anastasiac> with the old calls to initSubcomponent, you couldn't do that without lots of very bad code
[13:30:18 CDT(-0500)] <heidi_> ah interesting. and how did it work before? the parent had to know about its subcomponents and define them within itself?
[13:30:24 CDT(-0500)] <yura_> so your selectorsToCutpoints will make a simple list of containing id a and b
[13:30:49 CDT(-0500)] <heidi_> anastasiac_ ^
[13:30:58 CDT(-0500)] <anastasiac> yes, before a parent explicitly created its subcomponents by calling fluid.initSubcompont" inside its creator function
[13:31:01 CDT(-0500)] <yura_> now what if your component needs all selectors, e.g. a and b to always be interpreted as repeating cutpoints
[13:31:07 CDT(-0500)] <yura_> the ones wiht : at the end
[13:31:15 CDT(-0500)] <heidi_> anastasiac cool i think i get it
[13:31:46 CDT(-0500)] <yura_> in this case you would want your selectorsToCutpoints that will generate cutpoints for all selectors as repeating ones
[13:33:01 CDT(-0500)] <yura_> mlam: ^
[13:33:01 CDT(-0500)] <mlam> are repeating cutpoints valid cutpoints?
[13:33:08 CDT(-0500)] <anastasiac> heidi_, to add the the idea of substituting different components in different context: the different component don't even need to have the same function signature (i.e. parameters) because the parent component never actually invokes the creator function: the declaration says "component x will need y, p, and q from its parent" and "component y will need m and n from its parent"
[13:33:28 CDT(-0500)] <yura_> mlam: i m not sure i understand
[13:33:54 CDT(-0500)] <mlam> when you say repeating cutpoints, are you saying that all cutpoints don't have to be unique?
[13:34:10 CDT(-0500)] <heidi_> anastasiac seems much cleaner, cool
[13:34:38 CDT(-0500)] <anastasiac> heidi_, yes, it is actually very cool, once you can manage to wrap your head around it!
[13:34:55 CDT(-0500)] <yura_> sorry i mean the ones that have an ID with : at the end
[13:35:23 CDT(-0500)] <anastasiac> yura_, when you say "repeating cutpoints", do you mean cutpoints for repeating elements?
[13:35:25 CDT(-0500)] <heidi_> anastasiac how often will we be doing doc sprints? i'm enjoying learning about new infusion stuff
[13:35:34 CDT(-0500)] <yura_> anastasiac: that's the one
[13:35:49 CDT(-0500)] <anastasiac> heidi_, that's exactly what I like to hear!!
[13:35:56 CDT(-0500)] <heidi_>
[13:36:09 CDT(-0500)] <anastasiac> heidi_, we're thinking of having two per release: one near the middle, and one near the end
[13:36:12 CDT(-0500)] <anastasiac> but this is only our first
[13:36:20 CDT(-0500)] <heidi_> cool
[13:36:24 CDT(-0500)] <anastasiac> so we're only really learning how much we can get done
[13:36:36 CDT(-0500)] <mlam> ahhh that makes sense...thanks anastasiac for clearing that up
[13:36:39 CDT(-0500)] <anastasiac> and heidi_, you don't need to wait for a sprint to write docs
[13:36:43 CDT(-0500)] <yura_> heidi_: anastasiac: the only caveat is that if you want this IOC-like options to be resolved into a value from the IOC stack you have to initialize all components through IOC
[13:36:47 CDT(-0500)] <anastasiac> think of is as a nice break from coding
[13:37:02 CDT(-0500)] <heidi_> anastasiac yeah i plan to continue to sprinkle this learning thing throughout
[13:37:18 CDT(-0500)] <anastasiac> yura_, you mean the parent has to be created through IoC as well as all the subcomponents?
[13:38:23 CDT(-0500)] <Justin_o> yura_: is this page still correct
[13:38:23 CDT(-0500)] <Justin_o> http://wiki.fluidproject.org/display/fluid/Data+Import
[13:38:34 CDT(-0500)] <Justin_o> was the code ever committed with the patch
[13:38:36 CDT(-0500)] <Justin_o> ?
[13:39:03 CDT(-0500)] <yura_> anastasiac: well not that parent doesnt have to be but if you are referring to something created before your current component you want to make sure that everything in between was initialized through IOC
[13:40:24 CDT(-0500)] <yura_> Justin_o: it was never moved into trunk i think
[13:40:32 CDT(-0500)] <anastasiac> yura_, is this correct? when you initialize something through IoC and ask for stuff from other components (e.g. "component X wants Y from component Z)") then you have to make sure component Z was created through IoC, because the IoC system can only access stuff from components it created
[13:40:47 CDT(-0500)] <Justin_o> yura_: okay... i don't think it made it to git either... i'll just like to a static version of it in svn
[13:40:51 CDT(-0500)] <Justin_o> thanks
[13:41:23 CDT(-0500)] <anastasiac> and if Z happens to be a grandparent of X, then the parent also has to be created through IoC
[13:41:36 CDT(-0500)] <anastasiac> or is that a wrong understanding?
[13:43:40 CDT(-0500)] <yura_> so if X wants Y from Z, only X has to be initialized with IOC by Z
[13:43:40 CDT(-0500)] <yura_> if X wants Y from Z (where Z is grandparent of X and lets say W is the parent) then again W has to be initialized by Z with IOC, X needs to be initialized by W with IOC but Z itself doesnt have to be
[13:45:54 CDT(-0500)] <anastasiac> so my drawing is: A >> B >> C >> D where >> means "has subcomponent"
[13:46:51 CDT(-0500)] <anastasiac> If B or C or D want anything out of A, they need to have been created using IoC, and anything between them and A need to have been created using IoC (but A itself doesn't need to be created by IoC)
[13:47:23 CDT(-0500)] <anastasiac> so the general recommendation is: Use IoC for everything!!
[13:47:46 CDT(-0500)] <yura_> anastasiac: exactly, it's all or nothing
[13:48:20 CDT(-0500)] <anastasiac> well, not really "all," techincally: the very root can be created the old-fashioned way, technically - though we recommend IoC anyway
[13:49:09 CDT(-0500)] <anastasiac> heidi_, has any of the above exchange between me and yura been helpful?
[13:49:28 CDT(-0500)] <heidi_> yes... okay how does this sound? i feel like it might not be quite right:
[13:49:31 CDT(-0500)] <heidi_> Inversion of Control - a new feature in Infusion to make using components together easier and cleaner. Before a parent component would have to initialize and define options for all of its subcomponents. IOC lets you initialize and add subcomponents through its instantiator to a "resolution stack" where then a component can ask IOC to pick out information from components in this stack as it needs, without having the responsibility of
[13:49:32 CDT(-0500)] <heidi_> creating or even knowing too much about its subcomponents.
[13:51:20 CDT(-0500)] <anastasiac> I might change "Before, a parent component would have to initialize..." to something like "Instead of having to directly initialize..." (i.e. don't talk about it via comparison with the old way - many readers won't know the old way)
[13:51:52 CDT(-0500)] <heidi_> okay, thanks
[13:51:58 CDT(-0500)] <heidi_> the rest ok? yura_ ?
[13:52:26 CDT(-0500)] <anastasiac> heidi_, I'd also change "IoC lets you initialize and add subcomponents" to something like "IoC lets you declare subcomponents and their options"
[13:52:34 CDT(-0500)] <anastasiac> it's really kind of a passive thing
[13:52:44 CDT(-0500)] <heidi_> ah, yes
[13:52:55 CDT(-0500)] <anastasiac> heidi_, have you looked at IoC code, at demands blocks, etc?
[13:53:08 CDT(-0500)] <heidi_> it's not really doing anything other than registering/acknowledging
[13:53:20 CDT(-0500)] <anastasiac> right
[13:53:34 CDT(-0500)] <heidi_> i tried reading http://wiki.fluidproject.org/display/docs/Infusion+IoC but i'll try again with this new udnerstanding
[13:53:43 CDT(-0500)] <anastasiac> "you" don't initialize anything, you declare what you need, and IoC initializes it
[13:53:55 CDT(-0500)] <anastasiac> heidi_, i'd recommend looking at some actual code
[13:53:56 CDT(-0500)] <heidi_> aha
[13:54:28 CDT(-0500)] <anastasiac> the tests might help, and of course the CollectionSpace code base is becoming all-IoC, all-the-time!
[13:55:00 CDT(-0500)] <anastasiac> I think you're starting to understand well enough that looking at code that uses demands blocks might really help solidify things for you, heidi_
[13:55:17 CDT(-0500)] <heidi_> cool, i'll take a look!
[13:55:38 CDT(-0500)] <anastasiac> heidi_, if you look at some code and don't quite understand it, ask someone to walk you through it
[13:55:44 CDT(-0500)] <heidi_> anastasiac is there plans to IOC all of our existing components? i know some are already being switching
[13:55:48 CDT(-0500)] <heidi_> switched
[13:55:59 CDT(-0500)] <anastasiac> ultimately, yes, but likely over a few releases
[13:56:04 CDT(-0500)] <heidi_> ok
[13:56:09 CDT(-0500)] <anastasiac> Uploader is IoC-ified, so you could lookat that
[14:12:50 CDT(-0500)]
[14:14:36 CDT(-0500)]
[14:16:10 CDT(-0500)]
[14:22:47 CDT(-0500)] <yura_> well it maps to the same one, just multiple times
[15:06:22 CDT(-0500)] <mlam> anastasiac: i'm having troubles thinking of a good example for overriding the selectorsToCutpoint() function for the cutpoints documentation. I just spoke with michelled_ and we're in agreement that it might not be necessary to provide alternate code examples for our framework. What do you think?
[15:07:06 CDT(-0500)] <anastasiac> hm... what's the use case for overriding the function? I didn't even know that might be done. Is it likely to be common?
[15:07:23 CDT(-0500)] <anastasiac> where would the overriding be done/
[15:07:25 CDT(-0500)] <anastasiac> ?
[15:08:08 CDT(-0500)] <mlam> I dont' think so. But the original documentation suggested an example to illustrate the option of overriding this function
[15:08:41 CDT(-0500)] <anastasiac> which documentation is this?
[15:08:56 CDT(-0500)] <mlam> http://wiki.fluidproject.org/display/docs/Cutpoints
[15:09:16 CDT(-0500)] <mlam> Under "generated", there's an examples plug.
[15:09:29 CDT(-0500)] <anastasiac> ah, ok, I see where. let me look a bit at createRendererFunction
[15:10:21 CDT(-0500)] <mlam> There's definitely the option of overriding it, and the code clearly gives you freedom to do so, but I can't think of any use case of why someone would alter framework code to do what they want to do with creating cut points
[15:12:00 CDT(-0500)] <anastasiac> so, mlam: a renderer will, by default, use the selectors as cutpoints. This works if the things in the renderer tree are the things you have selectors for. You'd need to override that if, for some reason, your component tree doesn't really map to the things you've defined selectors for.
[15:12:10 CDT(-0500)] <anastasiac> I agree that this use case probably wouldn't happen very often.
[15:13:02 CDT(-0500)] <mlam> You think we should still provide an example here?
[15:13:16 CDT(-0500)] <anastasiac> I agree that we probably don't need to supply an example, except perhaps to show how you would pass the name of your custom function as an option to initRendererComponent, but not to actually write such a function
[15:13:31 CDT(-0500)] <anastasiac> did that make any sense?
[15:13:58 CDT(-0500)] <mlam> Ah, ok...I can do that
[15:14:00 CDT(-0500)] <mlam> makes sense
[15:14:05 CDT(-0500)] <anastasiac> great, thanks
[15:29:57 CDT(-0500)] <harriswong> anastasiac: For the "reorderer: How do I send new order back to the server?" FAQ, I noticed there is already an existing wiki page that explains all that, so I simply added a link to it.
[15:30:32 CDT(-0500)] <anastasiac> harriswong, thanks. Does the existing page look correct? is everything still up-to-date?
[15:31:12 CDT(-0500)] <harriswong> anastasiac: http://wiki.fluidproject.org/display/fluid/Talking+to+the+Server+Using+The+afterMove+Event, Mar 11, 2011, seems pretty updated
[15:32:12 CDT(-0500)] <harriswong> anastasiac: I have finished adding the 2 FAQ pages on the list, I guess I will move on to the last one: "Is it possible to have a multiline inline edit, without the "Rich Text" functionality?"?
[15:32:15 CDT(-0500)] <anastasiac> harriswong, the change that was made this month was fixing a spelling mistake. Other than that, it hasn't been touched since last July
[15:32:38 CDT(-0500)] <anastasiac> but the inline edit one would be good to have - go with that, harriswong
[15:33:25 CDT(-0500)] <harriswong> anastasiac: Ok, I will move on ahead with the inline edit one; and then back to review this page to see if it's indeed updated enough.
[15:33:32 CDT(-0500)] <anastasiac> thanks
[15:34:25 CDT(-0500)] <harriswong> anastasiac: Should I send you all the FAQ pages to the list and then ping you here?
[15:37:10 CDT(-0500)] <anastasiac> harriswong, sure! that's not a bad idea
[15:48:02 CDT(-0500)] <harriswong> anastasiac: FAQ sent.
[15:48:19 CDT(-0500)] <michelled> Bosmon2: I've got a couple more questions for you about the framework code.
[15:48:24 CDT(-0500)] <anastasiac> harriswong, thanks so much for your help with the docs!
[15:48:31 CDT(-0500)] <michelled> I was wondering why fluid.model.defaultFetchStrategy checks for "" and returns root in that case
[15:48:35 CDT(-0500)] <michelled> and only that case
[15:48:48 CDT(-0500)] <harriswong> anastasiac: I hope they are okay, please let me know if there are any adjustments/improvement you want me to make.
[15:49:02 CDT(-0500)] <michelled> Bosmon2: is 'segment' an elpath?
[15:49:02 CDT(-0500)] <Bosmon2> Hi michelled, ask away
[15:49:14 CDT(-0500)] <Bosmon2> Segment is a "segment" of an EL path
[15:49:22 CDT(-0500)] <Bosmon2> That is, the part of it that comes between "." characters
[15:49:40 CDT(-0500)] <michelled> and so the only possible falsey value would be ""
[15:49:42 CDT(-0500)] <Bosmon2> This is of course all modulo our (private) conversation yesterday about escaping rules for EL expressions
[15:49:55 CDT(-0500)] <Bosmon2> Yes, I believe so
[15:50:03 CDT(-0500)] <Bosmon2> "0" would not count as falsy unless it somehow got converted
[15:50:24 CDT(-0500)] <Bosmon2> "" is not actually a legal value, unless the entire expression is empty
[15:50:41 CDT(-0500)] <Bosmon2> That is, it is not legal to have an expression with 2 consecutive .
[15:50:57 CDT(-0500)] <Bosmon2> This probably isn't formalised anywhere, but it is not legal
[15:51:16 CDT(-0500)] <Bosmon2> Btw, anastasiac, yura_, thanks for the great explanation of IoC earlier
[15:51:16 CDT(-0500)] <michelled> right. so you've got a guard for empty string - any reason you don't need it to encompass null and undefined too?
[15:51:30 CDT(-0500)] <Bosmon2> Which particular method are you looking at?
[15:51:45 CDT(-0500)] <anastasiac> Bosmon2, hopefully you'll let us know if we got anything wrong
[15:51:48 CDT(-0500)] <michelled> fluid.model.defaultFetchStrategy
[15:53:23 CDT(-0500)] <Bosmon2> Yes, you could not ever be supplied null or undefined at this location
[15:53:34 CDT(-0500)] <Bosmon2> The "strategy" is not operated by the user, but by the "trundling machine"
[15:53:44 CDT(-0500)] <Bosmon2> Which has already done guarding for the overall path being null or undefined at the head
[15:54:06 CDT(-0500)] <Bosmon2> If you look at "fluid.model.trundle"
[15:54:15 CDT(-0500)] <Bosmon2> The head of it contains the frontline guarding of the EL
[15:54:50 CDT(-0500)] <michelled> ah - conversion to empty string for other falsey values
[15:55:01 CDT(-0500)] <Bosmon2> yes
[15:55:12 CDT(-0500)] <michelled> what is 'config' and 'uncess' being passed to fluid.model.trundle?
[15:55:30 CDT(-0500)] <Bosmon2> "config" is the overall configuration to the trundler
[15:55:49 CDT(-0500)] <Bosmon2> Which includes both "strategies", one of which you were just looking at, and "resolvers"
[15:56:02 CDT(-0500)] <Bosmon2> "uncess" is generally either 0 or 1, and indicates "how many EL segments before the end to stop"
[15:56:13 CDT(-0500)] <Bosmon2> For example if this is a "get" operation, you want to go all the way to the end
[15:56:26 CDT(-0500)] <Bosmon2> If it is a "set" operation, you want to stop one segment before the end, so you can actually DO it
[15:57:03 CDT(-0500)] <Bosmon2> For example, you can see the shared function "getPenultimate" calls "trundle" with uncess set to 1
[15:58:17 CDT(-0500)] <michelled> makes sense
[15:59:14 CDT(-0500)] <michelled> what are trundlers for mainly? clearly it's traversing the model but it's doing a lot more then just that
[16:00:46 CDT(-0500)] <Bosmon2> Well... trundlers are the new "GATEWAY TO THE SOUTH"
[16:01:01 CDT(-0500)] <Bosmon2> I guess so far they are a kind of "imperfectly developed abstraction"
[16:01:20 CDT(-0500)] <Bosmon2> Imagine a programming languages where ALL variable references where actually trundlers
[16:01:22 CDT(-0500)] <michelled> so, they'll take me someplace with no snow?
[16:01:28 CDT(-0500)] <Bosmon2> Almost certainly
[16:01:30 CDT(-0500)] <Bosmon2> Like Goa
[16:01:33 CDT(-0500)] <michelled>
[16:01:54 CDT(-0500)] <Bosmon2> Yes, they are a kind of "fundamental unit of model traversal"...
[16:02:03 CDT(-0500)] <Bosmon2> But there is a key, and important aspect to them... that they are COPIABLE
[16:02:14 CDT(-0500)] <Bosmon2> And this is the way in which they are similar to "variable references"
[16:02:28 CDT(-0500)] <Bosmon2> So a trundler is a kind of "tracked reference into a model"
[16:02:40 CDT(-0500)] <Bosmon2> As well as knowing what VALUE it is at in the model, it also knows which POSITION it is at
[16:02:44 CDT(-0500)] <Bosmon2> But... it also knows more than that
[16:02:54 CDT(-0500)] <Bosmon2> There is "hidden state" inside the "config" object
[16:03:14 CDT(-0500)] <Bosmon2> This only becomes important once we have more and more "schema-aware traversal" of the kind that is coming in CSpace
[16:03:33 CDT(-0500)] <Bosmon2> The trundler... "trundles".... and all the things inside the box trundle too, along with it
[16:03:52 CDT(-0500)] <Bosmon2> So for example a "strategy"
[16:04:01 CDT(-0500)] <Bosmon2> needs to know "Where it has got up to in the schema"
[16:04:11 CDT(-0500)] <Bosmon2> And is kept in step with "where the overall trundler has got up to in the model"
[16:04:20 CDT(-0500)] <Bosmon2> So that when the next "trundle" operation comes along, they both move along in step
[16:04:45 CDT(-0500)] <Bosmon2> BUT - the overall thing can be copied - which is important when we come to write "resolvers"
[16:04:53 CDT(-0500)] <Bosmon2> "resolvers" are what Colin likes to call "queries"
[16:04:56 CDT(-0500)] <Bosmon2> Currently we have just one of them
[16:05:02 CDT(-0500)] <Bosmon2> Again, one which JURA uses in CSpace
[16:05:25 CDT(-0500)] <Bosmon2> It currently lives in our test cases
[16:05:36 CDT(-0500)] <Bosmon2> In FluidJSTests.js line 539
[16:05:59 CDT(-0500)] <Bosmon2> "childMatchResolver" is our paradigmatic, and currently essentially only use of complex "trundling"
[16:06:19 CDT(-0500)] <Bosmon2> And shows the basic workflow that a "resolver" is something which accepts one trundler, and returns another
[16:06:34 CDT(-0500)] <Bosmon2> It is the TRUNDLER CALCULUS
[16:09:07 CDT(-0500)] <michelled> interesting
[16:09:31 CDT(-0500)] <Bosmon2> So it would not be possible for a "resolver" to do its work if a trundler were not i) trundlable, and ii) copiable
[16:09:42 CDT(-0500)] <Bosmon2> Which are what make them very similar to variable references
[16:09:58 CDT(-0500)] <Bosmon2> For example you can say "var a = b" which copies a reference
[16:10:16 CDT(-0500)] <Bosmon2> You can also say a = a.path which you can think of as "trundling" the reference
[16:11:07 CDT(-0500)] <Bosmon2> When the glorious new dawn of ECMAScript 6 or whatever it will be finally appears, "trundlers" are what we will use to put behind "proxies"... so that we can trundle with REAL variable references
[16:12:24 CDT(-0500)] <Bosmon2> Actually it looks like trundling automatically copies the trundler
[16:12:32 CDT(-0500)] <Bosmon2> So it is much more like writing "var b = a.path"
[16:12:59 CDT(-0500)] <michelled> did the API for fluid.get change when trundlers were introduced?
[16:13:04 CDT(-0500)] <Bosmon2> var newTrundler = trundler.trundle("path") is the equivalent
[16:13:10 CDT(-0500)] <Bosmon2> Well... "not really"
[16:13:22 CDT(-0500)] <michelled> environment is the same as config?
[16:13:32 CDT(-0500)] <Bosmon2> It always had a 3rd argument of which the purpose was essentially obscure
[16:13:40 CDT(-0500)] <Bosmon2> Now it has a different argument of which the purpose is essentially obscure
[16:13:43 CDT(-0500)] <Bosmon2> No, they are very different
[16:13:58 CDT(-0500)] <Bosmon2> But I don't believe we ever advertised "environment"
[16:14:18 CDT(-0500)] <Bosmon2> The material which used to be in "environment" appears inside "config" as part of the "environmentalStrategy"
[16:14:23 CDT(-0500)] <michelled> did trundlers ship in 1.3?
[16:14:31 CDT(-0500)] <Bosmon2> No
[16:14:40 CDT(-0500)] <Bosmon2> They were part of the material that was "hidden in the branch" whilst we were release 1.3.1
[16:14:45 CDT(-0500)] <Bosmon2> releasing
[16:15:03 CDT(-0500)] <Bosmon2> They were in trunk during a period coming up to 1.3.1 but they were part of what we decided to back out
[16:16:12 CDT(-0500)] <Bosmon2> What DID ship in 1.3.1 was a version where the 3rd arg of fluid.get was a raw array of strategies
[16:16:26 CDT(-0500)] <Bosmon2> So this unofficial 3rd arg is going to change twice in 2 successive releases
[16:17:25 CDT(-0500)] <michelled> it feels like we are on shaky ground referring to arguments as 'unofficial'
[16:17:39 CDT(-0500)] <Bosmon2> Well, I believe the official terminology is "unsupported"?
[16:18:08 CDT(-0500)] <Bosmon2> I think it will still be "unsupported" even in 1.4
[16:18:10 CDT(-0500)] <michelled> well, we've used that terminology for functions do we actually also use it for arguments to production level functions?
[16:18:16 CDT(-0500)] <Bosmon2> All of trundlers I think are pretty firmly sneak peak
[16:18:30 CDT(-0500)] <Bosmon2> Well... I think we will have to
[16:18:36 CDT(-0500)] <Bosmon2> There are a number of other examples of this too
[16:19:15 CDT(-0500)] <Bosmon2> For example "fluid.expandOptions" will probably be production-grade soon
[16:19:22 CDT(-0500)] <Bosmon2> But the 4th arg is always going to be "unsupported"
[16:19:54 CDT(-0500)] <michelled> let's put this on the next dev meeting agenda - it's going to be a documentation challenge at the very least if part of a function has a different status then the rest of it
[16:20:02 CDT(-0500)] <Bosmon2> ok
[16:20:19 CDT(-0500)] <Bosmon2> The same issue, I think, is a function which has "unsupported options"
[16:20:22 CDT(-0500)] <Bosmon2> Which we also have plenty of
[16:20:31 CDT(-0500)] <Bosmon2> I mean, a component
[16:20:43 CDT(-0500)] <michelled> yes
[16:25:28 CDT(-0500)] <anastasiac> Bosmon2, FYI that third argument to get/getBeanValue is documented in our docs. Should that be removed?
[16:25:36 CDT(-0500)] <Bosmon2> Certainly
[16:25:43 CDT(-0500)] <Bosmon2> What does it say it is?
[16:26:21 CDT(-0500)] <anastasiac> it's a copy of the description that's in the comments in the code
[16:26:34 CDT(-0500)] <Bosmon2> Well, as of what date?
[16:26:48 CDT(-0500)] <anastasiac> keep in mind that other than what's in the comments, there's no real way for the documentation writer to know what's "unsupported"
[16:26:56 CDT(-0500)] <anastasiac> I think it was added for 1.3
[16:27:12 CDT(-0500)] <anastasiac> for the older get/setBeanValue
[16:27:27 CDT(-0500)] <Bosmon2> So it considers it as "environment"?
[16:27:37 CDT(-0500)] <anastasiac> yes
[16:27:48 CDT(-0500)] <anastasiac> oh, no- config
[16:27:59 CDT(-0500)] <Bosmon2> Well... "config" has never been released
[16:28:13 CDT(-0500)] <anastasiac> actually, it documents that it was env for 1.2 and changed to config for 1.3
[16:28:19 CDT(-0500)] <anastasiac> well, it was there for 1.3
[16:29:17 CDT(-0500)] <anastasiac> https://github.com/fluid-project/infusion/blob/infusion-1.3/src/webapp/framework/core/js/Fluid.js
[16:29:31 CDT(-0500)] <anastasiac> line 469
[16:29:47 CDT(-0500)] <Bosmon2> Well, it's funny
[16:29:58 CDT(-0500)] <Bosmon2> Given the comment above the file still declares it is called "environment"
[16:30:12 CDT(-0500)] <anastasiac> yes, clearly the comments are not up-to-date :-P
[16:31:29 CDT(-0500)] <Bosmon2> I had forgotten "strategies" were implemented so early
[16:31:49 CDT(-0500)] <Bosmon2> I guess 1.3.1 and 1.3 were relatively close together
Unknown macro: {parent}
Unknown macro: {a}
Unknown macro: {id}
Unknown macro: {id}
Unknown macro: {id}
Unknown macro: {id}
Manage space
Manage content
Integrations