fluid-work IRC Logs-2010-07-07

[02:16:56 CDT(-0500)] * jameswy (~jameswy@142.150.154.115) has joined #fluid-work
[06:09:35 CDT(-0500)] * athena (~athena@c-76-121-97-221.hsd1.wa.comcast.net) has joined #fluid-work
[07:55:41 CDT(-0500)] * anastasiac (~team@142.150.154.193) has joined #fluid-work
[08:03:26 CDT(-0500)] * yura_ (~yura@142.150.154.163) has joined #fluid-work
[08:14:55 CDT(-0500)] * colinclark (~colin@bas2-toronto09-1176130958.dsl.bell.ca) has joined #fluid-work
[08:20:13 CDT(-0500)] * jhung (~Jon@H232.C205.cci.switchworks.net) has joined #fluid-work
[08:22:23 CDT(-0500)] * jhung (~Jon@H232.C205.cci.switchworks.net) has left #fluid-work
[08:23:57 CDT(-0500)] * jhung (~Jon@H232.C205.cci.switchworks.net) has joined #fluid-work
[08:54:31 CDT(-0500)] * clown (~clown@142.150.154.130) has joined #fluid-work
[09:28:39 CDT(-0500)] * Justin_o (~Justin@142.150.154.171) has joined #fluid-work
[09:41:19 CDT(-0500)] * colinclark (~colin@bas2-toronto09-1176130958.dsl.bell.ca) has joined #fluid-work
[09:41:40 CDT(-0500)] <colinclark> Hey anastasiac and yura_
[09:41:45 CDT(-0500)] <yura_> hey colinclark
[09:41:49 CDT(-0500)] <anastasiac> hi
[09:42:10 CDT(-0500)] <colinclark> I chatted with Bosmon yesterday for awhile, with the goal to update my roadmap of various framework development activities that we have on our plate
[09:42:32 CDT(-0500)] <colinclark> Anyway, one of the outcomes from that meeting was that we'd use our dev meeting today to chat more about prototree expansion
[09:42:49 CDT(-0500)] <yura_> great
[09:44:27 CDT(-0500)] <anastasiac> excellent!
[09:45:45 CDT(-0500)] * mackrauss (~Armin@142.150.154.130) has joined #fluid-work
[09:46:57 CDT(-0500)] <colinclark> And the issue of when to defer expansion
[09:46:57 CDT(-0500)] <colinclark> Hope you guys can make it
[09:56:42 CDT(-0500)] * athena (~athena@c-76-121-97-221.hsd1.wa.comcast.net) has joined #fluid-work
[09:58:27 CDT(-0500)] * EricDalquist (~dalquist@2607:f388:e:0:221:9bff:fe37:e768) has joined #fluid-work
[10:02:04 CDT(-0500)] * bsparks (~bsparks@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[10:04:14 CDT(-0500)] * bsparks (~bsparks@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[10:19:13 CDT(-0500)] <colinclark> Justin_o: I'm probably going to miss standup today
[10:20:10 CDT(-0500)] <colinclark> My update from yesterday: nearly finished completely refactoring the Decapod server to split out any actually divergent code between the mock and real servers. Today, it looks like I will get to the point where there really is actually only one server.
[10:20:24 CDT(-0500)] <colinclark> Will need some help QA testing my changes, since they are substantial
[10:27:58 CDT(-0500)] <Justin_o> colinclark: sure... let me know when it's ready to test out
[10:45:14 CDT(-0500)] * colinclark (~colin@bas2-toronto09-1176130958.dsl.bell.ca) has joined #fluid-work
[11:23:52 CDT(-0500)] * colinclark (~colin@142.150.154.130) has joined #fluid-work
[11:26:01 CDT(-0500)] * bsparks (~bsparks@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[11:55:31 CDT(-0500)] * jhung (~Jon@H232.C205.cci.switchworks.net) has joined #fluid-work
[12:21:46 CDT(-0500)] <bsparks> why in infusionAll.js are only some of the jQuery UI 1.8 components included? and which ones? it looks like only core, widget, and mouse, but draggable works...
[12:50:37 CDT(-0500)] <athena> i think they only include the ones that fluid actually uses
[12:51:25 CDT(-0500)] <athena> for uportal we actually build a custom package that includes only fluid and no jquery or jqueryui, since the portal is already including those full libraries
[12:55:18 CDT(-0500)] <colinclark> bsparks: yep, athena's right. We link to the jQuery UI widgets we actually use in our components
[12:55:29 CDT(-0500)] <colinclark> And then you can add any others you want to use by making a jQuery UI custom build
[12:59:23 CDT(-0500)] <bsparks> hmmm... but isn't jquery.ui.draggable.js a separate one? it's not listed in infusionAll.js as being included, but it seems to be included. the reason I ask is that if I want to create components that will work with stock Fluid Infusion and potentially be added to the Fluid component library. or in that case should I just dump the required UI pieces into those components, similarly to InfusionAll.js
[13:03:35 CDT(-0500)] <colinclark> bsparks: Ah, good question
[13:03:48 CDT(-0500)] <colinclark> The thing about InfusionAll.js is that it doesn't really exist as a thing in itself
[13:03:55 CDT(-0500)] <colinclark> It's created dynamically as part of the Infusion build process
[13:04:10 CDT(-0500)] <colinclark> When we ship Infusion we do a custom build that includes everything
[13:04:42 CDT(-0500)] <colinclark> Many users of Infusion, like athena, create their own custom builds of Infusion with only the things they want in it
[13:05:15 CDT(-0500)] <athena> in our case we include all of fluid, but exclude the jquery bits because we're already including hte full jquery and jquery ui libraries prior to the fluid inclusion
[13:05:21 CDT(-0500)] <athena> then after that we include our custom fluid components
[13:06:08 CDT(-0500)] <colinclark> So if you are creating components yourself, you can follow the same basic pattern that we do, and then have the build system squash everything together
[13:06:57 CDT(-0500)] <colinclark> So, in other words, when we're building components, we group third party dependencies together, and then each component has a "dependency declaration file"-- a bit of JSON on the file system--that lists its required dependencies
[13:07:17 CDT(-0500)] <colinclark> For standard development, we typically just link all dependencies individually in the head, and then in production create a build of everything that is needed
[13:07:33 CDT(-0500)] <colinclark> I'm not sure if I'm answering your question, bsparks, but hopefully this helpful?
[13:07:56 CDT(-0500)] <bsparks> I think so... so most users use this: http://forge.fluidproject.org/infusionBuilder/html/InfusionBuilder.html
[13:08:10 CDT(-0500)] <bsparks> rather than the main pre-built download
[13:08:52 CDT(-0500)] * Justin_o (~Justin@142.150.154.171) has joined #fluid-work
[13:09:15 CDT(-0500)] <colinclark> bsparks: Well, that Builder GUI hasn't been officially released
[13:09:29 CDT(-0500)] <colinclark> So I doubt many people actually use that, though we'd like to get it done and have them use it (smile)
[13:09:41 CDT(-0500)] <colinclark> Most people who do make their own custom builds use the command line, Ant-based build system
[13:09:52 CDT(-0500)] <colinclark> Which isn't super-friendly to use, but keeps them going until we finish up the Builder web app
[13:10:05 CDT(-0500)] <colinclark> As for what most users do, I'm not entirely certain
[13:10:12 CDT(-0500)] <colinclark> I think more advanced users tend to make their own custom builds
[13:10:24 CDT(-0500)] <colinclark> Certainly both the uPortal and Sakai 3 applications use custom builds of Infusion
[13:10:53 CDT(-0500)] <colinclark> Other users probably keep it simple and just use InfusionAll.js, linking in any other libraries or widgets that they want to use separately.
[13:12:48 CDT(-0500)] <bsparks> well, my goal was to create components and submit them to the Fluid project for inclusion in the Component Library. so, I was trying to create them using things that Fluid already had dependencies for, rather than introducing new ones, but, I guess in the case of using jquery UI resizeable for instance, I should just include it and note that it's required and not already included in 1.2
[13:13:03 CDT(-0500)] <colinclark> Yep, that's just fine
[13:13:22 CDT(-0500)] <bsparks> ok (smile) thanks
[13:13:32 CDT(-0500)] <colinclark> That's typically how people handle those cases when they're creating a new component
[13:13:48 CDT(-0500)] <colinclark> If they need something, use it and then request that it be added to the /lib folder of Infusion
[13:14:02 CDT(-0500)] <colinclark> Adding a dependency declaration file for the new component and any dependencies where required
[13:14:09 CDT(-0500)] <colinclark> We can help you with that
[13:14:21 CDT(-0500)] <colinclark> It's awesome that you're making components to share!
[13:18:20 CDT(-0500)] <bsparks> oh, I had another question from the other day... does it go against the philosophy of fluid to create components after the creation method? for instance I basically made a copy of the initSubcomponents method and made it so that you would not have to have the component defined in the options, but could pass in that same structure at runtime (if that makes sense)
[13:18:38 CDT(-0500)] <colinclark> Hmm
[13:18:53 CDT(-0500)] <colinclark> At runtime, meaning, as some public method on a component instance?
[13:19:25 CDT(-0500)] <bsparks> yes, component.add({type: 'fluid.pager', options: {}}); for example
[13:22:42 CDT(-0500)] <colinclark> bsparks: I guess I'd have to know more about why you're taking that particular approach
[13:22:58 CDT(-0500)] <colinclark> On the surface, I would imagine that you might not even need the initSubcomponent infrastructure at all
[13:23:59 CDT(-0500)] <colinclark> Generally, the idea with defining subcomponent types as options is that you can design a component with a particular set of relationships
[13:24:18 CDT(-0500)] <colinclark> Say, the Uploader component with a particular subcomponent responsible for handling the back-end uploading work
[13:24:22 CDT(-0500)] <colinclark> Uploader -> Upload Manager
[13:24:33 CDT(-0500)] <colinclark> While still enabling users to replace a given implementation with one of their own
[13:24:55 CDT(-0500)] <colinclark> A simple implementation of Inversion of Control (IoC)
[13:25:20 CDT(-0500)] <colinclark> But it's generally intended to express a dependency relationship between components
[13:25:38 CDT(-0500)] <colinclark> Which, by nature, is probably a dependency that is known at design time as opposed to run time
[13:25:58 CDT(-0500)] <colinclark> The decision about a given type of subcomponent is deferred to runtime
[13:26:06 CDT(-0500)] <colinclark> But the relationship is there from the start, if that makes sense
[13:28:02 CDT(-0500)] <bsparks> hmmm so really I could just use initView and just "add" them to the parent object
[13:28:32 CDT(-0500)] <bsparks> wait... no
[13:28:33 CDT(-0500)] <bsparks> hehe
[13:34:11 CDT(-0500)] <bsparks> I would still use my modified function, because really I want to instantiate new component instances using the "type". It's for a situation such as a container which doesn't care what it's children are besides that they are components with a certain contract. Then I could have buttons or events outside of that component that can add or remove them.
[13:34:11 CDT(-0500)] <colinclark> (smile)
[13:34:32 CDT(-0500)] <colinclark> Hmm
[13:34:42 CDT(-0500)] <colinclark> I'd probably have to see some code examples to really understand
[13:35:29 CDT(-0500)] <colinclark> The question is, what relationship does the parent have to its children, which it doesn't care about much?
[13:35:45 CDT(-0500)] <colinclark> In other words, are there arguments or options that a child component needs to get from its parents somehow
[13:36:28 CDT(-0500)] <colinclark> I guess the other thing to note, which may or may not be helpful to you, is that initSubcomponents() is built on some foundational infrastructure that you may find helpful for cases where you want this kind of indirection of type
[13:37:04 CDT(-0500)] <colinclark> fluid.invokeGlobalFunction() will take the name of the function to invoke as a string, and pass you back the return value. So you can invoke anything indirectly that way
[13:37:29 CDT(-0500)] <colinclark> Component creator functions are just plain old functions, so you can imagine how we use invokeGlobalFunction() to implement initSubcomponent()
[13:38:02 CDT(-0500)] <bsparks> I saw that in there, but I guess I basically just saw iniSubcomponent as a convient way to initView by using the string
[13:38:06 CDT(-0500)] <colinclark> But my guess is that you shouldn't ever have to make a copy of the code inside initSubcomponents() in your own component, you should be able to use it directly, even in the sort of example you describe
[13:40:39 CDT(-0500)] <bsparks> well, I thought because iniSubcomponents relies on var entry = that.options[className]; I basically made fluid.addSubcomponents rely on var entry = classDefObj;
[13:41:41 CDT(-0500)] <colinclark> Is that because your parent doesn't have any options for the given component, you're passing those in to the .add() method instead?
[13:42:15 CDT(-0500)] <colinclark> If that's the case, I'd suggest using fluid.invokeGlobalFunction() instead
[13:42:28 CDT(-0500)] <colinclark> So your add() method would just look something like this:
[13:43:06 CDT(-0500)] <bsparks> yeah, but why not leave the argument processing the same?
[13:43:42 CDT(-0500)] <colinclark> You mean, the argument to your add() method?
[13:44:24 CDT(-0500)] <bsparks> yeah, this is what I've done: http://pastebin.org/385480
[13:45:55 CDT(-0500)] <bsparks> and here is an example of one of the container components http://pastebin.org/385482
[13:47:01 CDT(-0500)] <bsparks> it's still WIP
[13:47:08 CDT(-0500)] <colinclark> for sure
[13:47:56 CDT(-0500)] <colinclark> Ok, this was what I was imagining you were doing
[13:49:19 CDT(-0500)] <colinclark> So, here's what my first suggested implementation looked like:
[13:49:20 CDT(-0500)] <colinclark> http://fluid.pastebin.com/w4rQeuSJ
[13:49:44 CDT(-0500)] <colinclark> But you're saying you want your add() method to take the same format as a subcomponent definition in the options
[13:49:49 CDT(-0500)] <colinclark> So that would look something like this...
[13:50:53 CDT(-0500)] <colinclark> http://fluid.pastebin.com/CjEuMqgs
[13:51:25 CDT(-0500)] <colinclark> Saves you having to cut and paste the whole implementation of initSubcomponent(), since you're not actually using much of the implementation in practice.
[13:52:14 CDT(-0500)] <bsparks> gotcha, well, cool that will work then. and I guess as far as the philosophy of fluid doing that doesn't "break" it?
[13:52:37 CDT(-0500)] <colinclark> Seems fine to me (smile)
[13:52:44 CDT(-0500)] <colinclark> keep going, I look forward to seeing what you've got
[13:52:45 CDT(-0500)] <bsparks> cool, thanks (smile)
[14:41:42 CDT(-0500)] * bsparks (~bsparks@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[15:34:18 CDT(-0500)] <jhung> jameswy: just about to head offline for the day. I've pushed my changes from my work today. Should not affect what you've been working on.
[15:35:12 CDT(-0500)] <jameswy> jhung (jobara): thanks. I've merged changes from the master and pushed to my repo as of 20 minutes ago.
[15:37:07 CDT(-0500)] <jhung> cool. I'll pull that down tomorrow.
[15:37:59 CDT(-0500)] * jhung (~Jon@H232.C205.cci.switchworks.net) has left #fluid-work
[16:08:00 CDT(-0500)] * anastasiac (~team@142.150.154.193) has left #fluid-work
[16:35:22 CDT(-0500)] * Justin_o (~Justin@142.150.154.171) has left #fluid-work
[18:25:12 CDT(-0500)] * jhung (~Jon@H232.C205.cci.switchworks.net) has joined #fluid-work
[18:28:26 CDT(-0500)] * jhung (~Jon@H232.C205.cci.switchworks.net) has left #fluid-work
[20:44:40 CDT(-0500)] * jhung (~Jon@H42.C192.cci.switchworks.net) has joined #fluid-work
[20:44:43 CDT(-0500)] * jhung (~Jon@H42.C192.cci.switchworks.net) has left #fluid-work
[20:50:28 CDT(-0500)] * yura (~yura@206-248-134-178.dsl.teksavvy.com) has joined #fluid-work