fluid-work IRC Logs-2009-04-14

[04:55:02 EDT(-0400)] * apetro (n=apetro@ip68-3-207-51.ph.ph.cox.net) has joined #fluid-work
[04:55:02 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined #fluid-work
[04:55:02 EDT(-0400)] * Bosmo1 (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[04:55:02 EDT(-0400)] * sgithens342f (n=sgithens@in-143-211.dhcp-149-166.iupui.edu) has joined #fluid-work
[04:55:02 EDT(-0400)] * pilpi (i=pilpi@xob.kapsi.fi) has joined #fluid-work
[08:25:28 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[09:20:49 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined #fluid-work
[09:32:09 EDT(-0400)] * clown (n=clown@142.150.154.101) has joined #fluid-work
[09:42:00 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined #fluid-work
[09:51:18 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176406311.dsl.bell.ca) has joined #fluid-work
[10:44:06 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined #fluid-work
[10:57:54 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[11:11:21 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[11:11:21 EDT(-0400)] * Bosmo1 (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[11:12:05 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[11:28:59 EDT(-0400)] <colinclark> fj4000, Justin_o: So what documentation are you guys working on today?
[11:29:15 EDT(-0400)] <colinclark> I'm going to try to focus on the "Why Infusion?" section first.
[11:29:16 EDT(-0400)] <Justin_o> colinclark: hello... i'm working on the migration docs
[11:29:19 EDT(-0400)] <fj4000> at the moment, i finished reviewing fss stuff
[11:29:26 EDT(-0400)] <fj4000> plus ^
[11:29:32 EDT(-0400)] <colinclark> Excellent.
[11:29:47 EDT(-0400)] <colinclark> There's a real dearth of documentation on our framework features.
[11:30:08 EDT(-0400)] <colinclark> I'd love for you guys to dive into that. It might involve learning a bit more about how things work, and asking lots of questions, but I think it will be generally productive.
[11:30:10 EDT(-0400)] <fj4000> should we take some time to update the examples too?
[11:30:15 EDT(-0400)] <colinclark> fj4000: Definitely, yes.
[11:30:20 EDT(-0400)] <fj4000> some of them are very out of date (fss)
[11:30:27 EDT(-0400)] <colinclark> yes
[11:30:45 EDT(-0400)] <Justin_o> colinclark: FLUID-2247, was that an api change in fluid.js
[11:30:47 EDT(-0400)] <fj4000> then I would like to do that as well
[11:31:44 EDT(-0400)] <Justin_o> or the jquery.keyboard1a11y.js
[11:32:08 EDT(-0400)] <colinclark> Justin_o: lemme check
[11:32:17 EDT(-0400)] <colinclark> fj4000: Yep, accuracy and currency are our two primary goals.
[11:32:23 EDT(-0400)] <colinclark> Then breadth, which is also important.
[11:32:53 EDT(-0400)] <colinclark> Justin_o: That was an API change. A big one.
[11:33:06 EDT(-0400)] <colinclark> In that it changed the semantics of our user's handler functions.
[11:33:29 EDT(-0400)] <Justin_o> i think you were telling me you flipped the return value from true to false... or vice versa
[11:33:40 EDT(-0400)] <colinclark> Justin_o: That was part of it.
[11:33:48 EDT(-0400)] <colinclark> That was actually FLUID-2243, I think.
[11:33:58 EDT(-0400)] <colinclark> This one is the fact that we changed the arguments we pass to an activation handler.
[11:34:15 EDT(-0400)] <colinclark> According to the JIRA, we are now the same as jQuery... we pass an Event object as the only argument.
[11:34:19 EDT(-0400)] <colinclark> I'll take a peek at the code to confirm.
[11:34:35 EDT(-0400)] <Justin_o> colinclark: thanks
[11:39:41 EDT(-0400)] <colinclark> Justin_o: I'm not sure this one actually got fixed!
[11:39:59 EDT(-0400)] <colinclark> Justin_o: It didn't.
[11:40:13 EDT(-0400)] <colinclark> Line 591 of jquery.keyboard-a11y.js...
[11:40:25 EDT(-0400)] <colinclark> It's invoking the user's activation handler like this:
[11:40:27 EDT(-0400)] <colinclark> var ret = binding.activateHandler(evt.target, evt);
[11:41:27 EDT(-0400)] <Justin_o> okay.... i see it
[11:42:35 EDT(-0400)] <Justin_o> I just double checked 0.8 and it is the same
[11:42:45 EDT(-0400)] <colinclark> Justin_o: I'm reopening it.
[11:43:10 EDT(-0400)] <Justin_o> okay... thanks for checking... was there any other api changes (other than name changes) for any of the core framework files, that you know of
[11:43:46 EDT(-0400)] <colinclark> Justin_o: Fortunately the framework was pretty stable in this release.
[11:45:38 EDT(-0400)] <Justin_o> colinclark: that is good... thanks for filling me in on this... the Core Framework is the last bit I'm working on for the migration docs.. when I'm done that... was there a specific item you wanted me to work on for the documentation...
[11:46:24 EDT(-0400)] <colinclark> Justin_o: I'm thinking one of the framework features pages might be a good place to start.
[11:46:39 EDT(-0400)] <colinclark> Something you feel reasonably comfortable with from your work on the progress indicators.
[11:46:58 EDT(-0400)] <Justin_o> colinclark: okay.. is it on anastasia's list of documentation tasks
[11:48:06 EDT(-0400)] <colinclark> Justin_o: I think there is probably something there, yes.
[11:48:08 EDT(-0400)] <colinclark> Let me check.
[11:49:04 EDT(-0400)] <colinclark> Justin_o: Yeah, the second table is filled with framework-related pages that haven't yet been written.
[11:49:14 EDT(-0400)] <colinclark> Even if you start with point form, that's useful.
[11:49:22 EDT(-0400)] <colinclark> I'm here if you want to "interview" me about anything.
[11:49:23 EDT(-0400)] <Justin_o> colinclark: okay... thanks...
[11:49:28 EDT(-0400)] <Justin_o> great
[11:49:35 EDT(-0400)] <Justin_o> that could be very helpful
[11:49:38 EDT(-0400)] <colinclark> They keyboard a11y tutorial might be another good one for you to write.
[11:49:48 EDT(-0400)] <colinclark> AC's got a draft there.
[11:49:59 EDT(-0400)] <colinclark> How to Build a Component, perhaps.
[11:50:02 EDT(-0400)] <colinclark> Since you've now built a component.
[11:50:11 EDT(-0400)] <colinclark> Although I'd also love to see fj4000 help with that one.
[11:50:32 EDT(-0400)] <colinclark> It seems we're also pretty behind on tutorials.
[11:50:33 EDT(-0400)] <fj4000> (smile) i will add it to the list
[11:51:04 EDT(-0400)] <Justin_o> colinclark: okay... i'll jump in where i can
[11:51:10 EDT(-0400)] <colinclark> Thanks!
[11:56:57 EDT(-0400)] <Justin_o> colinclark: just wanted to quickly double check something here... for the api name changes that affect the core framework... it looks like they were only for functions in the DataBinding.js file... which didn't exist is 0.8. Is that correct?
[11:57:24 EDT(-0400)] <colinclark> Justin_o: There was one other...
[11:57:30 EDT(-0400)] <colinclark> findKeyInObject was renamed.
[11:57:33 EDT(-0400)] <colinclark> in Fluid.js
[11:57:50 EDT(-0400)] <colinclark> And yes, DataBinding.js didn't exist before 1.0, so that's cool.
[11:57:59 EDT(-0400)] <Justin_o> okay.. thanks
[12:11:37 EDT(-0400)] <athena> found a minor typo on http://wiki.fluidproject.org/display/fluid/Renderer+Component+Types - the second box of code references "linktest" rather than "linktext"
[12:11:59 EDT(-0400)] <athena> and also has a random quotation mark instead of a colon, looks like
[12:12:29 EDT(-0400)] <colinclark> athena: Fixed the first one.
[12:12:39 EDT(-0400)] <athena> thanks (smile)
[12:13:18 EDT(-0400)] <colinclark> athena: And the second one. Thanks so much.
[12:13:34 EDT(-0400)] <athena> yep
[12:13:38 EDT(-0400)] * Topic is 'Infusion 1.0 Documentation Sprint: http://wiki.fluidproject.org/display/fluid/Documentation+Tasks' set by colinclark on 2009-04-14 12:13:38 EDT(-0400)
[12:13:46 EDT(-0400)] <athena> and thank you for making more documentation happen
[12:14:04 EDT(-0400)] <colinclark> athena: We're going for a real push on documentation before we start promoting the framework.
[12:14:10 EDT(-0400)] <colinclark> It's gonna hurt, but be awesome in the end.
[12:14:18 EDT(-0400)] <colinclark> Documentation is hard, but fun.
[12:14:25 EDT(-0400)] <athena> yeah it'll be great to have more documentation
[12:14:37 EDT(-0400)] <athena> and maybe more user-facing documentation
[12:14:55 EDT(-0400)] <athena> not that i don't enjoy reading long treatises on the renderer (smile)
[12:23:25 EDT(-0400)] <Justin_o> colinclark: do you know if the "How to Create a Fluid Component" and "How to Build a Component" are duplicates or are they different things... both pages are essentially untouched
[12:23:46 EDT(-0400)] <colinclark> athena: lol
[12:24:01 EDT(-0400)] <colinclark> Justin_o: They must be duplicates, yes.
[12:24:11 EDT(-0400)] <Justin_o> colinclark: thanks
[12:24:36 EDT(-0400)] <colinclark> Justin_o: I'm just writing an email in response to a question about how Infusion compares to the Open Social Gadgets spec...
[12:24:47 EDT(-0400)] <colinclark> but it outlines the motivations for a number of our framework features.
[12:25:06 EDT(-0400)] <colinclark> I'll get it up in the wiki ASAP; hopefully it will help you with your documentation.
[12:25:35 EDT(-0400)] <colinclark> I see the stuff you're working on as half conceptual, half practical: Talk about the process of building up a component and using our various framework features...
[12:25:46 EDT(-0400)] <colinclark> with an emphasis on why they're useful.
[12:26:03 EDT(-0400)] <colinclark> Flutter might be a good component to use as an example.
[12:29:49 EDT(-0400)] <Justin_o> colinclark: okay... i'll just make sure it is still working (after our svn changes)
[12:30:00 EDT(-0400)] <colinclark> Justin_o: oh yes
[12:30:02 EDT(-0400)] <colinclark> good point
[12:30:11 EDT(-0400)] <colinclark> Justin_o: Also, Flutter now lives in Jasig's repository.
[12:30:18 EDT(-0400)] <colinclark> athena can probably point you to the new URL.
[12:30:37 EDT(-0400)] <Justin_o> colinclark: okay... so if it doesn't work i'll have to send her a patch too right
[12:31:33 EDT(-0400)] <athena> https://www.ja-sig.org/svn/sandbox/FluidTwitterPortlet/trunk/
[12:31:48 EDT(-0400)] <athena> right now the portlet doesn't so much work in general
[12:31:59 EDT(-0400)] <athena> i don't think we ever updated it to finish off the missing pieces?
[12:34:36 EDT(-0400)] <Justin_o> athena: thanks for the link... will i be able to run it?
[12:35:05 EDT(-0400)] <athena> some of the stuff works, but it's not really hooked together
[12:35:19 EDT(-0400)] <athena> so it's not likely to be all that useful until we connect the javascript and java ends
[12:35:21 EDT(-0400)] <athena> it does run though
[12:35:54 EDT(-0400)] <athena> basically you'd need to run "mvn package" and then go into the uportal base source directory and run "ant deployPortletApp -DportletApp=/path/to/war/file"
[12:36:09 EDT(-0400)] <athena> and then register it in uportal as a new channel
[12:39:08 EDT(-0400)] <colinclark> Justin_o: But you can also run the page locally, without a portal or anything.
[12:39:22 EDT(-0400)] <colinclark> It'll use sample data from my Twitter account at the moment.
[12:40:58 EDT(-0400)] <athena> colinclark: the version in the uportal sandbox is only the portlet version
[12:41:11 EDT(-0400)] <colinclark> athena: The markup doesn't work standalone anymore?
[12:41:54 EDT(-0400)] <athena> well, there's no HTML file - it's backed by a Spring PortletMVC controller
[12:42:12 EDT(-0400)] <athena> i assume it'll make sense to have both HTML and portlet versions
[12:43:19 EDT(-0400)] <colinclark> athena: Ah, cool. I'll have to take a closer look.
[12:43:39 EDT(-0400)] <athena> i'm not sure if there's a good way for the two versions to share code
[12:43:40 EDT(-0400)] <colinclark> Justin_o: In the meantime, go ahead and work with the version sitting in the Fluid sandbox. We can merge changes into the portlet version fairly easily.
[12:43:53 EDT(-0400)] <athena> yeah, that's not a problem
[12:44:04 EDT(-0400)] <athena> and we'll need some new features to be able to make the portlet version work
[12:44:19 EDT(-0400)] <colinclark> athena: Something to think about. I haven't had any time for it since Dallas, but since it's coming up as an option for tutorials in Infusion, we can figure out how to keep them together.
[12:44:35 EDT(-0400)] <Justin_o> colinclark, athena: Okay... i'll start with the one in our sandbox
[12:45:10 EDT(-0400)] <athena> colinclark: i think if the flutter javascript became general and stable enough, we could just include it as a versioned dependency or something
[12:45:28 EDT(-0400)] <athena> i haven't really had time to think about it since our last email exchange either
[12:45:33 EDT(-0400)] <athena> both busy w/ releases i guess (smile)
[12:46:04 EDT(-0400)] <colinclark> athena: That makes sense.
[12:46:26 EDT(-0400)] <colinclark> Justin_o: Flutter should ultimately take advantage of the ChangeApplier now that it's here in 1.0. That's something I can work on soon.
[12:47:17 EDT(-0400)] <athena> colinclark: do you still have the list of things that needed updating to make the portlet side work?
[12:47:34 EDT(-0400)] <colinclark> athena: I'm not sure.
[12:47:36 EDT(-0400)] <Justin_o> colinclark: okay..
[12:47:38 EDT(-0400)] <colinclark> Perhaps in old email?
[12:47:39 EDT(-0400)] <colinclark> (smile)
[12:47:48 EDT(-0400)] <athena> lol me neither - i'll do some inbox digging later on today
[12:48:58 EDT(-0400)] <colinclark> I think the biggest things were dealing with the issue of storing username/password and making the UI more "portlet-sized."
[12:50:55 EDT(-0400)] <athena> ah
[12:51:15 EDT(-0400)] <athena> i think we'd talked about having a new url handler that let you inject target urls
[12:51:27 EDT(-0400)] <athena> using post instead of get
[12:51:44 EDT(-0400)] <athena> and being able to inject the credentials
[12:51:48 EDT(-0400)] <athena> that may have been most of it
[12:52:01 EDT(-0400)] <athena> the backend logic for storing and retrieving passwords is all there
[12:58:20 EDT(-0400)] <colinclark> cool
[12:58:39 EDT(-0400)] <colinclark> Justin_o: So if you do dig into Flutter, I guess the thing to do is make a custom build of Infusion with whatever it requires.
[12:58:54 EDT(-0400)] <colinclark> At this point, I'd guess that it just needs a "framework" build, along with the FSS.
[13:00:12 EDT(-0400)] <Justin_o> colinclark: okay... i had just messed up my aptana trying to copy over some files (sad) ... just got it all fixed up again.. the custom build sounds like the way to go...
[13:00:38 EDT(-0400)] <colinclark> cool
[13:00:46 EDT(-0400)] <colinclark> I'm around if you have any questions about it.
[13:00:55 EDT(-0400)] <Justin_o> okay... thanks
[13:11:30 EDT(-0400)] * Bosmon (n=Bosmon@82-43-145-30.cable.ubr02.nmal.blueyonder.co.uk) has joined #fluid-work
[13:11:44 EDT(-0400)] <Bosmon> Hi athena
[13:11:54 EDT(-0400)] <Bosmon> We have the other thing fixed now for your use case for the Pager
[13:12:15 EDT(-0400)] <Bosmon> FLUID-2596
[13:13:18 EDT(-0400)] <athena> oh thanks (smile)
[13:13:54 EDT(-0400)] <Bosmon> An odd side-effect of this method is that you, for this case, would have to do the "disagreeable thing" and embed the pager template inside a comment
[13:14:15 EDT(-0400)] <Bosmon> I couldn't find a way not to get the browsers to corrupt it through innerHTML, since it is not a valid HTML document
[13:14:26 EDT(-0400)] <athena> yeah i'd noticed that before
[13:14:35 EDT(-0400)] <Bosmon> Oh, do you have other invalid templates?
[13:14:54 EDT(-0400)] <Bosmon> It was always something we planned to support, but it didn't seem really necessary until now
[13:15:09 EDT(-0400)] <Bosmon> But even Firefox throws a fit at discovering a <div> tag surrounding two table rows
[13:31:24 EDT(-0400)] <athena> no i'd added it for that, i think
[14:04:14 EDT(-0400)] <Bosmon> "it"?
[14:09:54 EDT(-0400)] <athena> ah sorry - i believe did the "disagreeable thing" when i was experimenting with ~row
[14:10:46 EDT(-0400)] <athena> by the way, are these component types valid for the pager? http://wiki.fluidproject.org/display/fluid/Renderer+Component+Types
[14:14:13 EDT(-0400)] <Bosmon> But.... that wasn't supported before last night!
[14:14:25 EDT(-0400)] <Bosmon> I guess that is what you discovered when you experimented...
[14:15:22 EDT(-0400)] <athena> yes, exactly
[14:15:25 EDT(-0400)] <Bosmon> Yes, those are the component types
[14:15:28 EDT(-0400)] <athena> ok
[14:15:33 EDT(-0400)] <Bosmon> Although I still prefer my guide, which is at http://wiki.fluidproject.org/display/fluid/Fluid+Renderer+-+Background
[14:15:37 EDT(-0400)] <athena> for the markup, can i use bound data?
[14:15:48 EDT(-0400)] <Bosmon> There is a "Supported Component Set" table about 1/3 of the way down
[14:15:50 EDT(-0400)] <Bosmon> What do you mean?
[14:15:57 EDT(-0400)] <athena> oh! that grew
[14:16:07 EDT(-0400)] <Bosmon> Yes, it has been fleshed out a lot
[14:16:19 EDT(-0400)] <Bosmon> Although for some reason it doesn't seem to include "UISelectChoice"...
[14:16:40 EDT(-0400)] <Bosmon> Btw, last night we also added the "fluid decorator"
[14:17:05 EDT(-0400)] <Bosmon> Which is essential if you want to make a directive to instantiate a fluid component (like InlineEdit) to be attached to the final markup
[14:17:13 EDT(-0400)] <athena> i was looking at the "verbatim" option on the other page and wondering if i could insert property values in the markup string
[14:17:24 EDT(-0400)] <Bosmon> Ah, no
[14:17:30 EDT(-0400)] <Bosmon> The markup really is just markup
[14:17:34 EDT(-0400)] <athena> ah
[14:17:35 EDT(-0400)] <athena> sad.
[14:17:35 EDT(-0400)] <Bosmon> What might you want to put in there?
[14:17:47 EDT(-0400)] <athena> this is back to my complicated column full of sutff
[14:17:48 EDT(-0400)] <athena> er, stuff
[14:17:49 EDT(-0400)] <Bosmon> I mean... why is that markup not just another piece of template?
[14:17:51 EDT(-0400)] <colinclark> Justin_o: You were asking about Flutter and a custom build...
[14:18:03 EDT(-0400)] <athena> i still don't quite understand how i might handle that better
[14:18:18 EDT(-0400)] <athena> it continues to be more and more irritating - like, i need to selectively disable some of the checkboxes
[14:18:30 EDT(-0400)] <Bosmon> ok
[14:18:35 EDT(-0400)] <colinclark> If you're getting "fluid.defaults is not a function," it suggests one of two things: 1) your build is somehow messed up, or 2) the file isn't getting linked correctly.
[14:18:49 EDT(-0400)] <Bosmon> You can grab those easily by using the "identify" decorator
[14:18:59 EDT(-0400)] <Bosmon> it makes it very easy to find things which have just been dumped into the markup
[14:19:23 EDT(-0400)] <Bosmon> But tell me about the case that you want to handle with verbatim
[14:19:31 EDT(-0400)] <athena> so just run something after to mark them accordingly?
[14:19:37 EDT(-0400)] <athena> so i have a column that looks likething like
[14:20:01 EDT(-0400)] <Bosmon> Well - you can use the "attrs" decorator to render them as disabled in the first place
[14:20:06 EDT(-0400)] <athena> <td><input type="checkbox"/> <image /> Title</td>
[14:20:08 EDT(-0400)] <Bosmon> It depends how dynamic this disabling needs to be
[14:20:27 EDT(-0400)] <Bosmon> Are they constantly flipping back and forth somehow?
[14:20:35 EDT(-0400)] <Bosmon> ok
[14:20:38 EDT(-0400)] <athena> i didn't have much luck with that - it seemed like just having a disabled attribute set it to disabled regardless of the value of the attribute
[14:20:51 EDT(-0400)] <athena> when the user clicks on the image, the image changes and it disables the checkbox
[14:21:01 EDT(-0400)] <Bosmon> Wacky
[14:21:09 EDT(-0400)] <Bosmon> What on earth does this interface do? (tongue)
[14:21:13 EDT(-0400)] <athena> if a user's selected the row in the past, the image is already different and the checkbox is disabled
[14:21:16 EDT(-0400)] <athena> nothing that cool
[14:21:17 EDT(-0400)] * athena sighs
[14:21:37 EDT(-0400)] <Bosmon> ok, so it is pretty dynamic, it sounds
[14:21:49 EDT(-0400)] <Bosmon> Still, no reason you can't do this all in a giant closure using "identify"
[14:22:22 EDT(-0400)] <Bosmon> Or you could just pick up the stuff later and add handlers to it
[14:22:23 EDT(-0400)] <athena> i did manage to set the onclick element on the image, but that was about as far as i got
[14:22:33 EDT(-0400)] <Bosmon> Although I really do need to put in this event for you
[14:23:15 EDT(-0400)] <Justin_o> colinclark: i figured it out... it was the files had the 0_8 versioning on it... instead of the 1_1 that is used in MyInfusion.js file... michelled just gave me a quick run down of the versioning scheme again
[14:23:24 EDT(-0400)] <colinclark> Justin_o: Aha!
[14:23:41 EDT(-0400)] <colinclark> Yes, that's a good point. I guess Flutter has no particular need to declare a specific version of Infusion.
[14:23:43 EDT(-0400)] <Justin_o> colinclark: i'm still getting this error thoughthat.dialogElement.dialog is not a function
[14:23:56 EDT(-0400)] <colinclark> You could, instead of referring to fluid_0_8, just refer to fluid instead.
[14:24:11 EDT(-0400)] <Justin_o> colinclark: okay... i'll change that ...
[14:24:13 EDT(-0400)] <colinclark> Justin_o: Do you have the jQuery UI dialog included in your build?
[14:24:32 EDT(-0400)] <colinclark> Or, alternatively, linked to separately?
[14:24:48 EDT(-0400)] <athena> ah, Bosmon i think i remembered what the problem was with setting disabled as an attribute
[14:24:58 EDT(-0400)] <athena> is there some way to do something only if a property is true?
[14:26:11 EDT(-0400)] <Justin_o> colinclark: hmm... just talking to michelled about that... maybe not... I had though all our jQuery stuff was included but she just told me it is only the stuff that the framework depends on... i'll go double check
[14:26:27 EDT(-0400)] <colinclark> Justin_o: Did you do a "framework" build?
[14:26:32 EDT(-0400)] <Bosmon> athena: I guess that is not completely straightforward to express in JSON
[14:26:36 EDT(-0400)] <colinclark> If so, it only includes jQuery core and UI core.
[14:26:45 EDT(-0400)] <colinclark> You'll want to add jQueryUIWidgets to your custom build.
[14:26:55 EDT(-0400)] <Justin_o> oh okay... i'll give that a shot
[14:27:36 EDT(-0400)] <athena> so, i'd tried just doing { disabled: ${*.selected} }
[14:27:42 EDT(-0400)] <Bosmon> Yes
[14:27:49 EDT(-0400)] <Bosmon> That will not really do
[14:27:51 EDT(-0400)] <athena> but the problem is that setting the attribute disabled="false" on a checkbox actually renders it as disabled
[14:27:55 EDT(-0400)] <Bosmon> Yes
[14:28:05 EDT(-0400)] <Bosmon> Your only option is to try an RHS value of null or undefined
[14:28:16 EDT(-0400)] <athena> ah
[14:28:21 EDT(-0400)] <Bosmon> But even then you are probably slightly at the mercy of the browser.... if it doesn't work, I can try to put in explicit support for that
[14:28:36 EDT(-0400)] <athena> well, it'd be kind of nice in general to have some if/else logic
[14:28:47 EDT(-0400)] <athena> but i can try setting it that way, hm
[14:29:36 EDT(-0400)] <Bosmon> Hmm yeah, I think this will not work well
[14:29:43 EDT(-0400)] <Bosmon> I will need to add explicit support
[14:29:47 EDT(-0400)] <Bosmon> Perhaps you can make me a JIRA (smile)
[14:29:50 EDT(-0400)] <Bosmon> I will do it after soup
[14:30:12 EDT(-0400)] <athena> mmm soup
[14:30:15 EDT(-0400)] * athena had soup today
[14:30:37 EDT(-0400)] * athena needs to go grocery shopping or else
[14:36:59 EDT(-0400)] <athena> hm, seems impossible to use ${.property} rather than "${.property}"
[14:37:57 EDT(-0400)] * elicochran (n=elicochr@dhcp-169-229-212-24.LIPS.Berkeley.EDU) has joined #fluid-work
[14:40:09 EDT(-0400)] <Bosmon> ?
[14:40:21 EDT(-0400)] <Bosmon> Where would you write $(*.property), without quoting it?
[14:41:50 EDT(-0400)] <athena> oh, i was trying to see if i could get a null property
[14:42:03 EDT(-0400)] <Bosmon> But, what did it look like, when written?
[14:42:04 EDT(-0400)] <athena> but if i have '${*.property}' i wind up with 'null"
[14:42:10 EDT(-0400)] <Bosmon> Yes
[14:42:31 EDT(-0400)] <athena> or does it just assume you want strings
[14:42:39 EDT(-0400)] <Bosmon> No, it is just not geared up for that case yet
[14:42:40 EDT(-0400)] <Bosmon> (tongue)
[14:43:28 EDT(-0400)] <athena> ok (smile)
[14:43:55 EDT(-0400)] <Bosmon> http://issues.fluidproject.org/browse/FLUID-2598
[14:44:41 EDT(-0400)] <athena> very cool
[14:44:45 EDT(-0400)] <athena> aw cute
[14:44:50 EDT(-0400)] <Bosmon> ?
[14:44:50 EDT(-0400)] <athena> there is a this-catt identifier
[14:45:01 EDT(-0400)] <Bosmon> (smile)
[14:45:03 EDT(-0400)] <Bosmon> Where is that?
[14:45:45 EDT(-0400)] <athena> the identify decorator example on your fluid background page
[14:46:02 EDT(-0400)] <Bosmon> ah yes (smile)
[14:47:36 EDT(-0400)] <athena> can't have THE CATT get lost, i suppose
[14:47:41 EDT(-0400)] <Bosmon> Yes
[14:47:53 EDT(-0400)] <Bosmon> It is like one of those little metal tubes that you can put round their neck
[14:48:01 EDT(-0400)] <Bosmon> And inside you can put a small piece of rolled up paper
[14:48:12 EDT(-0400)] <Bosmon> Such that, when you take it out and unroll it, it says, "This is a CATT"
[14:48:25 EDT(-0400)] <athena> just in case you wondered (smile)
[14:48:28 EDT(-0400)] <Bosmon> Yes
[14:48:31 EDT(-0400)] <athena> catts can be deceiving
[14:48:43 EDT(-0400)] <Bosmon> Yes
[14:48:53 EDT(-0400)] <Bosmon> We used to hail Aaron's cat as VISHWAK RAJGOPALAN
[14:48:54 EDT(-0400)] <athena> by the way, on FLUID-2598 i can imagine similar use cases for CSS classes and other decorators
[14:49:09 EDT(-0400)] <Bosmon> Since she frequently had EXTEMELY CRITICAL PRODUCTION ISSUES
[14:49:18 EDT(-0400)] <Bosmon> Ah, for CSS classes, we already have an explicit "removeClass" decorator
[14:49:42 EDT(-0400)] <Bosmon> OK
[14:49:45 EDT(-0400)] <Bosmon> Actually we don't
[14:49:48 EDT(-0400)] <athena> lol
[14:49:51 EDT(-0400)] <Bosmon> But we have the possibility for one
[14:49:52 EDT(-0400)] <Bosmon> (smile)
[14:50:02 EDT(-0400)] <athena> but i can imagine wanting to set one style for one type of element, and another style for another
[14:50:13 EDT(-0400)] <athena> or conditionally set a class based on some property of the item
[14:50:28 EDT(-0400)] <Bosmon> Yes
[14:50:45 EDT(-0400)] <Bosmon> In those cases I suspect you would just write a function to compute the style from the literal data
[14:50:53 EDT(-0400)] <athena> will that work?
[14:50:57 EDT(-0400)] <Bosmon> Yes
[14:51:06 EDT(-0400)] <Bosmon> Your "components" member in columnDefs can be a function, you know
[14:51:10 EDT(-0400)] <Bosmon> I did mention this, right?
[14:51:29 EDT(-0400)] <athena> yes
[14:51:40 EDT(-0400)] <colinclark> Bosmon: Can I get one of those identifiers that says "Don't feed this CAT, he's already already eaten six dinners tonight?"
[14:51:50 EDT(-0400)] <athena> though i still don't quite know that i'd know how to do that
[14:51:52 EDT(-0400)] <Bosmon> So, it gets given the literal row data for that row, from which you can compute any old bit of component tree you like
[14:51:57 EDT(-0400)] <athena> is there an example of that somewhere?
[14:52:10 EDT(-0400)] <athena> i mean i get it in the abstract
[14:52:17 EDT(-0400)] <Bosmon> Well, no examples, no (tongue)
[14:52:37 EDT(-0400)] <Bosmon> colinclark: You can write up a JIRA for that decorator? (tongue)
[14:52:39 EDT(-0400)] <athena> but am very much less confident i could actually write a function with the right parameters that did the right thing
[14:53:28 EDT(-0400)] <Bosmon> Yes... the parameters are already fixed up for you
[14:54:00 EDT(-0400)] <Bosmon> And what you return looks exactly like what the remaining columnDef fields look like... only instead of "*" property references, you just fish the data out yourself
[14:56:22 EDT(-0400)] <athena> so what level is that at, exactly?
[14:56:47 EDT(-0400)]

<athena> would that return the

Unknown macro: { key}

piece? or a piece inside the components?


[14:57:50 EDT(-0400)] <Bosmon> You write the "outside" bit of the columnDef for that column in the usual way
[14:57:56 EDT(-0400)] <Bosmon> So you write the key, valuebinding as normal
[14:58:14 EDT(-0400)] <Bosmon> Only, for the member of that columnDef called "components", you write a function, rather than literal data
[14:58:23 EDT(-0400)] <Bosmon> And this function is given the arguments (row, index)
[14:58:33 EDT(-0400)] <Bosmon> Where row is the relevant row of your data model, and index is the row index number
[14:58:53 EDT(-0400)] <Bosmon> So, this function can return any arbitrary bit of component tree - with two bits of help
[14:59:12 EDT(-0400)] <Bosmon> i) the first bit of help it gets is that the "ID" for the component will be automatically set to what you wrote for the key
[14:59:48 EDT(-0400)] <Bosmon> ii) the second bit is that you can write fluid.VALUE or wildcard expressions at "valuebinding" paths in that tree
[14:59:53 EDT(-0400)] <Bosmon> And they will get expanded for you
[15:00:14 EDT(-0400)] <Bosmon> But other than that, you can make any computation in that function you like, for example to compute your CSS styles, disabled attributes etc.
[15:01:25 EDT(-0400)] <athena> ok, that makes more sense given some background
[15:02:04 EDT(-0400)] <athena> i shall have to do some testing
[15:02:07 EDT(-0400)] <Bosmon> I mean, as I think about it, perhaps the "ID" bit is not so helpful (tongue)
[15:02:18 EDT(-0400)] <Bosmon> I can imagine cases where you might want to take control of this yourself...
[15:03:55 EDT(-0400)] <athena> so to actually call the function, do i use components: function?
[15:04:22 EDT(-0400)] <Bosmon> Well, the framework will call the function
[15:04:37 EDT(-0400)]

<Bosmon> But yes, you would write components: function(row, index) { return

Unknown macro: { blah, blah}

;}


[15:04:50 EDT(-0400)] <athena> ahah! it works
[15:04:54 EDT(-0400)] <Bosmon> (smile)
[15:06:29 EDT(-0400)] <colinclark> Awesome!@
[15:10:09 EDT(-0400)] <athena> ahhh! it works
[15:10:13 EDT(-0400)] <athena> thank you so much bosmon
[15:10:18 EDT(-0400)] <Bosmon> No worries
[15:10:27 EDT(-0400)] <Bosmon> Gosh... it still is so damn hard to write component trees (tongue)
[15:10:37 EDT(-0400)] <Bosmon> I am trying to write the test case now for FLUID-2598....
[15:10:39 EDT(-0400)] <athena> i know we talked about this before, but actually knowing the expected arguments and return at a more specific level makes all the difference
[15:11:01 EDT(-0400)] <colinclark> Bosmon: Something we will focus on for the next few releases.
[15:11:07 EDT(-0400)] <athena> and this actually makes it simple to mark my little checkbox as disabled - works perfectly, in fact
[15:11:10 EDT(-0400)] <Bosmon> Any ideas you have for making this stuff easier to handle would be deeply appreciated, athena...
[15:11:13 EDT(-0400)] <Bosmon> What?
[15:11:18 EDT(-0400)] <Bosmon> It works already?
[15:11:25 EDT(-0400)] <Bosmon> I guess if you can write a function, it is fine
[15:11:28 EDT(-0400)] <athena> yeah
[15:11:39 EDT(-0400)] <Bosmon> I guess I sitll need to fill in this hole in the system though
[15:11:50 EDT(-0400)] <athena> i mean i just returned a little tree that only includes the disabled attribute if i mean to be setting it
[15:11:53 EDT(-0400)] <athena> makes perfect sense
[15:11:53 EDT(-0400)] <Bosmon> Since as far as possible, we want to make it possible for everything to be specified declaratively
[15:11:55 EDT(-0400)] <Bosmon> Yes
[15:12:27 EDT(-0400)] * athena is quite happy
[15:12:35 EDT(-0400)] <Bosmon> Well, I am more than quite happy
[15:12:38 EDT(-0400)] <athena> i think even just documenting how to write such functions would be helpful
[15:12:50 EDT(-0400)] <athena> i mean of course it's not hard - it's just knowing exactly what needs to go where
[15:12:54 EDT(-0400)] <colinclark> athena: Yeah, suggestions would be awesome. I guess our goal is like this: component trees are useful because they're declarative--they're just JSON. But they're also still hard to build, so we're hoping to build up a set of functions that help you generate trees more easily.
[15:13:05 EDT(-0400)] <athena> yeah, definitely
[15:13:19 EDT(-0400)] <Bosmon> All this business with "children" : [[{{ID [children etc.
[15:13:34 EDT(-0400)] <Bosmon> Is quite hard to grasp, even if you are not trying to write anything dehydrated...
[15:13:35 EDT(-0400)] <colinclark> Bosmon: It looks like you are swearing at us. (wink)
[15:13:43 EDT(-0400)] <colinclark> [[[{{ID [!!
[15:13:45 EDT(-0400)] <colinclark> (tongue)
[15:15:43 EDT(-0400)] <athena> lol
[15:16:09 EDT(-0400)] * colinclark is about to sign off for a bit to study for the sailing exam tonight.
[15:16:21 EDT(-0400)] <colinclark> Bosmon, Justin_o: Anything you need me for before I go?
[15:17:06 EDT(-0400)] <Justin_o> colinclark: i think i'm okay... good luck with the exam
[15:17:11 EDT(-0400)] <colinclark> thanks
[15:18:22 EDT(-0400)] <athena> good luck (smile)
[15:18:45 EDT(-0400)] * athena still knows some silly mnemonics about boat lights or something
[15:18:53 EDT(-0400)] <colinclark> (smile)
[15:19:20 EDT(-0400)] <athena> red over green, sailing machine . . .
[15:19:26 EDT(-0400)] <colinclark> (smile)
[15:19:42 EDT(-0400)] <athena> from when kris was studying for her license
[15:19:49 EDT(-0400)] <colinclark> Cool.
[15:19:54 EDT(-0400)] * athena has to make a pilgrimage to boston soon for related purposes
[15:19:57 EDT(-0400)] <athena> anyway, night!
[15:20:10 EDT(-0400)] <colinclark> athena: You should visit jessm while you're in Boston. (smile)
[15:20:35 EDT(-0400)] <athena> hey if she's around that weekend maybe we could do lunch or something
[16:44:56 EDT(-0400)] <Bosmon> athena: Your "removal" functionality is now implemented, as in FLUID-2598 and FLUID-2603
[16:45:03 EDT(-0400)] <athena> thanks! (smile)
[16:45:52 EDT(-0400)] <athena> if you let me work with these components for long you'll have 1 million and 1 use cases, apparently
[16:46:06 EDT(-0400)] <Bosmon> Yes
[16:46:23 EDT(-0400)] <athena> i don't know if that's a good thing or not.
[16:46:30 EDT(-0400)] <Bosmon> Luckily with our awesomely compact framework idiom, they will not require 1 million and 1 features in order to meet them (tongue)
[16:46:40 EDT(-0400)] <athena> lol
[16:46:45 EDT(-0400)] <athena> well that certainly is good
[16:48:43 EDT(-0400)] <athena> now if i can just figure out this whole "fossil bolus" thing
[16:48:50 EDT(-0400)] <Bosmon> hah
[16:48:58 EDT(-0400)] <Bosmon> Well, you shouldn't really need to figure that out
[16:49:08 EDT(-0400)] <Bosmon> It should just work automatically, if you give the renderer the "autoBind: true" flag
[16:49:16 EDT(-0400)] <Bosmon> http://issues.fluidproject.org/browse/FLUID-2604
[16:49:19 EDT(-0400)] <Bosmon> This one is also for you
[16:49:22 EDT(-0400)] <Bosmon> And also for githens
[16:49:30 EDT(-0400)] <Bosmon> I should be able to deal with it shortly
[16:50:11 EDT(-0400)] <athena> ooh nice
[16:50:13 EDT(-0400)] <athena> i like it
[16:50:28 EDT(-0400)] <athena> well, in my use case of the clickable image
[16:50:58 EDT(-0400)] <athena> is autoBind capable of keeping the new image once the onclick event changes it?
[17:06:17 EDT(-0400)] <Bosmon> Well
[17:06:24 EDT(-0400)] <Bosmon> It is the same DOM element, right?
[17:06:33 EDT(-0400)] <Bosmon> You are just changing the img attribute..
[17:07:27 EDT(-0400)] <athena> yeah
[17:07:30 EDT(-0400)] <athena> hm
[17:07:48 EDT(-0400)] <Bosmon> Although I'm not quite clear what the relevance of "binding" would be, to this case
[17:07:58 EDT(-0400)] <Bosmon> I mean, there is no way you could service this change without a custom event handler
[17:08:22 EDT(-0400)] <athena> so i set a custom onclick event on the image
[17:08:31 EDT(-0400)] <athena> that updates the "src" attribute to point to another image
[17:08:35 EDT(-0400)] <Bosmon> ok
[17:08:43 EDT(-0400)] <athena> if i go to the next page and come back, it reverts to the old one
[17:08:58 EDT(-0400)] <Bosmon> yes
[17:09:15 EDT(-0400)] <Bosmon> Since you have not stored this information anywhere in the model
[17:10:03 EDT(-0400)] <athena> i guess i'd figured that i needed to update the property it was calculated from
[17:11:24 EDT(-0400)] <athena> since on the first render it sets the image src attribute depending on an object property
[17:11:43 EDT(-0400)] <Bosmon> yes
[17:13:05 EDT(-0400)] <athena> so . . . what's the best way update that property?
[17:13:18 EDT(-0400)] <Bosmon> Well
[17:13:23 EDT(-0400)] <Bosmon> This seems like pretty custom logic
[17:13:30 EDT(-0400)] <Bosmon> I suggest for now that you update it "by hand"
[17:14:32 EDT(-0400)] <athena> oh ok
[17:14:46 EDT(-0400)] <athena> so just find it in the model and set the property?
[17:14:50 EDT(-0400)] <athena> i wasn't sure if that would work
[17:16:22 EDT(-0400)] <Bosmon> Well, we don't have a DARApplier yet in the Pager
[17:16:26 EDT(-0400)] <Bosmon> So it is even the only option....
[17:16:59 EDT(-0400)] <Bosmon> You might be "helped" by the fact that the right row is passed as an argument to the components() function
[17:17:06 EDT(-0400)] <Bosmon> So you could get at the right bit of data more quickly from there
[17:23:59 EDT(-0400)] <athena> hurrah!
[17:24:04 EDT(-0400)] <athena> everything wokrs
[17:24:09 EDT(-0400)] * athena wonders if that makes it nap time
[17:24:21 EDT(-0400)] <Bosmon> wow
[17:24:31 EDT(-0400)] <Bosmon> Well, THE CATT certainly thinks so
[17:24:38 EDT(-0400)] <Bosmon> He naps, whether everything works, or not (tongue)
[17:25:07 EDT(-0400)] <athena> lol
[17:25:09 EDT(-0400)] <athena> yes
[17:25:39 EDT(-0400)] <athena> the pet snake has a similar disposition
[17:25:50 EDT(-0400)] <athena> though like cats, seems to find laying on keyboards entertaining
[17:29:01 EDT(-0400)] <Bosmon> I am not sure the snake is not to be suspected
[17:29:08 EDT(-0400)] <Bosmon> Would you be happy to have it chew on your finger for a while? (tongue)
[17:30:43 EDT(-0400)] <athena> no
[17:30:46 EDT(-0400)] <athena> it in fact hurts
[17:30:51 EDT(-0400)] * athena has been mistaken for food before
[17:31:45 EDT(-0400)] * clown (n=clown@142.150.154.101) has left #fluid-work
[17:42:13 EDT(-0400)] <Bosmon> There is the core issue with that which is NOT A CATT
[17:44:03 EDT(-0400)] <athena> yes
[17:44:12 EDT(-0400)] <athena> a cat would have more difficult to keep as an illegal dorm pet
[21:32:20 EDT(-0400)] * apetro (n=apetro@rrcs-70-62-121-194.midsouth.biz.rr.com) has joined #fluid-work