fluid-work IRC Logs-2008-07-30

[08:04:36 EDT(-0400)] * Justin_o (n=Justin@142.150.154.235) has joined #fluid-work
[08:25:25 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[08:55:09 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[09:13:29 EDT(-0400)] * athena7 (n=athena7@adsl-75-58-125-195.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[09:19:22 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[09:26:27 EDT(-0400)] <athena7> anyone around who might be able to help me understand the simple layout reorderer's orderChangedCallback?
[09:29:26 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[09:39:39 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[09:48:31 EDT(-0400)] * anastasia_c (n=team@142.150.154.160) has joined #fluid-work
[10:00:42 EDT(-0400)] * davidb (n=davidb@142.150.154.101) has joined #fluid-work
[10:33:14 EDT(-0400)] * apetro-_ (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[11:10:19 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[11:19:30 EDT(-0400)] <colinclark> Is anyone averse to the idea of deprecating fluid.mixin() in favour of jQuery.extend()?
[11:20:00 EDT(-0400)] <colinclark> michelled, anastasiac: ^
[11:20:15 EDT(-0400)] <anastasia_c> does fluid.mixin() offer anything that extend doesn't?
[11:20:27 EDT(-0400)] <anastasia_c> and vice versa?
[11:20:32 EDT(-0400)] <Bosmon> vice versa, yes
[11:20:41 EDT(-0400)] <Bosmon> I was actually planning to blog about jQuery.extend (tongue)
[11:20:49 EDT(-0400)] <michelled> athena7: sorry, I hadn't seen your question
[11:21:02 EDT(-0400)] <athena7> oh, that's ok (smile)
[11:21:10 EDT(-0400)] <athena7> any thoughts?
[11:21:48 EDT(-0400)] <Bosmon> Yes
[11:21:58 EDT(-0400)] <Bosmon> It is a null-arg function which is called when the order of the reorderables changes...
[11:22:06 EDT(-0400)] <Bosmon> You are responsible for understanding the nature of the change by yourself (tongue)
[11:22:11 EDT(-0400)] <michelled> it's actually not null-arg anymore
[11:22:15 EDT(-0400)] <Bosmon> But typically the best way is just to issue a Jquery
[11:22:18 EDT(-0400)] <Bosmon> It is so!
[11:22:19 EDT(-0400)] <michelled> it takes the item being moved
[11:22:24 EDT(-0400)] <Bosmon> I am looking at the source right now (tongue)
[11:22:25 EDT(-0400)] <anastasia_c> regarding mixin/extend, I don't see a good reason to create our own function to do something that jQuery does a good job of
[11:22:32 EDT(-0400)] <michelled> so am I (tongue)
[11:22:40 EDT(-0400)] <Bosmon> Well you haven't committed it then (tongue)
[11:22:44 EDT(-0400)] <Bosmon> Fiend...
[11:23:04 EDT(-0400)] <michelled> (smile)
[11:23:19 EDT(-0400)] <Bosmon> Anyway, a simple option would be to treat like a null-arg function (tongue)
[11:23:34 EDT(-0400)] <Bosmon> Especially in the default case where what you want to do is simply ship the entire reordered state back to a server...
[11:24:23 EDT(-0400)] <Bosmon> Anyway, I assume Jen was actually asking about released functionality (tongue)
[11:25:49 EDT(-0400)] <athena7> i'm not sure if the plan for the portal is to use a released or soon-to-be-released version?
[11:25:59 EDT(-0400)] <athena7> so what we really need is to know what changed
[11:26:04 EDT(-0400)] <athena7> what was moved, and where it was put
[11:26:22 EDT(-0400)] <athena7> is it possible to get that information from the reorderer, or do we only get the new layout and have to manually infer differences?
[11:26:22 EDT(-0400)] <Bosmon> Well, even in 0.4 (the current release) I assume it will still be null-arg...
[11:27:10 EDT(-0400)] <Bosmon> You would need to infer it
[11:27:22 EDT(-0400)] <michelled> Bosmon: this was the issue that we discussed on list and made it in after code freeze
[11:27:25 EDT(-0400)] <michelled> 1033
[11:27:28 EDT(-0400)] <Bosmon> !!!!!
[11:27:30 EDT(-0400)] <Bosmon> This is 1033?!
[11:27:39 EDT(-0400)] <athena7> ok
[11:27:46 EDT(-0400)] <michelled> yes - didn't look at the patch (tongue)
[11:27:53 EDT(-0400)] <athena7> i'm a little worried about the performance overhead, but it's certainly possible to do
[11:28:00 EDT(-0400)] <Bosmon> Well, it had been QAed (tongue)
[11:28:43 EDT(-0400)] <michelled> athena7: colinclark asked me to provide a simpler way of handling locked portlets since the simple layout reorderer can't
[11:29:09 EDT(-0400)] <michelled> I had thought the you were going to use this code - not the release that is being put out today
[11:29:41 EDT(-0400)] <michelled> I am just in the midst of writing and testing in and then I can send you a minified Fluid-all.js file with the changes
[11:29:55 EDT(-0400)] <Bosmon> Oh dear...
[11:30:00 EDT(-0400)] <Bosmon> This will teach me not to read things...
[11:30:18 EDT(-0400)] <athena7> i don't know which we're using, sorry (smile)
[11:30:32 EDT(-0400)] <colinclark> Hey all, let me try to clarify...
[11:30:34 EDT(-0400)] <michelled> no issues (smile) I'm just trying to clarify myself
[11:30:55 EDT(-0400)] <colinclark> Gary and some of the other designers want to do some user testing on the LayoutCustomizer in uPortal...
[11:31:14 EDT(-0400)] <michelled> going back to the order change question - when we last talked, we had thought it would be best for the client to send the server the new 'layout' object and then the server would respond with the new perms
[11:32:23 EDT(-0400)] <michelled> that way the client doesn't have to have any knowledge about what can go where - I remember the rules for moving things around in uPortal are quite complex and it doesn't make sense to repeat these on the client.
[11:32:32 EDT(-0400)] <colinclark> So we're going with a two-staged approach. Gary was a bit intimidated by the layout and permissions data structures, and found the selector-based approach was more intuitive. Fair enough.
[11:32:55 EDT(-0400)] <colinclark> Michelle is working on an easy way to identify locked portlets using a selector, which will generate the necessary permissions object.
[11:33:18 EDT(-0400)] <colinclark> This is the version we'll use for Gary's user testing work.
[11:33:36 EDT(-0400)] <athena7> ok, i wondered why the difference between what i saw on the wiki and gary's code
[11:33:39 EDT(-0400)] <michelled> oh, now I get it.
[11:33:44 EDT(-0400)] <colinclark> After we're done this, we should look at the ideal way to integrate LayoutCustomizer into uPortal.
[11:33:51 EDT(-0400)] <colinclark> Using these JSON data structures.
[11:33:52 EDT(-0400)] <athena7> i'm not sure if selectors will be able to identify the full permissions
[11:34:10 EDT(-0400)] <athena7> but it may be that it's good enough and we can just punt on the more confusing functionality
[11:34:12 EDT(-0400)] <colinclark> athena7: The real question is whether the full permissions are necessary for the user testing.
[11:34:17 EDT(-0400)] <athena7> they're not
[11:34:18 EDT(-0400)] <michelled> ya, for the integration work you won't be able to use the 'simple layout reorderer'
[11:34:21 EDT(-0400)] <colinclark> athena7: That's what I was thinking. (smile)
[11:34:26 EDT(-0400)] <athena7> and we may just be able to ignore them more long-term
[11:34:39 EDT(-0400)] <athena7> it may be good enough to just say that immovable things are just immovable
[11:34:58 EDT(-0400)] <athena7> not immovable above things with a higher priority, which gives me a headache every time i think about it
[11:35:00 EDT(-0400)] <colinclark> So does this make sense? Step 1: Get a basic working version of LayoutCustomizer in uP3 for user testing.
[11:35:13 EDT(-0400)] <colinclark> Step 2: Look at the harder problems for the uP 3.1 release.
[11:35:17 EDT(-0400)] <athena7> yes, totally
[11:35:21 EDT(-0400)] <michelled> cool
[11:35:30 EDT(-0400)] <athena7> so my question was for persisting the layout changes
[11:35:45 EDT(-0400)] <athena7> from what i understand we'll want a little uportal-specific function to save changes
[11:35:55 EDT(-0400)] <colinclark> Yes, definitely.
[11:35:56 EDT(-0400)] <athena7> and give to the reorderer as a callback
[11:36:07 EDT(-0400)] <michelled> yup, that's right
[11:36:11 EDT(-0400)] <athena7> but if the callback only gets the new layout, not the changes, we'll have to infer the changes
[11:36:18 EDT(-0400)] <athena7> which is certainly possible, although it'll be a pain
[11:36:34 EDT(-0400)] <michelled> and actually, the callback doesn't get the new layout right now
[11:36:38 EDT(-0400)] <athena7> the uportal methods we need to hook into require us to send parameters indicating what moved and where it went
[11:36:41 EDT(-0400)] <michelled> all it gets is the thing that was moved
[11:36:44 EDT(-0400)] <athena7> oh!
[11:36:45 EDT(-0400)] <athena7> ok
[11:36:59 EDT(-0400)] <athena7> that may be a lot better then - what data exactly does it get?
[11:37:19 EDT(-0400)] <michelled> it gets the DOM element that was moved
[11:41:02 EDT(-0400)] <athena7> ok
[11:41:20 EDT(-0400)] <athena7> is that all documented somewhere?
[11:42:10 EDT(-0400)] <michelled> good point - the change to the order changed callback was done really late in the game and the docs may not be updated
[11:42:48 EDT(-0400)] <athena7> ok, i thought i'd just missed it (smile)
[11:43:00 EDT(-0400)] <athena7> how might one reference that info in the callback?
[11:43:00 EDT(-0400)] <michelled> anastasia_c said she'd fix that. Thanks for mentioning it!
[11:43:04 EDT(-0400)] <athena7> ok, cool
[11:43:32 EDT(-0400)] <michelled> you create your function and give your parameter any name you want.
[11:43:47 EDT(-0400)] <michelled> function (item) {}
[11:44:15 EDT(-0400)] <athena7> colin, i think it sounds like we could pull together a persistence mechanism fairly quickly
[11:44:55 EDT(-0400)] <colinclark> athena7: Awesome. (smile)
[11:45:15 EDT(-0400)] <athena7> do you need this for tomorrow?
[11:45:41 EDT(-0400)] <colinclark> athena7: Gary was hoping to have it ready for tomorrow.
[11:45:54 EDT(-0400)] <colinclark> michelled is free all day to lend a hand if you need it.
[11:46:18 EDT(-0400)] <athena7> ok
[11:46:26 EDT(-0400)] <athena7> i've got some time, so i'll work on it this afternoon
[11:46:39 EDT(-0400)] <athena7> it looks like i should be able to take the code gary sent to start off with
[11:46:56 EDT(-0400)] <athena7> did you see my note about the portlets getting added to the table cell rather than the div?
[11:49:09 EDT(-0400)] <colinclark> athena7: I did. I just have to run to a quick 15 minute meeting. Will you be here when I get back so I can ask more questions about it? (smile)
[11:49:23 EDT(-0400)] <athena7> i actually need to run an errand and find some lunch
[11:49:32 EDT(-0400)] <athena7> the wedding is saturday, have some last minute things to take care of (smile)
[11:49:43 EDT(-0400)] <athena7> but i'll be back in a half-hour/hour or so
[11:49:48 EDT(-0400)] <athena7> and here for the rest of the afternoon
[11:49:52 EDT(-0400)] <athena7> so maybe we can catch up then?
[11:51:14 EDT(-0400)] <colinclark> yes, totally
[11:52:20 EDT(-0400)] <athena7> ok
[11:52:23 EDT(-0400)] <athena7> talk to you soonish
[12:17:21 EDT(-0400)] <Bosmon> Where do people think is an appropriate place for the CSS describing the "little buttons" appearing next to a field for the undo feature for inline-edit?
[12:19:21 EDT(-0400)] <Bosmon> It seems a bit silly to put it in its own CSS file since typically it would just be one style
[12:19:31 EDT(-0400)] <Bosmon> On the other hand, it doesn't seem like it belongs in a "theme"...
[12:29:26 EDT(-0400)] <athena7> colinclark: when you're back, let me know
[12:29:28 EDT(-0400)] <athena7> (smile)
[13:15:41 EDT(-0400)] <michelled> athena7: what do you mean that the portlets are getting added to the table cell rather than the div?
[13:16:02 EDT(-0400)] <michelled> could I see the markup somewhere?
[13:16:30 EDT(-0400)] * apetro-- (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[13:17:12 EDT(-0400)] <athena7> here's gary's demo: http://mercury.unicon.net:8080/uPortal
[13:19:00 EDT(-0400)] <michelled> I'm getting a 'fluid is not defined' error - is this expected?
[13:20:42 EDT(-0400)] <michelled> If I'm understanding what you were asking, then I think the issue is that the column selector that's passed to the layout reorderer needs to find the divs rather then the tds
[13:20:51 EDT(-0400)] <michelled> does that make sense athena7?
[13:21:17 EDT(-0400)] <athena7> can you hang on a minute? on the phone w/ gary (smile)
[13:21:19 EDT(-0400)] <athena7> but yes i think so
[13:21:22 EDT(-0400)] <michelled> of course
[13:21:51 EDT(-0400)] <athena7> thanks!
[13:22:29 EDT(-0400)] <athena7> i think you need to log in to see the behavior - the guest view isn't really supposed to do drag and drop
[13:22:39 EDT(-0400)] <athena7> so we'll comment out that block in the guest version
[13:22:50 EDT(-0400)] <athena7> default logins like student/student should probably work
[13:30:11 EDT(-0400)] <michelled> thanks. I'm seeing them being added to the div
[13:30:35 EDT(-0400)] <michelled> did you fix it? or is my FireBug crazy?
[13:30:59 EDT(-0400)] <athena7> it's only when you move it to the very bottom of the column
[13:31:16 EDT(-0400)] <athena7> i assume that maybe using the div instead of the td in the constructor would fix it
[13:31:49 EDT(-0400)] <athena7> i can't quite figure out what's going on with my local version
[13:32:00 EDT(-0400)] <athena7> that one seems to work generally, but my local version won't let me drop anything
[13:32:33 EDT(-0400)] <michelled> weird - is it giving you an error?
[13:33:27 EDT(-0400)] <athena7> yes, lots of ui.element has no properties
[13:34:07 EDT(-0400)] <athena7> http://uportal.pastebin.com/m7051168
[13:34:09 EDT(-0400)] <athena7> from firebug
[13:36:31 EDT(-0400)] <athena7> odd
[13:37:46 EDT(-0400)] <michelled> ya, it looks like a jQuery DnD error but I don't know why
[13:38:33 EDT(-0400)] <michelled> also odd - when I try to recreate the other bug on Gary's instance Firefox crashes.
[13:38:37 EDT(-0400)] <athena7> :/
[13:38:47 EDT(-0400)] <athena7> are you playing with the google portlet?
[13:38:49 EDT(-0400)] <athena7> because that'll definitely do it
[13:39:06 EDT(-0400)] <michelled> oh, maybe. I won't this time
[13:39:36 EDT(-0400)] <athena7> it seems like the jquery drag and drop behaves pretty badly when the thing being dragged has document.write statements in it
[13:39:49 EDT(-0400)] <athena7> causes the page to reload on a white screen and then frequently crash the browser
[13:40:04 EDT(-0400)] <athena7> and unfortunately all the google apis use document.write statements
[13:41:05 EDT(-0400)] <michelled> yes, that's a known bug I opened against them. I haven't looked recently whether they've worked on it.
[13:41:24 EDT(-0400)] <michelled> (against jQuery not google)
[13:41:32 EDT(-0400)] <athena7> ah ok
[13:41:37 EDT(-0400)] <athena7> good to know it's at least logged
[13:41:44 EDT(-0400)] <athena7> it's made us very sad
[13:41:51 EDT(-0400)] <athena7> and keeps cropping up (sad)
[13:42:31 EDT(-0400)] <athena7> trying to do a diff to see if i have any changes since 3.0.1 that could be causing this weird behavior locally
[13:43:51 EDT(-0400)] <michelled> ya, it's really nasty. I came up in the first integration of the Reorderer in aTutor. They were able to change their code to use jquery.append instead and that worked
[13:44:37 EDT(-0400)] <athena7> ahh
[13:44:49 EDT(-0400)] <athena7> yeah we've changed code where we could to get around it
[13:44:55 EDT(-0400)] <athena7> but it's sad for the google apis
[13:44:57 EDT(-0400)] <michelled> here's the ticket in case you want to watch it but it looks like there's no progress. http://dev.jquery.com/ticket/2887
[13:45:07 EDT(-0400)] <michelled> for sure!
[13:45:12 EDT(-0400)] <athena7> and i think the problem exists with all the google javascript framework stuff too
[13:45:18 EDT(-0400)] <athena7> so it's not just using their search api or whatever
[13:45:24 EDT(-0400)] <athena7> which affects kuali, i think
[13:45:50 EDT(-0400)] <michelled> argh
[13:45:53 EDT(-0400)] <athena7> yeah
[13:51:58 EDT(-0400)] <athena7> shoot, i really can't figure out why this doesn't work
[13:57:12 EDT(-0400)] <michelled> I wonder if it would be easier with the non-minified file.
[14:00:57 EDT(-0400)] <athena7> dunno
[14:01:04 EDT(-0400)] <athena7> think there might be a conflict somewhere
[14:01:10 EDT(-0400)] <athena7> because gary's flyout menus don't work
[14:01:16 EDT(-0400)] <athena7> and mine do
[14:01:39 EDT(-0400)] <athena7> oh wow, yes, that's it
[15:17:03 EDT(-0400)] <athena7> i'm a little confused about the difference between the stuff i'm seeing on the wiki here http://wiki.fluidproject.org/display/fluid/Layout+Customizer+Integration+-+Layout+and+Permissions and the code gary wrote for uportal
[15:17:17 EDT(-0400)] <athena7> are there a couple different constructors or am i looking at a different version?
[15:35:45 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[15:36:44 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[15:58:12 EDT(-0400)] <athena7> i seem to be having some trouble with the fluid.initLayoutCustomizer function
[15:58:15 EDT(-0400)] <athena7> just kind of fails silently
[15:59:29 EDT(-0400)] <athena7> does the Fluid-all file include jquery itself?
[15:59:31 EDT(-0400)] <colinclark> athena7: How are you using it?
[15:59:36 EDT(-0400)] <colinclark> athena7: It does, yes.
[15:59:43 EDT(-0400)] <athena7> ok, that may be some of the problem
[16:00:00 EDT(-0400)] <colinclark> Fluid-all.js is arguably a bit heavy-handed, since it includes all of our dependencies.
[16:00:23 EDT(-0400)] <colinclark> One of our upcoming tasks is to continue to refine our build process so you can control what dependencies are packed up.
[16:00:30 EDT(-0400)] <athena7> gotcha
[16:00:52 EDT(-0400)] <athena7> so i'm trying to use fluid.initLayoutCustomizer(layout, perms, '', {});
[16:01:01 EDT(-0400)] <athena7> i don't know if it likes me ignoring the last two parameters
[16:01:42 EDT(-0400)] <colinclark> athena7: It should be fine. Although I would pass something falsey for those two arguments, just in case.
[16:01:53 EDT(-0400)] <athena7> ok, got something in mind?
[16:01:57 EDT(-0400)] <colinclark> So just call it like this: fluid.initLayoutCustomzier(layout, perms);
[16:02:03 EDT(-0400)] <athena7> ok, can do
[16:02:06 EDT(-0400)] <colinclark> (smile)
[16:02:23 EDT(-0400)] <colinclark> JavaScript is nice like that. If you omit an argument, it will be passed in as undefined.
[16:02:30 EDT(-0400)] <athena7> i don't know if something like that would be good enough for tomorrow
[16:03:10 EDT(-0400)] <colinclark> athena7: It might be. But I think Gary was hoping that the portal would remember the order of portlets.
[16:03:23 EDT(-0400)] <colinclark> How have you created the layout and perms objects?
[16:03:31 EDT(-0400)] <athena7> ok, i got the impression from talking to him this afternoon that he was less worried about that piece
[16:03:38 EDT(-0400)] <colinclark> I thought Gary was using the reorderLayout() API instead.
[16:03:52 EDT(-0400)] <colinclark> athena7: Aha. Perhaps we should check in with him just to make sure.
[16:04:04 EDT(-0400)] <athena7> yes, i need to get both of you at the same time (smile)
[16:04:14 EDT(-0400)] <colinclark> athena7: Shall I organize a SKype call?
[16:04:23 EDT(-0400)] <athena7> i think he's at a meeting until 4:30 or so
[16:04:39 EDT(-0400)] <athena7> i'm lacking an external microphone, so skype with me might be a little painful
[16:04:39 EDT(-0400)] <colinclark> athena7: Yeah, you're right. He said lunch. (smile)
[16:04:51 EDT(-0400)] <colinclark> athena7: Phone? IRC?
[16:05:00 EDT(-0400)] <athena7> but we can try it
[16:05:03 EDT(-0400)] <athena7> phone and irc are both good
[16:05:22 EDT(-0400)] <athena7> my last computer had a broken microphone port, so i got rid of my crappy microhpone (smile)
[16:05:52 EDT(-0400)] <colinclark> I have a USB headset that has become invaluable.
[16:06:03 EDT(-0400)] <colinclark> We do so much video conferencing and skyping and ichatting.
[16:06:25 EDT(-0400)] <athena7> yeah
[16:06:36 EDT(-0400)] <athena7> i should get a new one
[16:07:37 EDT(-0400)] <athena7> hm, here's the error i'm getting
[16:07:41 EDT(-0400)] <athena7> http://uportal.pastebin.com/m5cbdaf42
[16:08:09 EDT(-0400)] <colinclark> I'll take a look, one sec...
[16:08:29 EDT(-0400)] <athena7> does the reorderer require that the columns be top-level descendants of the container?
[16:08:51 EDT(-0400)] <colinclark> athena7: No, I don't think so.
[16:08:59 EDT(-0400)] <colinclark> We did our best to make it not care about the structure of the DOM at all.
[16:09:06 EDT(-0400)] <athena7> ok
[16:09:39 EDT(-0400)] <colinclark> Hmm... el.setAttributeNS is not a function
[16:09:50 EDT(-0400)] <colinclark> Just to be sure, what browser are you using?
[16:10:01 EDT(-0400)] <athena7> firefox 2
[16:10:09 EDT(-0400)] <athena7> or 2.5 or whatever the most recent flavor of 2 is
[16:10:53 EDT(-0400)] <colinclark> right
[16:11:12 EDT(-0400)] <colinclark> this is a sign of something very strange, since setAttributeNS() is a standard DOM method. (smile)
[16:11:14 EDT(-0400)] <colinclark> Not even jQuery.
[16:11:46 EDT(-0400)] <athena7> i sort of assumed it was lying and something else bad happened
[16:12:14 EDT(-0400)] <colinclark> yes, good assumption. (smile)
[16:12:24 EDT(-0400)] <colinclark> Can I see the page this is happening in?
[16:12:33 EDT(-0400)] <colinclark> Seems like a freak versioning or order issue, perhaps.
[16:12:36 EDT(-0400)] <athena7> unfortunately i don't have a public test instance to play with
[16:12:47 EDT(-0400)] <colinclark> ok, no problem.
[16:12:56 EDT(-0400)] <colinclark> What scripts are being imported in the document's head?
[16:12:56 EDT(-0400)] <athena7> although when gary comes back maybe we can get him to put it up on his public one
[16:13:10 EDT(-0400)] <athena7> fluid-all and the two uportal scripts
[16:13:29 EDT(-0400)] <colinclark> Very strange.
[16:13:36 EDT(-0400)] <athena7> i could try commenting those out
[16:13:48 EDT(-0400)] <athena7> already found some compatibility problems w/ the flyout one
[16:13:55 EDT(-0400)] <colinclark> that's too bad. (sad)
[16:14:10 EDT(-0400)] <colinclark> Out of curiosity, what type of DOM element is portlet_n7?
[16:14:43 EDT(-0400)] <athena7> a div
[16:14:49 EDT(-0400)] <colinclark> cool
[16:14:55 EDT(-0400)] <athena7> the column is a div inside of a table cell
[16:15:08 EDT(-0400)] <colinclark> gotcha
[16:15:12 EDT(-0400)] <colinclark> Did you create your own layout and perms objects?
[16:15:20 EDT(-0400)] <athena7> and the containing div is a table row
[16:15:21 EDT(-0400)] <athena7> yes
[16:15:27 EDT(-0400)] <colinclark> You're didn't end up using reorderLayout() instead?
[16:15:35 EDT(-0400)] <colinclark> "You didn't..."
[16:16:05 EDT(-0400)] <athena7> nope - here's the output in the source: http://uportal.pastebin.com/m76507d33
[16:16:13 EDT(-0400)] <athena7> i may well have missed something
[16:17:46 EDT(-0400)] <colinclark> i'm just looking, sorry for the delay
[16:18:03 EDT(-0400)] <athena7> ok, now i have no errors
[16:18:07 EDT(-0400)] <athena7> but can't drag anything either
[16:18:22 EDT(-0400)] <athena7> do i need to specify a drag handle or something?
[16:18:30 EDT(-0400)] * apetro--_ (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[16:18:33 EDT(-0400)] <colinclark> by default, it will use the whole portlet
[16:18:43 EDT(-0400)] <athena7> ok
[16:18:47 EDT(-0400)] <colinclark> But you can optionally specify a drag handle. It's uglier than I'd like at the moment. (sad)
[16:18:51 EDT(-0400)] <athena7> should i see a cursor indicator of draggyness?
[16:19:05 EDT(-0400)] <colinclark> Undoubtedly yes.
[16:19:07 EDT(-0400)] <colinclark> (smile)
[16:19:32 EDT(-0400)] <colinclark> Just out of curiosity, is it possible to identify your portlets with a selector? Do they have a class attached to them or anything?
[16:19:55 EDT(-0400)] <athena7> yes, they do
[16:20:05 EDT(-0400)] <athena7> and the movable ones have a movable selector
[16:21:23 EDT(-0400)] <colinclark> I wonder if you'd encounter the same issue using the reorderLayout() function instead, which takes selectors instead of layouts and perms. It generates them for you.
[16:21:57 EDT(-0400)] <colinclark> This is what Gary was using: fluid.reorderLayout ("#portalPageBodyColumns", {
[16:21:57 EDT(-0400)] <colinclark> columns: ".portal-page-column-inner",
[16:21:58 EDT(-0400)] <colinclark> modules: ".portlet-container "
[16:21:58 EDT(-0400)] <colinclark> });
[16:22:00 EDT(-0400)] <athena7> that one worked
[16:22:11 EDT(-0400)] <athena7> as long as we used portal-page-column rather than portal-page-column-inner
[16:22:14 EDT(-0400)] <colinclark> Right.
[16:22:31 EDT(-0400)] <athena7> i guess i could try switching the div to the table cell and see if that does anything friendly
[16:22:53 EDT(-0400)] <athena7> although of course that makes portlets fall out of the div
[16:22:57 EDT(-0400)] <colinclark> ah, I see.
[16:23:19 EDT(-0400)] <colinclark> So just so I understand the structure of your DOM here...
[16:23:36 EDT(-0400)] <colinclark> Columns are a div wrapped inside a table cell.
[16:23:44 EDT(-0400)] <colinclark> Portlets are divs within that column div?
[16:25:10 EDT(-0400)] * colinclark is going to look at the actual uP markup...
[16:25:11 EDT(-0400)] <athena7> yes
[16:25:26 EDT(-0400)] <athena7> tr -> tds
[16:25:34 EDT(-0400)] <athena7> td -> div -> lotso baby divs
[16:25:55 EDT(-0400)] <athena7> http://mercury.unicon.net:8080/uPortal/render.userLayoutRootNode.uP (have to log in)
[16:26:01 EDT(-0400)] <athena7> that has the simpler reorderer
[16:26:34 EDT(-0400)] <colinclark> Right. This is the version I saw before Gary went for lunch, which has a couple of quirks.
[16:26:39 EDT(-0400)] <colinclark> (wink)
[16:26:49 EDT(-0400)] <athena7> yes
[16:29:37 EDT(-0400)] <colinclark> So when you user using .portal-page-column-inner, what was happening?
[16:29:44 EDT(-0400)] <colinclark> I can't type...
[16:29:49 EDT(-0400)] <colinclark> "when you were using..."
[16:29:50 EDT(-0400)] <athena7> let me try it again
[16:30:34 EDT(-0400)] <athena7> oh hm, that seems to be working now
[16:30:38 EDT(-0400)] <colinclark> Curious.
[16:30:39 EDT(-0400)] <athena7> maybe some of that was a result of the other scripts
[16:30:42 EDT(-0400)] <colinclark> But good.
[16:30:46 EDT(-0400)] <athena7> yes
[16:30:54 EDT(-0400)] <athena7> so that all seems to be functioning as expected
[16:31:00 EDT(-0400)] <colinclark> It sure beats having to create your own layout and perms, which is a drag.
[16:31:05 EDT(-0400)] <colinclark> Only a Portal should have to do that. (tongue)
[16:31:30 EDT(-0400)] <athena7> yeah
[16:31:31 EDT(-0400)] <athena7> totally
[16:32:02 EDT(-0400)] <colinclark> So Michelle's pending patch will allow you to identify locked portlets, and then the reorderLayout() function will compute all of those objects for you.
[16:32:03 EDT(-0400)] <athena7> ok, so any thoughts about what might be happening with the other version?
[16:32:14 EDT(-0400)] <athena7> ah, interesting
[16:32:24 EDT(-0400)] <colinclark> The one that's using initLayoutCustomizer(), you mean?
[16:32:25 EDT(-0400)] <athena7> that'd cover most of the real use cases
[16:32:28 EDT(-0400)] <athena7> yeah
[16:32:29 EDT(-0400)] <colinclark> That
[16:32:42 EDT(-0400)] <athena7> if we could just mark the locked ones, i think we'd be well on our way
[16:32:47 EDT(-0400)] <colinclark> I'm figuring it's something with the layout object. Let me take a closer look.
[16:32:56 EDT(-0400)] <athena7> it wouldn't address the locked but not really but prioritied stuff
[16:33:01 EDT(-0400)] <colinclark> athena7: Yep, that's what I was thinking. Michelle is just about finished with that feature.
[16:33:02 EDT(-0400)] <athena7> but that may not be the end of the world
[16:33:05 EDT(-0400)] <athena7> ok, cool
[16:33:16 EDT(-0400)] <colinclark> Yeah, that seems to be Gary's sense. Not a huge deal.
[16:33:19 EDT(-0400)] <athena7> yeah
[16:33:30 EDT(-0400)] <athena7> to be honest, that's kind of the state the tabs are in
[16:33:47 EDT(-0400)] <colinclark> When we look at doing this for real in uP3, we can talk about whether we should get the portal to generate those JSON objects for us.
[16:33:49 EDT(-0400)] <athena7> if they say they aren't movable, you just can't move them
[16:33:54 EDT(-0400)] <athena7> yeah
[16:34:07 EDT(-0400)] <athena7> so what can i do for you today to help?
[16:34:50 EDT(-0400)] <colinclark> Wiring up the callback so the portal knows about the order changing would be great.
[16:34:53 EDT(-0400)] <colinclark> Do yout hink it's feasible.
[16:34:54 EDT(-0400)] <colinclark> ?
[16:35:42 EDT(-0400)] <athena7> yes, i think so
[16:35:53 EDT(-0400)] <athena7> what exactly is the format of the callback?
[16:35:59 EDT(-0400)] <athena7> looking at the docs, that's a callback url?
[16:36:35 EDT(-0400)] <athena7> and is there a place to stick that into the constructor?
[16:38:17 EDT(-0400)] <colinclark> one sec, sorry
[16:38:21 EDT(-0400)] <athena7> sure
[16:38:23 EDT(-0400)] <colinclark> too many distractions...
[16:38:30 EDT(-0400)] <colinclark> we are on the verge of the 0.4 release today. (smile)
[16:38:33 EDT(-0400)] <colinclark> so there are lots of questions for me
[16:39:50 EDT(-0400)] <athena7> ah (smile)
[16:39:55 EDT(-0400)] <athena7> yeah i'm sure things are crazy
[16:40:43 EDT(-0400)] <athena7> i was already planning to work late tonight, so if we can get me the right tasks and documentation, i do have some time to help today
[16:41:43 EDT(-0400)] <colinclark> athena7: Do you want to check in with me and Gary real quick on breeze? I'll grab you the URL.
[16:42:02 EDT(-0400)] <athena7> oh sure
[16:42:09 EDT(-0400)] <athena7> didn't realize he was back now
[16:42:28 EDT(-0400)] <colinclark> he just got back
[16:42:40 EDT(-0400)] <colinclark> we do "walkie-talkie" style breeze, so your lack of good microphone should be okay.
[16:42:48 EDT(-0400)] <colinclark> you have some kind of built-in one, right?
[16:43:09 EDT(-0400)] <colinclark> http://breeze.yorku.ca/fluidwork
[16:43:37 EDT(-0400)] <athena7> yep
[17:07:54 EDT(-0400)] <athena7> ok, the version i have seems to expect a function, rather than a url
[17:35:04 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has left #fluid-work
[17:44:05 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-74.LIPS.Berkeley.EDU) has joined #fluid-work
[18:19:52 EDT(-0400)] * apetro_mac (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[21:56:54 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279722600.dsl.bell.ca) has joined #fluid-work