fluid-work IRC Logs-2009-11-25

[01:27:39 EST(-0500)] * Bosmon2 (n=amb26fre@75-171-178-212.hlrn.qwest.net) has joined #fluid-work
[04:26:20 EST(-0500)] * joan2 (n=jgarci@120.Red-213-96-26.staticIP.rima-tde.net) has joined #fluid-work
[06:47:56 EST(-0500)] * sveto (n=sveto@62.44.108.2) has joined #fluid-work
[07:17:23 EST(-0500)] * boyan (n=boyan@62.44.108.2) has joined #fluid-work
[08:26:28 EST(-0500)] * laurel (n=Laurel@142.150.154.178) has joined #fluid-work
[08:31:20 EST(-0500)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[08:34:34 EST(-0500)] * sveto_ (n=sveto@62.44.108.2) has joined #fluid-work
[08:37:20 EST(-0500)] * jameswy (n=jameswy@142.150.154.196) has joined #fluid-work
[08:39:16 EST(-0500)] * EricDalquist (n=EricDalq@76.210.69.47) has joined #fluid-work
[08:46:03 EST(-0500)] * joan2 (n=jgarci@120.Red-213-96-26.staticIP.rima-tde.net) has joined #fluid-work
[08:52:45 EST(-0500)] * michelled (n=michelle@142.150.154.193) has joined #fluid-work
[09:00:00 EST(-0500)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[09:06:36 EST(-0500)] * anastasiac (n=team@142.150.154.189) has joined #fluid-work
[09:09:45 EST(-0500)] * sveto_ (n=sveto@62.44.108.2) has joined #fluid-work
[09:13:12 EST(-0500)] <sveto> Justin_o: hi, I think I found a problem with kettle acceptors - it seems that the http query is produced concatenated twice when passed in the environment to the handler. For instance when I call http://../some.html?abc&xyz I receive a QUERY_STRING equal to "abc&xyz&abc&xyz". Is this a known problem or should I file a jira for it?
[09:22:00 EST(-0500)] <Justin_o> sveto: yes that is a known issue... it is actually a bug in the loadData.js file... it has been fixed in trunk
[09:23:31 EST(-0500)] <Justin_o> sveto: we were adding it in a second time in the ajax call. you can just remove the data key to get rid of it.
[09:24:59 EST(-0500)] <sveto> Justin_o: ok, I guess it will be better if I do a merge with the trunk.
[09:29:14 EST(-0500)] <Justin_o> sveto sure if you can that would probably be good to try to stay current
[09:30:14 EST(-0500)] <Justin_o> sveto: also the format of the query params are now more standard so instead of doing something like mmi&merchandising we now do db=mmi&q=merchandising
[09:31:40 EST(-0500)] <sveto> I guess that then the parsing of the query should change too. I'll see how it's done in the other components.
[09:32:29 EST(-0500)] <Justin_o> yep... kettle actually deserialiezes the query parameter for you into a proper object
[09:32:42 EST(-0500)] <Justin_o> sveto: ^
[09:32:42 EST(-0500)] <Justin_o> {color}
[09:32:58 EST(-0500)] <Justin_o> sveto: you can take a look at how the current versions of browse and view use it
[09:34:49 EST(-0500)] * jessm (n=Jess@71.232.1.65) has joined #fluid-work
[09:36:04 EST(-0500)] * clown (n=clown@142.150.154.101) has joined #fluid-work
[09:46:17 EST(-0500)] * colinclark (n=colin@70.26.86.7) has joined #fluid-work
[09:49:20 EST(-0500)] <boyan> michelled, colinclark: after I spent a fair amount of time on firing events from the thumbnail browser, and listening to them in capture, I came up with a rather radical design idea:
[09:49:20 EST(-0500)] <boyan> thumbBrowser component represents a list of reordarable images (no preview) and thus has the reorderer as a subcomponent, adding only a model to it
[09:49:20 EST(-0500)] <boyan> capture has thumbBrowser as a subcomponent and a preview area that should be affected by that subcomponent (or even by the sub-subcomponent, i.e. the reorderer)
[09:49:20 EST(-0500)] <boyan> this is a kind of redundant and complex structure (thumbBrowser has no meaningful logic in itself except of that of the reorderer)
[09:49:20 EST(-0500)] <boyan> also events fired by a sub-component should be handled by the parent component and some markup should be changed, which leads to the need of IoC, similar to the undo decorator in InlineEdit
[09:49:23 EST(-0500)] <boyan> so I'm thinking of getting rid of thumbBrowser as a separate component and have the reorderer as part of capture
[09:49:26 EST(-0500)] <boyan> this will simplify things and event handling, reduce redundancy and components will still be loosely coupled
[09:49:29 EST(-0500)] <boyan> what do you think about this?
[09:51:40 EST(-0500)] <colinclark> boyan: Makes tons of sense to me. Go for it!
[09:52:10 EST(-0500)] <boyan> colinclark: ok, I will
[09:52:49 EST(-0500)] <colinclark> It sounds like you're feeling pretty comfortable with the event-driven approach of Infusion and our IoC system.
[09:56:25 EST(-0500)] <boyan> colinclark: well, it took me a while and some try-errors to get acquainted with it
[09:59:52 EST(-0500)] <colinclark> boyan: Seems like you've learned it pretty quick to me. Anyway, I'm looking forward to seeing it after your refactoring.
[10:01:29 EST(-0500)] * yura (n=yura@142.150.154.163) has joined #fluid-work
[10:05:10 EST(-0500)] <boyan> colinclark: meanwhile, I have investigated the bug about the multiple event firing in reorderer
[10:05:30 EST(-0500)] <boyan> I think it is in the following piece of code (pasted in in Astea's private pastebin):
[10:05:32 EST(-0500)] <boyan> http://pastebin.asteasolutions.net/m1a899980
[10:05:59 EST(-0500)] <boyan> we have selecatables everywhere in the for statement
[10:06:29 EST(-0500)] <boyan> shouldn't they be selectable (the current selectable only, which is selectables[i])
[10:06:47 EST(-0500)] <boyan> if i change selectables.click(function (evt) {
[10:06:50 EST(-0500)] <boyan> to selectable.click(function (evt) {
[10:06:59 EST(-0500)] <boyan> the event is fired one time only
[10:07:14 EST(-0500)] <boyan> and I believe it should be the current selectable everywhere in the for statement
[10:07:42 EST(-0500)] <boyan> unless there's a good reason to modify all selectables on every iteration
[10:13:52 EST(-0500)] <colinclark> boyan: just catching up. I'll take a look
[10:15:25 EST(-0500)] <colinclark> boyan: I think you're right. This looks like a fairly dorky bug on our part.
[10:16:11 EST(-0500)] <boyan> colinclark: should I attach a patch and description to the JIRA I filed so that someone can review it and commit it?
[10:25:31 EST(-0500)] <michelled> boyan, colinclark: sorry I was away from the keyboard
[10:25:36 EST(-0500)] <michelled> boyan: yes, please attach a patch
[10:26:18 EST(-0500)] <michelled> and thanks for looking into the issue. Also I completely agree with your design decision above about getting rid of the thumb browser since it doesn't really do anything interesting.
[10:27:33 EST(-0500)] <michelled> I won't be surprised if you end up with a 'thumb' component sometime down the line as the designers refine their designs but I guess we'll wait and see
[10:29:05 EST(-0500)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[10:37:42 EST(-0500)] <boyan> colinclark, michelled: I attached the patch, marked the issue as resolved and sent out an email to fluid-work
[10:37:56 EST(-0500)] <michelled> thanks
[10:38:53 EST(-0500)] <michelled> just thinking that maybe it shouldn't be marked as resolved until it gets committed. I wouldn't want it to slip by
[10:45:06 EST(-0500)] <colinclark> michelled: That makes sense
[10:56:48 EST(-0500)] <joan2> hi
[10:58:45 EST(-0500)] <joan2> justin, michelle: which branch to i need to use to place the artifactview comments component?
[10:59:40 EST(-0500)] <joan2> one more: which branch to i need to check server code uses my couchdb local install? thxs.
[11:01:05 EST(-0500)] * boyan (n=boyan@62.44.108.2) has left #fluid-work
[11:05:30 EST(-0500)] * sveto (n=sveto@62.44.108.2) has left #fluid-work
[11:23:57 EST(-0500)] <joan2> i've seen how artifactView requestes documents in kettle to lucene-couchdb.
[11:24:16 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[11:24:28 EST(-0500)] <joan2> i'll try to do the same for the artifact comments.
[11:28:52 EST(-0500)] * boyan (n=Administ@84.238.192.26) has joined #fluid-work
[11:43:41 EST(-0500)] * boyan (n=Administ@84.238.192.26) has left #fluid-work
[11:56:51 EST(-0500)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[12:01:30 EST(-0500)] <Justin_o> joan2: hello, sorry i didn't see your messages
[12:01:39 EST(-0500)] <Justin_o> so i'm just catching up
[12:02:23 EST(-0500)] <Justin_o> joan2: you could possibly work in the same svn space as sveto is for myCollections, but we should probably talk with him about it when he comes back online tomorrow
[12:02:42 EST(-0500)] <joan2> no problem
[12:03:23 EST(-0500)] <joan2> justin: the keyboard that appears just on the top of the comments, is a also a component?
[12:03:27 EST(-0500)] <Justin_o> joan2: comments themselves may be stored in a seperate database like sveto is for users specific info... although comments would seem to belong to the artifact and not the user...
[12:03:55 EST(-0500)] <Justin_o> joan2: no that is actually native to the iphone and should appear automatically when the text field has focus
[12:04:22 EST(-0500)] <Justin_o> I think the goal would be to have focus start on the first textfield
[12:04:26 EST(-0500)] <joan2> justin: comments have to have a field with the artifact-id, i suppose.
[12:04:38 EST(-0500)] <Justin_o> yes.. to link it back.. that makes sens
[12:05:29 EST(-0500)] <joan2> justin: yes to get all/one/any comment/s from an artifact
[12:06:08 EST(-0500)] <joan2> so should I create a different database for comments?
[12:12:19 EST(-0500)] <Justin_o> joan2: That is an interesting question... i don't think we have a definitive answer at this point how all that would work
[12:14:07 EST(-0500)] <Justin_o> joan2: so a couple options could be to have a new database for the comments, or to have the comments as a new document within the same database... what do you think?
[12:16:28 EST(-0500)] <michelled> I suppose the third option is to include comments in the current artifact documents. The issue with this options is mixing data that is coming from the museum with data that is being created by Engage
[12:16:29 EST(-0500)] <joan2> for me: it's a kind-of master-detail, same database? In a relational database space this would be the default approach.
[12:17:38 EST(-0500)] <joan2> michelle: i'm not sure that mixing would work. each comment is a document itself (just that has a relation with the artifact and someone who wrote it)
[12:19:58 EST(-0500)] <Justin_o> joan2: I think you could probably pick whichever approach you think is best... we can discuss it some more at the dev meeting. But, as with anything, the approach decided may have to change as things become more clear.
[12:21:16 EST(-0500)] <joan2> i'll start with comments as standalone documents (referencing artifact-id) stored on the same database. No problem having to change this.
[12:21:24 EST(-0500)] <joan2>
[12:21:49 EST(-0500)] <Justin_o> joan2: that's great... have we answered all of your questions or were there any that we missed
[12:22:26 EST(-0500)] <joan2> no. it's ok. many thanks.
[12:23:09 EST(-0500)] * joan2 (n=jgarci@120.Red-213-96-26.staticIP.rima-tde.net) has left #fluid-work
[12:58:54 EST(-0500)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[13:20:42 EST(-0500)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[14:09:03 EST(-0500)] * athena (n=athena@75-139-69-027.dhcp-v.gnvl.sc.charter.com) has joined #fluid-work
[14:20:28 EST(-0500)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[15:00:15 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[15:00:38 EST(-0500)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[16:51:40 EST(-0500)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[17:12:40 EST(-0500)] * anastasiac (n=team@142.150.154.189) has left #fluid-work
[18:04:06 EST(-0500)] * clown (n=clown@142.150.154.101) has left #fluid-work
[22:39:45 EST(-0500)] * Bosmon2 (n=amb26fre@75-171-178-212.hlrn.qwest.net) has joined #fluid-work