fluid-work IRC Logs-2008-08-21

Owned by Fluid IRC Log Bot
Last updated: Aug 21, 2008Version comment
28 min read

[06:50:49 EDT(-0400)] * jacobfarber (n=Jacob@142.150.154.106) has joined #fluid-work
[08:31:17 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[08:58:50 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[09:05:02 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[10:40:14 EDT(-0400)] * lessthanzero (n=lessthan@CPE0017f2e4e4f6-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work
[10:40:17 EDT(-0400)] <lessthanzero> Colin?
[10:40:19 EDT(-0400)] <lessthanzero> I mean...
[10:40:22 EDT(-0400)] <lessthanzero> msg me
[10:40:23 EDT(-0400)] <lessthanzero> (smile)
[10:53:35 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279336033.dsl.bell.ca) has joined #fluid-work
[10:53:43 EDT(-0400)] <lessthanzero> (smile)
[10:53:44 EDT(-0400)] <lessthanzero> there ya go.
[10:54:08 EDT(-0400)] <colinclark> anastasiac, jacobfarber, Justin_o, michelled: I want to introduce you to lessthanzero.
[10:54:19 EDT(-0400)] <colinclark> His name is Blake, and he's working on the web module for the OpenVULab.
[10:54:30 EDT(-0400)] <lessthanzero> That I am.
[10:54:37 EDT(-0400)] <anastasiac> welcome, lessthanzero
[10:54:42 EDT(-0400)] <colinclark> The VULab guys are making a push to get more involved and visible in the community, which is awesome.
[10:54:44 EDT(-0400)] <michelled> Hi Blake, nice to meet you
[10:54:44 EDT(-0400)] <jacobfarber> Hello!
[10:54:45 EDT(-0400)] <lessthanzero> anastasiac: hello hello.
[10:54:53 EDT(-0400)] <Justin_o> lessthanzero: hello
[10:54:54 EDT(-0400)] <colinclark> So it's great to have lessthanzero here in the channel.
[10:55:16 EDT(-0400)] <colinclark> lessthanzero: We tend to talk a lot of jQuery here, so hopefully it will be interesting to you.
[10:55:21 EDT(-0400)] <colinclark> We can always use your feedback and ideas.
[10:55:51 EDT(-0400)] <lessthanzero> /whois lessthanzero
[10:55:53 EDT(-0400)] <lessthanzero> (wink)
[10:55:55 EDT(-0400)] <lessthanzero> I love jquerty.
[10:56:05 EDT(-0400)] <lessthanzero> *jquery
[10:56:11 EDT(-0400)] <michelled> yes, it makes life so much easier
[10:56:12 EDT(-0400)] <michelled> (smile)
[10:56:19 EDT(-0400)] <lessthanzero> I refuse to getElementByID again.
[10:56:27 EDT(-0400)] <colinclark> (smile)
[10:56:48 EDT(-0400)] <lessthanzero> have you guys seen: http://code.google.com/p/phpquery ?
[10:56:51 EDT(-0400)] <lessthanzero> jquery for php basically.
[10:57:07 EDT(-0400)] <lessthanzero> I had to use an older version, but it works beautifully. (css selectors for php!)
[10:57:35 EDT(-0400)] <colinclark> Awesome.
[10:57:38 EDT(-0400)] <lessthanzero> VERY awesome.
[11:01:52 EDT(-0400)] <michelled> what to people think of the new 'good part' option in jsLint: "allow only one var statement per functions"? It basically promotes a style where the first line of a function is a var statement that declares all the variables in the function. Setting the variables would happen throughout the function.
[11:01:59 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined #fluid-work
[11:02:37 EDT(-0400)] <michelled> I suppose it makes function scoping really clear and should thus avoid bugs
[11:03:20 EDT(-0400)] <colinclark> michelled: I assume that is it's intention, yes.
[11:03:48 EDT(-0400)] <colinclark> Crockford's advocating a kind of rigor around not forgetting the scoping rules in JavaScript by ensuring that variables are always defined up-front.
[11:04:31 EDT(-0400)] <colinclark> I think it's a language bug, given the fact that nothing but functions have scope, that the language doesn't throw an error when you declare variables throughout a function.
[11:04:45 EDT(-0400)] <colinclark> But I will confess, sheepishly, that I've never picked up the style.
[11:04:56 EDT(-0400)] <colinclark> var foo, bar, baz, boo; // Is this what JSLint is forcing you to do?
[11:05:04 EDT(-0400)] <jacobfarber> colinclark, michelled: do you mean var a,b,c; ?
[11:05:08 EDT(-0400)] <colinclark> (smile)
[11:05:10 EDT(-0400)] <jacobfarber> at the first line?
[11:05:19 EDT(-0400)] <michelled> yup
[11:05:34 EDT(-0400)] <michelled> I like the convenience when jsLinting files of 'good parts' + 'assume a browser' so I guess we'll see if I get used to it (smile)
[11:05:39 EDT(-0400)] <colinclark> (smile)
[11:05:57 EDT(-0400)] <colinclark> It's a good way to force you to keep your functions small...
[11:05:59 EDT(-0400)] <colinclark> imagine this
[11:06:09 EDT(-0400)] <colinclark> var a, b, c, d, e, f, g, h, i, j, k;
[11:06:12 EDT(-0400)] <colinclark> (tongue)
[11:06:17 EDT(-0400)] <jacobfarber> eactly
[11:06:28 EDT(-0400)] <colinclark> Plus assigning values to them by default.
[11:06:29 EDT(-0400)] <jacobfarber> its a little note to recycle what you have, and make good use of it
[11:06:35 EDT(-0400)] <colinclark> (smile)
[11:06:37 EDT(-0400)] <colinclark> Yep.
[11:06:51 EDT(-0400)] <colinclark> Crockford must have just added that feature.
[11:07:01 EDT(-0400)] <colinclark> Since I JSLinted code yesterday that didn't follow this pattern.
[11:07:09 EDT(-0400)] <jacobfarber> although, with JSLint I never really thought that hard about the problesm with "=="
[11:07:21 EDT(-0400)] <jacobfarber> I always thought that was safe....oh well
[11:07:23 EDT(-0400)] <colinclark> (smile)
[11:07:31 EDT(-0400)] <colinclark> That's what JSLint is good for...
[11:07:39 EDT(-0400)] <michelled> well, you could easily assign default values later. the code I was just linting changed from: var fluidLightboxDOMNode = document.getElementById(lightboxRootId);
[11:07:40 EDT(-0400)] <michelled> var lightboxParent = document.getElementById(lightboxParentId);
[11:07:55 EDT(-0400)] <michelled> to: var fluidLightboxDOMNode, lightboxParent;
[11:07:55 EDT(-0400)] <michelled>
[11:07:56 EDT(-0400)] <michelled> fluidLightboxDOMNode = document.getElementById(lightboxRootId);
[11:07:56 EDT(-0400)] <michelled> lightboxParent = document.getElementById(lightboxParentId);
[11:07:56 EDT(-0400)] <colinclark> If you don't want to understand the nature of the various bugs, you can just do what JSLint tells you to. (wink)
[11:08:10 EDT(-0400)] <colinclark> michelled: That's what I would have suggested. Nice.
[11:08:21 EDT(-0400)] <colinclark> So I want to show you guys this new UploadManager code...
[11:08:29 EDT(-0400)] <colinclark> but I need to get the tests working better.
[11:08:36 EDT(-0400)] <colinclark> So I'm going to disappear for an hour or so.
[11:08:43 EDT(-0400)] <michelled> ok, see you soon
[11:08:43 EDT(-0400)] <colinclark> Hey, before I go...
[11:08:52 EDT(-0400)] <colinclark> michelled: FLUID-1285 is a really interesting one.
[11:09:00 EDT(-0400)] <colinclark> I started to comment on it with a sort of superficial suggestion.
[11:09:06 EDT(-0400)] <colinclark> But it points to an interesting problem....
[11:09:09 EDT(-0400)] <michelled> yes
[11:09:23 EDT(-0400)] <colinclark> There's essentially two totally different modes for the Layout Customizer.
[11:09:40 EDT(-0400)] <michelled> yes
[11:09:48 EDT(-0400)] <colinclark> And now that our API is very consistent, people are going to go looking for a familiar function name to instantiate the LayoutCustomizer...
[11:10:01 EDT(-0400)] <colinclark> var myLayoutCustomizer = fluid.layoutCustomizer();
[11:10:20 EDT(-0400)] <michelled> well, and interestingly they could use fluid.reorderLayout
[11:10:22 EDT(-0400)] <colinclark> So I'm beginning to think that the current initLayoutCustomizer() should be renamed something like this...
[11:10:31 EDT(-0400)] <colinclark> fluid.dataDrivenLayoutCustomizer();
[11:10:34 EDT(-0400)] <colinclark> Not exactly succinct.
[11:10:37 EDT(-0400)] <colinclark> But very explicit.
[11:10:41 EDT(-0400)] <michelled> true
[11:10:56 EDT(-0400)] <colinclark> And then perhaps move reorderLayout() to layoutCustomizer().
[11:11:05 EDT(-0400)] <colinclark> But then we lose the symmetry of the various reorder*() functions.
[11:11:12 EDT(-0400)] * colinclark sighs.
[11:11:48 EDT(-0400)] <michelled> ya, I wasn't sure what to do with that API - that's why I punted it to you (tongue)
[11:11:54 EDT(-0400)] <colinclark> gee, thanks.
[11:11:56 EDT(-0400)] <colinclark> (tongue)
[11:12:12 EDT(-0400)] <michelled> perhaps bosmon will have an opinion next week
[11:12:23 EDT(-0400)] <colinclark> We could flip around the various reorder*() functions, but I fear that people will perceive it as gratuitous change.
[11:12:26 EDT(-0400)] <colinclark> so something like this:
[11:12:47 EDT(-0400)] <colinclark> layoutCustomizer(container, options); listReorderer(container, options); gridReorderer(container, options);
[11:13:17 EDT(-0400)] <michelled> well, and I like 'reorderList' etc. plus they are shorter
[11:13:27 EDT(-0400)] <colinclark> yep, me too
[11:13:32 EDT(-0400)] <colinclark> I'm tempted just to alias reorderLayout() to layoutCustomizer();
[11:13:44 EDT(-0400)] <colinclark> Then we don't break the API.
[11:13:48 EDT(-0400)] <michelled> that's possible
[11:14:06 EDT(-0400)] <colinclark> It's scary writing frameworks. (wink)
[11:14:12 EDT(-0400)] <michelled> (smile)
[11:15:02 EDT(-0400)] <colinclark> Certainly, I'd advocate for renaming initLayoutCustomizer() to dataDrivenLayoutCustomizer() if you think that's a reasonable name.
[11:15:15 EDT(-0400)] <colinclark> anastasiac: Do you have any thoughts on the issue?
[11:15:29 EDT(-0400)] * anastasiac reads back to catch up...
[11:16:12 EDT(-0400)] <colinclark> The last option would be do method overloading...
[11:16:23 EDT(-0400)] <colinclark> A single layoutCustomizer() function.
[11:16:55 EDT(-0400)] <colinclark> But that will take, as its first argument, either an object containing layout and perms, or a jQuery instance, or a selector string.
[11:17:09 EDT(-0400)] <colinclark> Either of the latter two arguments would be interpreted as the markup-driven layout customizer.
[11:17:38 EDT(-0400)] <anastasiac> I'm all for consistency in naming - for things that are consistent
[11:17:40 EDT(-0400)] <michelled> or we could just make layout and perms options and always require a container
[11:17:56 EDT(-0400)] <colinclark> Why doesn't the data-driven layout customizer take a container?
[11:18:05 EDT(-0400)] <colinclark> That's a good point, michelled.
[11:18:06 EDT(-0400)] <michelled> it's specified in the layout
[11:18:07 EDT(-0400)] <anastasiac> If reorderLayout() is similar in concept and simplicity to reorderList() then it makes sense for it to exist
[11:18:21 EDT(-0400)] <colinclark> anastasiac: I agree.
[11:18:32 EDT(-0400)] <anastasiac> the data-driven initialization is a pretty different beast, and so warrants a different kind of name
[11:18:53 EDT(-0400)] <colinclark> Now I'm beginning to doubt whether the reorder*() functions even need to be made consistent with a typical component creator function. (sad)
[11:19:08 EDT(-0400)] <colinclark> anastasiac: Does dataDrivenLayoutCustomizer() seem reasonable?
[11:19:12 EDT(-0400)] <michelled> well, but if it's an option, people don't need to know or care unless they want that type of flexibility anastasiac
[11:19:33 EDT(-0400)] <michelled> colinclark - I think they do.
[11:19:46 EDT(-0400)] <colinclark> michelled: What's your rationale?
[11:19:51 EDT(-0400)] <colinclark> I mean, I can see it both ways.
[11:19:53 EDT(-0400)] <anastasiac> colinclark, dataDrivenLayoutCustomizer() makes sense to me, as a version of a creator function
[11:19:53 EDT(-0400)] <michelled> it's so much easier to just think 'container, options' what where those options again?
[11:19:59 EDT(-0400)] <michelled> easy to look up those
[11:20:13 EDT(-0400)] <colinclark> In one sense, they are creator functions... in another sense, you can think of them as super-simple, quick convenience functions for getting a reorderer.
[11:20:22 EDT(-0400)] <colinclark> michelled: Yep, I hear you.
[11:20:58 EDT(-0400)] <colinclark> I think I'd prefer an explicit function name rather than an "either/or" configuration in the options.
[11:21:14 EDT(-0400)] <colinclark> What would we do if we got both a layout alongside a set of selectors?
[11:21:33 EDT(-0400)] <anastasiac> I agree - different forms of a function should have different names - more clear, easier to understand the docs
[11:21:34 EDT(-0400)] <michelled> I think we'd have to decide what wins - I'd pick the layout
[11:22:14 EDT(-0400)] <michelled> anastasiac: I certainly defer to you when it comes to communicating this stuff. (smile)
[11:23:23 EDT(-0400)] <colinclark> So there seems to be three options on the table:
[11:23:43 EDT(-0400)] <colinclark> 1. Two different functions... say, dataDrivenLayoutCustomizer() and just plain old layoutCustomizer().
[11:24:18 EDT(-0400)] <colinclark> 2. Overloading: a single layoutCustomizer() function that either takes a container (jquery or selector string) or a simple hash containing a layout and a perms object.
[11:24:49 EDT(-0400)] <colinclark> 3. Options stuff: user either supplies a container and set of selectors, or a layout and perms. In the case of getting both, we pick.
[11:25:02 EDT(-0400)] <colinclark> Does that seem like a reasonable summary?
[11:25:07 EDT(-0400)] <colinclark> michelled, anastasiac: ^
[11:25:38 EDT(-0400)] * anastasiac reconsiders two different function names
[11:25:42 EDT(-0400)] <michelled> yes
[11:25:51 EDT(-0400)] <anastasiac> yes, that's a good summary
[11:26:02 EDT(-0400)] <anastasiac> for option 3, would you still pass (container, options)?
[11:26:11 EDT(-0400)] <michelled> ye
[11:26:14 EDT(-0400)] <michelled> yes, i think
[11:26:21 EDT(-0400)] <michelled> for consistency
[11:26:26 EDT(-0400)] <anastasiac> good
[11:26:41 EDT(-0400)] <colinclark> I'll try to show how each scenario might be used...
[11:26:45 EDT(-0400)] <michelled> I like 1 or 3 and I'm leaning toward 1.
[11:27:03 EDT(-0400)] <colinclark> 1a. var myLC = dataDrivenLayoutCustomizer(layout, perms, options);
[11:27:11 EDT(-0400)] <anastasiac> I agree that 1 and 3 are better than 2
[11:27:16 EDT(-0400)] <colinclark> 1b. var myLC = layoutCustomizer("#foo", options);
[11:27:42 EDT(-0400)]

<colinclark> 2a. var myLC = layoutCustomizer(

Unknown macro: {layout}

, options);


[11:27:55 EDT(-0400)] <colinclark> 2b. var myLC = layoutCustomizer("#foo", options);
[11:28:33 EDT(-0400)]

<colinclark> 3a. var myLC = layoutCustomizer("#foo",

Unknown macro: {layout}

);


[11:29:08 EDT(-0400)] <colinclark> 3b. var myLC = layoutCustomizer("#foo", {selectors: {columns: ".column", portlets: ".portlet"}});
[11:29:24 EDT(-0400)] <colinclark> michelled, anastasiac: Does that make sense?
[11:29:31 EDT(-0400)] <michelled> yes
[11:30:28 EDT(-0400)] <colinclark> I actually like 2 better than 3.
[11:31:02 EDT(-0400)] <colinclark> And maybe scenario #1 is most explicit.
[11:31:21 EDT(-0400)] <colinclark> anastasiac: Any further thoughts?
[11:31:24 EDT(-0400)] <michelled> I issue with 2 is communicating it out.
[11:31:33 EDT(-0400)] <michelled> so 1 is the most clear
[11:31:39 EDT(-0400)] * anastasiac is cursed with the ability to understand many points of view
[11:32:44 EDT(-0400)] <anastasiac> michelled, regarding documenting option 2, I don't think that would be too difficult.
[11:32:56 EDT(-0400)] <anastasiac> conceptually, the first paramater identifies the container
[11:33:05 EDT(-0400)] <anastasiac> there are just two different ways of identifying it (smile)
[11:33:47 EDT(-0400)] <michelled> well, but layout and perms is much more then the container - as you well know for having documented it (smile)
[11:34:08 EDT(-0400)] <anastasiac> yes, that's true - it is more...
[11:34:48 EDT(-0400)] <anastasiac> Now I'm leaning away from 1
[11:35:01 EDT(-0400)] <anastasiac> colinclark, what's your thinking on preferring 2 to 3?
[11:35:24 EDT(-0400)] <colinclark> anastasiac: Well, in a sense they're both overloading...
[11:35:29 EDT(-0400)] <anastasiac> right
[11:35:34 EDT(-0400)] <colinclark> Option three is overloading inside the options.
[11:35:38 EDT(-0400)] <anastasiac> right
[11:35:39 EDT(-0400)] <colinclark> Which seems a bit more indirect.
[11:35:44 EDT(-0400)] <anastasiac> true
[11:35:50 EDT(-0400)] <colinclark> Also, the need to redundantly specify a container in option 3 seems odd.
[11:36:05 EDT(-0400)] <colinclark> Since I presume we'd just completely ignore it if we received a layout option.
[11:36:12 EDT(-0400)] <colinclark> michelled: Is that what you were thinking?
[11:37:19 EDT(-0400)] <michelled> well, I was thinking of not ignoring the container but then, of course, it would be ignored in the layout.
[11:37:44 EDT(-0400)] <michelled> we had wanted to change the way layout is specified anyway because of the reliance on ids
[11:38:12 EDT(-0400)] <anastasiac> ok, how about this line of thinking? my thinking to date has been that the options are meant to allow customization - changes to the default behaviour
[11:38:25 EDT(-0400)] <anastasiac> is using layout and perms conceptually a form of customization?
[11:38:33 EDT(-0400)] <anastasiac> i.e. does it belong in the options?
[11:39:30 EDT(-0400)] <michelled> it is now - the default behaviour is to allow for locking of modules at the top of columns - the layout and perms allows for locking and precedence.
[11:39:37 EDT(-0400)] <colinclark> Well, the other thing the options is useful for is the fact that there will be good defaults.
[11:39:50 EDT(-0400)] <colinclark> But I think it's impossible for us to have a default layout and perms?
[11:39:59 EDT(-0400)] <anastasiac> right - michelled just implemented defaults
[11:40:03 EDT(-0400)] <michelled> not if there are selectors
[11:40:41 EDT(-0400)] <colinclark> hmmm
[11:40:49 EDT(-0400)] <colinclark> so in a sense, there's a single layout customizer...
[11:41:01 EDT(-0400)] <michelled> yes
[11:41:07 EDT(-0400)] <colinclark> that has sensible defaults. those defaults are to simply use selectors
[11:41:21 EDT(-0400)] <colinclark> the alternative to those selectors is to supply a layout
[11:41:30 EDT(-0400)] <colinclark> the issue of permissions is somewhat separate...
[11:41:36 EDT(-0400)] <anastasiac> right - and just as you have the option of overriding the selectors with your own selectors...
[11:41:45 EDT(-0400)] <anastasiac> you could override the selectors with layout/perms
[11:41:47 EDT(-0400)] <colinclark> in that it's perfectly reasonable to use selectors for identifying the layout, but actually providing a real perms object.
[11:42:08 EDT(-0400)] <michelled> well, you could but I wouldn't want to try
[11:42:11 EDT(-0400)] <colinclark> so, in a sense, we're asking the user to override the selectors option with a layout
[11:42:12 EDT(-0400)] <anastasiac> Does the code work now if you only provide perms?
[11:42:29 EDT(-0400)] <anastasiac> i.e. use the default selectors, not providing a layout object
[11:42:31 EDT(-0400)] <michelled> I doubt it - but it wouldn't take a lot to fix it
[11:43:01 EDT(-0400)] <anastasiac> so right now, if you want perms, you have to write a layout obj
[11:43:14 EDT(-0400)] <michelled> I don't know for sure.
[11:43:33 EDT(-0400)] * anastasiac ponders
[11:43:40 EDT(-0400)] <colinclark> so a fourth scenario is emerging...
[11:44:27 EDT(-0400)] * Topic is 'Layout Customizer API' set by anastasiac on 2008-08-21 11:44:27 EDT(-0400)
[11:44:43 EDT(-0400)]

<colinclark> 4a. var myLC = layoutCustomizer("#container",

Unknown macro: {selectors}

);


[11:45:21 EDT(-0400)] <colinclark> 4b. var myLC = layoutCustomizer("#container", {selectors: {portlets: ".portlet", columns: ".column"}});
[11:45:26 EDT(-0400)] <anastasiac> oh, no - if a layout object is being provided, I wouldn't call it "selectors" -that'd be confusing
[11:45:31 EDT(-0400)] <colinclark> (smile)
[11:45:39 EDT(-0400)] <colinclark> But that was your point!
[11:45:46 EDT(-0400)] <colinclark> That we're overloading selectors with a layout object.
[11:45:50 EDT(-0400)] <colinclark> (tongue)
[11:46:02 EDT(-0400)] <anastasiac> well, I wasn't trying to make that point :-P
[11:46:40 EDT(-0400)] <anastasiac> We'd need two different mutually exclusive options, selectors and layout, and rules as to which one is used if both are provided
[11:46:56 EDT(-0400)] <anastasiac> I think, at least
[11:47:00 EDT(-0400)] <anastasiac> other opinions?
[11:47:48 EDT(-0400)] <colinclark> The risk there is that we're representing an "or" situation with an "and," if you know what I mean.
[11:48:00 EDT(-0400)] <michelled> so that is option 3
[11:48:01 EDT(-0400)] <anastasiac> yes, I know - and it's not ideal
[11:48:22 EDT(-0400)] <anastasiac> right, michelled, with the difference that perms is pulled out
[11:48:33 EDT(-0400)] <anastasiac> i.e. you should be able to use perms with selectors
[11:48:37 EDT(-0400)] * colinclark is eating cereal while he thinks.
[11:48:38 EDT(-0400)] <anastasiac> (right?)
[11:48:54 EDT(-0400)] <michelled> ya, I don't see why not.
[11:49:06 EDT(-0400)] <colinclark> anastasiac: Yes. We can treat that as a separate issues, but it's a good point.
[11:49:28 EDT(-0400)] <colinclark> You should be able to use a layout with no perms, or selectors with perms, or any reasonable combination.
[11:50:51 EDT(-0400)] * Topic is 'Consistency is the hobgoblin of lesser minds. (tongue)' set by colinclark on 2008-08-21 11:50:51 EDT(-0400)
[11:51:12 EDT(-0400)] * anastasiac wonders if she should be offended by the new topic
[11:51:19 EDT(-0400)] <colinclark> lol
[11:51:43 EDT(-0400)] * Topic is 'Consistent and symmetrical APIs are a joy to use.' set by colinclark on 2008-08-21 11:51:43 EDT(-0400)
[11:51:49 EDT(-0400)] <anastasiac> LOL
[11:52:16 EDT(-0400)] <colinclark> If only the world were symmetrical.
[11:52:37 EDT(-0400)] <anastasiac> I wonder if we should paper-prototype user-test these api options (smile)
[11:52:46 EDT(-0400)] <colinclark> it wouldn't hurt
[11:53:05 EDT(-0400)] <colinclark> do we have any momentum one way or another, or should i just make an executive decision?
[11:53:53 EDT(-0400)] <anastasiac> that might depend on your decision (smile)
[11:54:08 EDT(-0400)] <colinclark> lol
[11:54:12 EDT(-0400)] <michelled> perhaps put the options on the issue and we'll talk about it next week with bosmon?
[11:54:26 EDT(-0400)] <michelled> I'm not sure if he's already started to address some of this in his branch
[11:54:35 EDT(-0400)] <anastasiac> ah, good point michelled
[11:54:43 EDT(-0400)] <colinclark> (tongue)
[11:54:53 EDT(-0400)] <colinclark> does that mean I can go back to being invisible?
[11:55:01 EDT(-0400)] <michelled> yup
[11:55:04 EDT(-0400)] <colinclark> for the record, my vote would have been for #3.
[11:55:22 EDT(-0400)] <michelled> interesting
[11:55:26 EDT(-0400)] <colinclark> A single layoutCustomizer() API that had options for selectors and layout.
[11:55:34 EDT(-0400)] <michelled> can you throw the options onto the issues please colinclark?
[11:55:34 EDT(-0400)] <colinclark> If we get a layout, we'll use it.
[11:55:44 EDT(-0400)] <anastasiac> I was leaning to that too (with perms pulled out)
[11:57:27 EDT(-0400)] * athena7 (n=athena7@adsl-99-149-83-32.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[12:00:01 EDT(-0400)] <colinclark> michelled: Done. http://issues.fluidproject.org/browse/FLUID-1285
[12:00:13 EDT(-0400)] <colinclark> I added you, anastasiac, and bosmon as watchers on the issue.
[12:00:25 EDT(-0400)] <anastasiac> cool, thanks colinclark
[12:00:44 EDT(-0400)] <michelled> thanks so much!
[12:01:04 EDT(-0400)] * colinclark flaps his cape and attempts to disappear. (tongue)
[12:01:11 EDT(-0400)] <michelled> lol
[12:01:16 EDT(-0400)] <colinclark> ..or whatever super heroes do to become invisible.
[12:01:29 EDT(-0400)] <colinclark> Command-Q, I guess. (tongue)
[12:18:23 EDT(-0400)] * simonwang (n=chatzill@swang.itservices.ubc.ca) has joined #fluid-work
[12:18:36 EDT(-0400)] <simonwang> Hello justin_o
[12:23:31 EDT(-0400)] <Justin_o> simonwang: hello
[12:23:57 EDT(-0400)] <simonwang> I'd like to confirm the issue with IE6.
[12:24:35 EDT(-0400)] <Justin_o> yes...
[12:25:05 EDT(-0400)] <Justin_o> what would you like to confirm
[12:25:29 EDT(-0400)] <simonwang> When use IE6, the drop marker changes to very big. Is this what you see?
[12:26:06 EDT(-0400)] <Justin_o> no.. what i see is there is no drop marker at all below the last item in the list.. can you send me a screenshot
[12:27:32 EDT(-0400)] <simonwang> What I meant was that the drop marker is tall in other lines in the page.
[12:28:10 EDT(-0400)] <Justin_o> hmm. shouldn't be.. that was fixed.. are you running off of the daily build site or a local version
[12:29:23 EDT(-0400)] <simonwang> I copied from the daily build site. I will try the daily build site.
[12:29:45 EDT(-0400)] <Justin_o> okay.. please let me know if you are seeing something different there
[12:32:34 EDT(-0400)] <Justin_o> simonwang: did you happen to see the bug parade e-mail i sent to the fluid-work-list the othere day
[12:32:57 EDT(-0400)] <simonwang> I saw it.
[12:34:06 EDT(-0400)] <Justin_o> There are some other issues there that you can look at as well, when you finish this one or want to do something different.
[12:35:32 EDT(-0400)] <simonwang> I checked the daily build site, the drop marker is not tall now. The fix was done in changing font-size to 0px the CSS file.
[12:36:07 EDT(-0400)] <Justin_o> okay that's good.. did you notice the issue with no drop marker below the last list item
[12:37:07 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279336033.dsl.bell.ca) has joined #fluid-work
[12:38:29 EDT(-0400)] <simonwang> I noticed this, and I think this probably is not a bug in the code. If you change the height to 20px in the todo-list.css, you will have the same issue in IE 7 and Firefox.
[12:40:05 EDT(-0400)] <simonwang> The reason is that when a user drags a component from above the last component, the drop marker appears before the last component first.
[12:42:42 EDT(-0400)] <simonwang> When the user continues dragging down, when the drop marker is supposed to appear after the last component, the last component moves up and the mouse now is out of the drop site, and then the drop marker disappeared.
[12:44:53 EDT(-0400)] <michelled> simonwang, Justin_o: I'm seeing the bug in IE6. it's true that when I'm below all of the items and hovering over whitespace I wouldn't expect to see a drop marker
[12:45:10 EDT(-0400)] <michelled> however, when I'm over the last item and in position to drop, I should see a drop marker
[12:45:42 EDT(-0400)] <michelled> when I'm over the top half of the last time the drop marker should be above the last item. When I'm over the bottom half of the last item the drop marker should be below the last item
[12:45:53 EDT(-0400)] <michelled> Justin_o, is this the bug that you're talking about?
[12:46:10 EDT(-0400)] <Justin_o> michelled: yes that's what the issue is
[12:46:20 EDT(-0400)] <Justin_o> simonwang: is that what you were seeing
[12:46:34 EDT(-0400)] <simonwang> yes.
[12:47:27 EDT(-0400)] <Justin_o> simonwang: okay... sorry i think you had a solution. what was that again
[12:53:02 EDT(-0400)] * apetro-_ (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[12:55:04 EDT(-0400)] <simonwang> justin_o: the code has no bug, this issue is caused by the css styling.
[12:55:27 EDT(-0400)] <Justin_o> oh okay.. i see what you're saying... do you know what it should be set at
[12:58:08 EDT(-0400)] <simonwang> I tried a few things, but still cannot reduce the move of the last line enough when the drop marker changes from the top to the bottom of the last line.
[12:58:41 EDT(-0400)] <Justin_o> So the issue is that the drop marker is there but it is underneath the last list item?
[13:00:07 EDT(-0400)] <Justin_o> simonwang: stand-up is in about 1 minute or so, if you want to join us on breeze
[13:00:29 EDT(-0400)] <simonwang> ok, let's meet in the breeze.
[13:00:51 EDT(-0400)] <Justin_o> see u there
[13:28:33 EDT(-0400)] <simonwang> hi athena7
[13:28:40 EDT(-0400)] <athena7> heya
[13:29:51 EDT(-0400)] <simonwang> I need to build uPortal 3 with the fluid integration. Could you tell me which uPortal 3 version should I use?
[13:30:44 EDT(-0400)] <athena7> you'll need to check out the trunk
[13:31:04 EDT(-0400)] <athena7> i just committed it yesterday, so there's no tagged release
[13:31:42 EDT(-0400)] <simonwang> the current trunk, thanks
[13:32:03 EDT(-0400)] <athena7> yep (smile)
[13:32:14 EDT(-0400)] <athena7> just as a general note, the trunk now requires tomcat 6
[13:32:54 EDT(-0400)] <athena7> http://www.ja-sig.org/wiki/display/UPM30/01+Tomcat
[13:33:04 EDT(-0400)] <athena7> that documents the configuration change you'll need to make to tomcat 6
[13:33:28 EDT(-0400)] <simonwang> Great! thank you so much.
[13:35:13 EDT(-0400)] <athena7> no problem
[13:35:21 EDT(-0400)] <athena7> let me know if you have any problems getting up and running
[13:35:44 EDT(-0400)] <athena7> you'll need maven 2 and ant 1.6.5 (not 1.7) to build it
[13:37:32 EDT(-0400)] <simonwang> I need to set up our environment first. I will document the steps I need, and probably will need your help.
[13:38:05 EDT(-0400)] <athena7> no problem
[13:39:01 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[13:39:04 EDT(-0400)] <athena7> i'll be traveling for work next week, so i may not be spending a lot of time in IRC
[13:39:25 EDT(-0400)] <athena7> but feel free to email me or the uportal-dev lists if you run into any problems
[13:39:43 EDT(-0400)] <simonwang> I will.
[13:57:57 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined #fluid-work
[13:58:40 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-54.LIPS.Berkeley.EDU) has joined #fluid-work
[14:22:03 EDT(-0400)] <michelled> ecochran, jacobfarber: I just sent the commit freeze warning message to the list.
[14:22:24 EDT(-0400)] <michelled> I was really hoping to see some of the springboards in the beta
[14:22:31 EDT(-0400)] <michelled> any idea when that may happen?
[14:22:47 EDT(-0400)] <jacobfarber> thanks. ecochran- want to sit down and discuss the status of the springboards?
[14:22:53 EDT(-0400)] <michelled> (commit freeze on Tuesday, end of day)
[14:23:13 EDT(-0400)] <ecochran> Actually let me bring our conversation to this list, if I may
[14:23:19 EDT(-0400)] <jacobfarber> sure
[14:23:28 EDT(-0400)] <ecochran> I'm a little concerned with releasing them as they stand now
[14:23:41 EDT(-0400)] <ecochran> they are very solid and they are going the direction that we want them to go
[14:23:44 EDT(-0400)] <jacobfarber> sure, lets discuss on the list
[14:23:48 EDT(-0400)] <ecochran> good work! jacobfarber
[14:24:01 EDT(-0400)] <michelled> what is your concern ecochran?
[14:24:11 EDT(-0400)] <ecochran> however, in light of anastasiac's comment on fluid-work
[14:24:18 EDT(-0400)] <ecochran> getting there, typing slow
[14:24:23 EDT(-0400)] <michelled> sorry (smile)
[14:24:34 EDT(-0400)] <ecochran> I'm wondering if we should put more design into them before putting them out
[14:24:39 EDT(-0400)] <ecochran> not sure
[14:24:42 EDT(-0400)] <ecochran> thinking
[14:24:54 EDT(-0400)] <ecochran> are we sending the wrong message about where they are going?
[14:25:05 EDT(-0400)] <ecochran> or will folks understand that this is "phase one"
[14:25:06 EDT(-0400)] <jacobfarber> you think a design pass is necessary this early on?
[14:25:10 EDT(-0400)] <michelled> interesting.
[14:25:22 EDT(-0400)] <michelled> well, one thing I'd keep in mind is that this is the beta
[14:25:24 EDT(-0400)] <ecochran> code wise they are fine
[14:25:37 EDT(-0400)] <ecochran> visually they are flat and uninteresting
[14:25:39 EDT(-0400)] <michelled> perhaps just putting a couple of them in and then improving the design for the release?
[14:25:55 EDT(-0400)] <ecochran> perhaps even so flat that they don't really communicate
[14:25:57 EDT(-0400)] <jacobfarber> i really thought that was the idea
[14:26:12 EDT(-0400)] <ecochran> for "phase one"
[14:26:43 EDT(-0400)] <ecochran> I'm fine with putting them out there as is, I just want to make sure that we all are
[14:26:46 EDT(-0400)] <jacobfarber> we should push this conversation to the list
[14:27:00 EDT(-0400)] <anastasiac> I think they are still useful, even without a design pass
[14:27:13 EDT(-0400)] <anastasiac> they do a good job of showing how to code the components
[14:27:32 EDT(-0400)] <jacobfarber> i thinks thats the key right now
[14:27:42 EDT(-0400)] <ecochran> let's just make sure that we put into the documentation, where we're going and how folks can contribute
[14:27:45 EDT(-0400)] <jacobfarber> more looking through the implementation code source, than the visual aspect
[14:27:47 EDT(-0400)] <anastasiac> as long as they are accompanied by a comment explaining that they don't yet illustrate best practices for visuals, they're very useful
[14:27:57 EDT(-0400)] <ecochran> cool
[14:27:58 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279336033.dsl.bell.ca) has joined #fluid-work
[14:28:09 EDT(-0400)] <ecochran> I will check them in
[14:28:30 EDT(-0400)] <jacobfarber> Can I write a patch to include inline edit?
[14:28:41 EDT(-0400)] <ecochran> is it ready?
[14:28:57 EDT(-0400)] <jacobfarber> almost, within an hour
[14:29:00 EDT(-0400)] <jacobfarber> or so
[14:29:26 EDT(-0400)] <ecochran> let me check in what we have, then I'll patch the source in fluid instead of sandbox
[14:29:50 EDT(-0400)] <jacobfarber> ok
[14:30:58 EDT(-0400)] <ecochran> ? for those of you who are svn gurus: is there a good way to move something from one repository to another so that history isn't lost?
[14:31:05 EDT(-0400)] <michelled> cool! this is exciting - let me know when they are there and we can rebuild and add links to them on the build page
[14:31:41 EDT(-0400)] * anastasiac searches her memory
[14:31:48 EDT(-0400)] * anastasiac also searches the svn book
[14:32:03 EDT(-0400)] <colinclark> ecochran: You want to move between repositories, or between modules in the same repository?
[14:32:25 EDT(-0400)] <michelled> I think I remember clown doing an export, cleaning the export file and then doing an import
[14:32:31 EDT(-0400)] <michelled> I don't think it was trivial
[14:32:35 EDT(-0400)] <colinclark> If it's just moving from, say, sandbox to fluid-components trunk, you should be able to use "svn move."
[14:32:37 EDT(-0400)] <ecochran> modules, I guess... (*ecochran not a svn guru)
[14:32:46 EDT(-0400)] <ecochran> OK
[14:32:49 EDT(-0400)] <ecochran> I'll try that
[14:32:56 EDT(-0400)] <colinclark> If you actually want to move something from one repository to another, (say from Sakai's to Fluid's) it's a harder job.
[14:33:12 EDT(-0400)] <ecochran> no, just from sandbox to fluid trunk
[14:33:25 EDT(-0400)] <colinclark> ecochran: Easy!
[14:33:38 EDT(-0400)] <ecochran> I'll give it a shot
[14:33:39 EDT(-0400)] <colinclark> svn move will do the trick.
[14:34:12 EDT(-0400)] <colinclark> Try this, for example:
[14:35:05 EDT(-0400)] <colinclark> svn move http://source.fluidproject.org/svn/sandbox/springboards/trunk/LayoutCustomizer/LayoutCustomizer.html https://source.fluidproject.org/svn/fluid/components/trunk/src/webapp/fluid-components/html/LayoutCustomizer.html
[14:35:54 EDT(-0400)] <colinclark> If you want to move a bunch of files in one shot, you can do it with both modules checked out.
[14:36:21 EDT(-0400)] <colinclark> Which is better. Moving via URL tends to force you to do lots of commits.
[14:37:22 EDT(-0400)] <ecochran> ok, the svn part of your example is very clear, but your paths have me concerned... are we going to create a springboards directory? /trunk/src/webapp/fluid-components/springboards/ ?
[14:37:33 EDT(-0400)] <ecochran> I thought that we were
[14:37:39 EDT(-0400)] <ecochran> but I may be confused
[14:37:48 EDT(-0400)] <colinclark> No, I'd like them to be at the top-level, inside the html and css directories.
[14:38:30 EDT(-0400)] <ecochran> so you want them intermingled with everything else?
[14:38:33 EDT(-0400)] <ecochran> hmm
[14:39:12 EDT(-0400)] <ecochran> I think that confuses what is sample code, and what is component
[14:43:34 EDT(-0400)] <ecochran> colinclark: ^
[14:43:59 EDT(-0400)] <colinclark> I don't even understand that distinction.
[14:44:42 EDT(-0400)] <colinclark> Many of these components simply don't have markup of their own. I believe this was your rationale for putting Uploader's markup into the sample-code folder.
[14:45:03 EDT(-0400)] <colinclark> My point with these springboards is to ship good default markup. A starting point for people to customize and adapt for their own implementation.
[14:45:04 EDT(-0400)] <ecochran> exactly
[14:45:27 EDT(-0400)] <colinclark> When we have the template renderer working, we'll split the html up into two separate folders, one for the template and one the springboard.
[14:45:52 EDT(-0400)] <colinclark> But for the time being, these springboards are the markup that you would use when getting started with the compoent.
[14:46:06 EDT(-0400)] <colinclark> So in effect, they are the component's "template."
[14:46:20 EDT(-0400)] <ecochran> but what if you already have your own mark up?
[14:46:28 EDT(-0400)] <colinclark> then use it
[14:48:07 EDT(-0400)] <ecochran> seems confusing to me...
[14:49:13 EDT(-0400)] <ecochran> I think that it's important to distinguish between what code is for what purpose
[14:49:26 EDT(-0400)] <ecochran> exactly why I separated out the uploader examples
[14:50:29 EDT(-0400)] <colinclark> ecochran: I'd like to put the springboards in the top level html and css directories.
[14:50:39 EDT(-0400)] <ecochran> springboards are more canonical, they straddle the line between an example and code that you code implement with
[14:50:45 EDT(-0400)] <ecochran> OK, your call
[14:51:39 EDT(-0400)] <colinclark> The fact that you separated out the uploader examples never made sense. They're about as canonical as you can get. But I'm going with this general approach that, since we don't ship templates for our components, that the springboards represent the default markup for a component. Since they're not templates, they're naturally mutable.
[14:52:05 EDT(-0400)] <colinclark> Your uploader markup will eventually also become springboards, too.
[14:52:26 EDT(-0400)] <anastasiac> the springboard files consist of both html files and css files, right?
[14:52:33 EDT(-0400)] <ecochran> agreed, but only after all context is removed
[14:52:38 EDT(-0400)] <ecochran> yes
[14:52:56 EDT(-0400)] * anastasiac pauses to catch up on the discussion before weighing in
[14:53:12 EDT(-0400)] <colinclark> And then, when the template renderer ships, we'll look at the relationship between springboards and the canonical templates. Presumably the springboards will remain more simple and the templates will capture the complex details and features of a component.
[14:53:32 EDT(-0400)] <colinclark> But for the time being, we need to give people more than they have now to start with. Good default css and some markup they can adapt and use.
[14:53:53 EDT(-0400)] <colinclark> And these files should be easy to find.
[14:54:10 EDT(-0400)] <colinclark> Hence the top-level html and css directories.
[14:55:27 EDT(-0400)] <anastasiac> if we actually had templates, I would agree with keeping the templates separate from the springboards.
[14:55:33 EDT(-0400)] <ecochran> I feel that if they are in their own directory that it is easier to explain what they are, and how they are meant to be used.
[14:55:33 EDT(-0400)] <anastasiac> but we don't have templates
[14:56:30 EDT(-0400)] <anastasiac> if these springboards are essentially the closest thing we have to templates, and are intended to function as an informal template, then I agree that they should go in the html/css folders
[14:56:43 EDT(-0400)] <anastasiac> provided there is documentation/readme/something explaining what they are
[14:57:35 EDT(-0400)] <colinclark> "Informal template" is a nice way to put it.
[14:57:52 EDT(-0400)] <ecochran> I cry uncle, there is no point in belaboring this...
[14:58:14 EDT(-0400)] <anastasiac> the Lightbox.html file was originally thought of as a template, but it isn't a template, it's essentially an 'informal template' now
[14:58:30 EDT(-0400)] <anastasiac> it's a model for how to create a lightbox
[15:25:31 EDT(-0400)] <ecochran> michelled: all checked in
[15:27:24 EDT(-0400)] <colinclark> michelled: This "too many vars" in JSLint is just dreadful.
[15:27:27 EDT(-0400)] <michelled> cool! Thanks ecochran
[15:28:03 EDT(-0400)] <michelled> colinclark: is it because you are doing an old file? I found it annoying too but I'm wondering if it will be fine the next time I do that file.
[15:28:20 EDT(-0400)] <colinclark> michelled: I'm turning off "Allow only one var statement per function." It's impossible to put anything even vaguely substantial into an anonymous closure.
[15:28:42 EDT(-0400)] <colinclark> Take a look at the new DemoUploadManager. It's got a bunch of stateless functions at the top of the file.
[15:28:53 EDT(-0400)] <colinclark> But JSLint wants me to cram all those variable declarations into one line.
[15:28:55 EDT(-0400)] <colinclark> Which is crazy!
[15:29:06 EDT(-0400)] <colinclark> michelled: Do you know what I mean?
[15:29:12 EDT(-0400)] <michelled> yes, I do
[15:29:26 EDT(-0400)] <michelled> I had the same issue with one of the files I did
[15:29:29 EDT(-0400)] <colinclark> It seems to me that it will be a showstopper with all of our code defined within functions.
[15:30:29 EDT(-0400)] <michelled> perhaps. The files I did were fairly small so it wasn't too onerous. And there was a good side effect that on the first line of the function I could easily see the names of all the private functions inside
[15:31:17 EDT(-0400)] <michelled> var deriveLightboxCellBase, addThumbnailActivateHandler, createItemFinder, defaultOrderChangedCallback;
[15:31:32 EDT(-0400)] <michelled> but I understand what you're saying.
[15:31:56 EDT(-0400)] <colinclark> It just doesn't work for reasonably substantial chunks.
[15:32:05 EDT(-0400)] <colinclark> (sad)
[15:35:34 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[15:45:47 EDT(-0400)] <michelled> http://build.fluidproject.org/fluid/fluid-components/html/LayoutCustomizer.html
[15:46:09 EDT(-0400)] <michelled> http://build.fluidproject.org/fluid/fluid-components/html/Reorderer.html
[15:46:49 EDT(-0400)] <michelled> http://build.fluidproject.org/fluid/fluid-components/html/Lightbox.html
[15:47:01 EDT(-0400)] <michelled> those are the existing springboards if anyone is interested
[15:47:27 EDT(-0400)] <colinclark> michelled: I'm getting errors on the LayoutCustomizer file.
[15:47:38 EDT(-0400)] <michelled> jacobfarber: the Lightbox one is very old and could use your eye on it. Perhaps some clean up is in order.
[15:47:51 EDT(-0400)] <colinclark> dropMarker is undefined.
[15:47:59 EDT(-0400)] <michelled> good catch colinclark, me too
[15:48:15 EDT(-0400)] <michelled> that's the error that shows up when a reorderer isn't initallized correctly
[15:48:23 EDT(-0400)] <michelled> it could be due to new API changes
[15:48:33 EDT(-0400)] <colinclark> jacobfarber: I'd love to see the drop marker on the tabs example get some love.
[15:48:37 EDT(-0400)] <colinclark> It's pretty subtle at the moment.
[15:48:38 EDT(-0400)] <jacobfarber> michelled: just finished my first pass on the inline edit, now onto the lightbox one
[15:49:03 EDT(-0400)] <colinclark> There also seems to be some debugging output in the console.
[15:49:16 EDT(-0400)] <michelled> cool. I think it makes sense for you to start with what's there already
[15:49:17 EDT(-0400)] <colinclark> Reorderer line 34: "Drag stopped."
[15:49:37 EDT(-0400)] <michelled> colinclark: do you think that the RSF ids should still be in the Lightbox.html file?
[15:49:41 EDT(-0400)] <colinclark> jacobfarber, ecochran: These are really great.
[15:49:47 EDT(-0400)] <michelled> that adds considerable complication
[15:50:01 EDT(-0400)] <colinclark> michelled: At the moment, they need to be in there for our gallery example to continue working.
[15:50:34 EDT(-0400)] <jacobfarber> ecochran: http://issues.fluidproject.org/browse/FLUID-1112
[15:51:12 EDT(-0400)] <ecochran> curious about the dropmarker bug, cause I thought we fixed that yesterday
[15:51:16 EDT(-0400)] <ecochran> I'll take a look
[15:52:11 EDT(-0400)] <jacobfarber> thanks
[15:52:41 EDT(-0400)] <jacobfarber> colinclark: is that due to the api change?
[15:52:56 EDT(-0400)] <colinclark> jacobfarber: Not sure. I'd have to take a closer look.
[15:53:53 EDT(-0400)] <ecochran> strange, I did my smoke test in Safari, just cause it was already open, and it works fine. error only in FF
[15:55:03 EDT(-0400)] <michelled> yes, it's the API change
[15:55:16 EDT(-0400)] <michelled> I can fix and commit
[15:55:57 EDT(-0400)] <michelled> colinclark: do you think it makes sense for jacobfarber to create a new clean Lightbox.html and rename the old example to LightboxRSF.html?
[15:56:25 EDT(-0400)] <colinclark> michelled: ... or stick it in a templates directory.
[15:56:40 EDT(-0400)] <colinclark> Either way, the gallery config files would have to be updated.
[15:56:51 EDT(-0400)] <colinclark> But yes, a nice light Lightbox springboard would be great.
[15:57:02 EDT(-0400)] <colinclark> I'd say toss Lightbox.html into a templates directory.
[15:57:10 EDT(-0400)] <colinclark> I wonder what its future really is at this point.
[15:57:14 EDT(-0400)] <michelled> thanks
[15:57:32 EDT(-0400)] <michelled> would 'templates' exist in html or as a sibling?
[15:58:08 EDT(-0400)] <colinclark> I think inside html.
[15:58:33 EDT(-0400)] <colinclark> michelled: What do you prefer?
[15:58:47 EDT(-0400)] <michelled> no preference
[15:59:12 EDT(-0400)] <colinclark> So there is an application context or something in the old gallery that will have to be updated to this new path.
[15:59:45 EDT(-0400)] <colinclark> I'd put it within html. That should ensure that no weirdness will occur when our mini-war is merged with the gallery tool's war file.
[15:59:45 EDT(-0400)] <michelled> k, you can try layout customizer again
[16:00:21 EDT(-0400)] <colinclark> Works for me.
[16:00:24 EDT(-0400)] <ecochran> just tried it, works
[16:00:46 EDT(-0400)] <ecochran> did the API change since yesterday afternoon?
[16:00:59 EDT(-0400)] <michelled> yup (smile)
[16:01:04 EDT(-0400)] <ecochran> ah
[16:01:06 EDT(-0400)] <ecochran> missed that
[16:01:15 EDT(-0400)] <colinclark> jacobfarber: They're really nice examples. I really like the "no drag" affordance you've used in example 2.
[16:01:39 EDT(-0400)] <colinclark> michelled: I'm still having trouble with example #3.
[16:02:04 EDT(-0400)] <michelled> ecochran - that was my morning task - bring reorderLayout in line with reorderList and reorderGrid
[16:02:16 EDT(-0400)] <ecochran> cool
[16:02:34 EDT(-0400)] <jacobfarber> colinclark: example 3?
[16:02:46 EDT(-0400)] <colinclark> jacobfarber: Yep. Ah, it seems to be the permissions rules, maybe?
[16:03:01 EDT(-0400)] <colinclark> I wonder if we should do some styling to provide an indication of the rules?
[16:03:01 EDT(-0400)] <jacobfarber> in the layout customizer?
[16:03:14 EDT(-0400)] <colinclark> It's probably a sign that these uPortal-style permissions are just plain crazy. (tongue)
[16:04:28 EDT(-0400)] <colinclark> jacobfarber: What are the rules in example 3 for moving portlets around?
[16:04:34 EDT(-0400)] <jacobfarber> colinclark: they should be there, albeit limited
[16:04:48 EDT(-0400)] <jacobfarber> in the description, it says only take item #1 in column #1
[16:05:02 EDT(-0400)] <colinclark> ah, words
[16:05:08 EDT(-0400)] <michelled> (tongue)
[16:05:13 EDT(-0400)] <jacobfarber> and drag it up or down wihtin 2 units, so the drop marker should help right?
[16:05:31 EDT(-0400)] <colinclark> Yep
[16:05:37 EDT(-0400)] <colinclark> I think this is proof that uP is crazy!
[16:05:43 EDT(-0400)] <michelled> I have to run - anastasiac could you maybe put some links to these examples on the build page?
[16:05:46 EDT(-0400)] <jacobfarber> indeed (tongue)
[16:06:31 EDT(-0400)] <colinclark> I am, however, seeing inconsistencies in how the rules seem to be applied when dragging versus moving.
[16:06:34 EDT(-0400)] <colinclark> I think.
[16:06:51 EDT(-0400)] <colinclark> jacobfarber: I'm pretty impressed that you managed to work these rules out, and express them in that crazy JSON format.
[16:06:55 EDT(-0400)] <jacobfarber> I did end up with a few errors
[16:07:01 EDT(-0400)] <jacobfarber> (smile)
[16:07:04 EDT(-0400)] <colinclark> Those formats were never intended to be human-readable. (wink)
[16:07:11 EDT(-0400)] <michelled> so perms are really complicated and they get out of sync after the first move
[16:07:24 EDT(-0400)] <jacobfarber> yeah, plus there is a glitch
[16:07:30 EDT(-0400)] <colinclark> michelled: We still didn't fix the bug where they get out of sync?
[16:07:34 EDT(-0400)] <jacobfarber> it seems you can drag to the bottom of any column as well
[16:07:36 EDT(-0400)] <ecochran> should svn in Aptana be able to create new files from a patch. I don't seem to be able to do it?
[16:07:38 EDT(-0400)] <anastasiac> michelled - yes, I'll put links on the build page to the springboards
[16:08:00 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has left #fluid-work
[16:08:03 EDT(-0400)] <jacobfarber> ecochran: it should, right?
[16:08:04 EDT(-0400)] <michelled> colinclark: we have no way to fix it. precedence is only known and understood by the server
[16:08:17 EDT(-0400)] <ecochran> I would think
[16:08:20 EDT(-0400)] <colinclark> michelled: Ah, I see.
[16:08:45 EDT(-0400)] <colinclark> What would an implementor other than uP need to know to provide this concept of precedence?
[16:09:16 EDT(-0400)] <colinclark> ecochran: I'm fairly certain it will. I tend to always apply patches with Aptana, and I'm pretty sure it worked for me with one of jacobfarber's previous patches.
[16:09:42 EDT(-0400)] <ecochran> it tells me that the file doesn't exist
[16:09:49 EDT(-0400)] <ecochran> I'll see if there is some setting that I don't have
[16:10:33 EDT(-0400)] <jacobfarber> http://issues.fluidproject.org/browse/FLUID-1128
[16:12:19 EDT(-0400)] <michelled> colinclark: the contract that we worked out with EricDalquist was that the client would call the server with the new layout and the server would respond with the new perms.
[16:12:49 EDT(-0400)] <michelled> unfortunately this isn't actually integrated into uPortal and I think it will change when we do the integration
[16:13:21 EDT(-0400)] <michelled> it became clear in recent conversations with Jen that it isn't actually what would be preferable for her.
[16:13:33 EDT(-0400)] <colinclark> I guess what I'm getting at is, how would the server know how to respond with new perms?
[16:14:25 EDT(-0400)] <michelled> the server has to understand it's own concept of precedence and work out the perms based on that.
[16:14:55 EDT(-0400)] <michelled> not for the faint of heart (tongue)
[16:15:25 EDT(-0400)] <colinclark> Indeed.
[16:15:35 EDT(-0400)] <michelled> later all
[16:15:41 EDT(-0400)] * michelled (n=team@142.150.154.197) has left #fluid-work
[16:15:44 EDT(-0400)] <colinclark> I'm going to hit the road, too.
[16:16:01 EDT(-0400)] <colinclark> A day of wrangling with new Uploader code deserves a sailing reward. (wink)
[16:16:37 EDT(-0400)] <colinclark> ecochran: The new DemoUploadManager is in svn now, with decent tests. Your algorithm was quite remarkable, and took me awhile to understand.
[16:17:14 EDT(-0400)] <colinclark> There's a stub of the ServerUploadManager, too. It will need work. I'm going to start in on the FileQueue view tomorrow, so that we can see this in action.
[16:17:15 EDT(-0400)] <ecochran> well not so remarkable that it took awhile to understand, but thanks
[16:17:40 EDT(-0400)] <colinclark> Well, concurrency is always a bitch...
[16:17:46 EDT(-0400)] <colinclark> and in JavaScript, it's just plain bizarre.
[16:18:03 EDT(-0400)] <colinclark> So it took me awhile to get a feel for your bit of recursion for demoProgress.
[16:19:01 EDT(-0400)] <ecochran> jacobfarber: I see part of the problem with the patch. It still references separate InlineEdit and Reorderer folders which we don't have anymore in fluid-components
[16:19:14 EDT(-0400)] <ecochran> don't worry about it, I can hand apply the changes
[16:19:38 EDT(-0400)] <jacobfarber> yeah, I wasnt aware at the time of the move to the trunk
[16:19:48 EDT(-0400)] <ecochran> colinclark: hmm, recursion... good!
[16:19:56 EDT(-0400)] <jacobfarber> now thats where im working, so there shouldnt be any mor confusion
[16:20:09 EDT(-0400)] <ecochran> jacobfarber: yes
[16:24:34 EDT(-0400)] <colinclark> have a good evening, all
[16:33:39 EDT(-0400)] <ecochran> jacobfarber: could you make sure that your Aptana is set up to use Unix linefeeds for new files
[16:33:59 EDT(-0400)] <ecochran> it's under Preferences > General > Workspace
[16:34:08 EDT(-0400)] <jacobfarber> i dont use aptana....
[16:34:13 EDT(-0400)] <jacobfarber> unix linefeeds??
[16:34:44 EDT(-0400)] <ecochran> oh, what do you edit in?
[16:34:52 EDT(-0400)] <jacobfarber> notepad++
[16:34:58 EDT(-0400)] <ecochran> Ah...
[16:35:13 EDT(-0400)] <ecochran> Mac, Unix and Windows all use different line endings...
[16:35:39 EDT(-0400)] <jacobfarber> ahh
[16:35:42 EDT(-0400)] <ecochran> It's not really a big deal but it does mean that when I bring in your patches they are hard to read because they use Windows linefeeds
[16:35:54 EDT(-0400)] <jacobfarber> ok, so I changed my documents to be "unix compatible" yes?
[16:36:22 EDT(-0400)] <ecochran> yes
[16:36:26 EDT(-0400)] <ecochran> makes them easier to read
[16:36:47 EDT(-0400)] <jacobfarber> ok, done
[16:40:07 EDT(-0400)] <ecochran> jacobfarber: check out Aptana... there is a Windows version
[16:40:17 EDT(-0400)] <jacobfarber> i use it too ;P
[16:40:20 EDT(-0400)] <jacobfarber> (tongue)
[16:40:21 EDT(-0400)] <ecochran> ah
[16:40:29 EDT(-0400)] <jacobfarber> but its too slow for my tastes
[16:40:41 EDT(-0400)] <ecochran> I'm completely addicted to it
[16:40:47 EDT(-0400)] <ecochran> used to be slow on the Mac
[16:40:53 EDT(-0400)] <ecochran> now it rocks
[16:40:56 EDT(-0400)] <ecochran> mostly
[16:41:00 EDT(-0400)] <jacobfarber> (smile)
[16:41:08 EDT(-0400)] <ecochran> faster than Dreamweaver, slower than BBEdit
[16:42:18 EDT(-0400)] <jacobfarber> yeah, i just find that Eclipse is built to be everything to everyone, and Aptana suffers a little from this
[16:42:42 EDT(-0400)] <jacobfarber> I enjoy it though
[16:42:46 EDT(-0400)] <jacobfarber> very powerful stuff
[16:50:26 EDT(-0400)] <ecochran> jacobfarber: on the inlineedit springboard...
[16:50:52 EDT(-0400)] <ecochran> the multi example should the fields jump to the end of the line when editing?
[16:51:44 EDT(-0400)] <jacobfarber> yes, its a logged bug
[16:51:45 EDT(-0400)] <ecochran> oh, I guess the simple one does it too
[16:51:49 EDT(-0400)] <ecochran> ok
[16:51:53 EDT(-0400)] <ecochran> bummer
[16:51:57 EDT(-0400)] <ecochran> I'm checking in now
[16:52:50 EDT(-0400)] <ecochran> jacobfarber: done
[16:53:13 EDT(-0400)] * apetro-- (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[16:53:14 EDT(-0400)] <ecochran> please check since the merge was done semi-manually I want to make sure that I didn't miss anything
[16:53:14 EDT(-0400)] <jacobfarber> http://issues.fluidproject.org/browse/FLUID-1286
[16:53:38 EDT(-0400)] <ecochran> how funky
[16:53:55 EDT(-0400)] <jacobfarber> its pretty simple
[16:54:09 EDT(-0400)] <jacobfarber> the edit input just needs to go right after the editable text
[16:54:14 EDT(-0400)] <jacobfarber> not at the end of the container
[16:54:43 EDT(-0400)] <jacobfarber> im not sure if jQuery has an "inject after" function
[17:14:35 EDT(-0400)] <jessm> sneak peak extravaganza:
[17:15:25 EDT(-0400)] <jessm> there is a skype public channel where the designers have been resting their feet and their longer design-related conversations – i'll put it up on the wiki, but it's at http://www.skype.com/go/joinpublicchat?skypename=jesshmitchell&amp;topic=Fluid%20Team&amp;blob=VNf5-n_slaRn0GeAvJVcnVssklkxbjmpKrHqXOfIwA-lmbgf2cbDQnncsi5GS0NIbBSbZDBQ7IwdwbG9UEpwJ2pREUE61ouK5y8TecOMRcEodOcnXL1WUaV5jx7JLL66v8vjzhGuwE4OCWCnT94FicCh
[17:15:38 EDT(-0400)] <jessm> sorry for the horrendous url!
[17:17:52 EDT(-0400)] <jessm> http://tiny.cc/3IKwh
[17:19:51 EDT(-0400)] <ecochran> jacobfarber: yes, it's pretty easy with jQuery to inject anywhere
[18:03:02 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[18:28:58 EDT(-0400)] * simonwang (n=chatzill@swang.itservices.ubc.ca) has joined #fluid-work