2010-07-08T00:42:01 *** mck9 has left #evergreen 2010-07-08T01:54:12 *** mrpeters-isl has quit IRC 2010-07-08T02:00:07 *** mrpeters-isl has joined #evergreen 2010-07-08T07:03:48 *** dbs has joined #evergreen 2010-07-08T07:46:01 *** isl-rjackson has joined #evergreen 2010-07-08T07:53:15 *** mck9 has joined #evergreen 2010-07-08T08:02:33 *** sfortin has joined #evergreen 2010-07-08T08:13:04 *** granitize has joined #evergreen 2010-07-08T08:55:53 *** Melissa has joined #evergreen 2010-07-08T09:07:07 *** shopkins has joined #evergreen 2010-07-08T09:19:25 *** jenny has joined #evergreen 2010-07-08T09:19:54 *** _bott_ has quit IRC 2010-07-08T09:21:01 *** _bott_ has joined #evergreen 2010-07-08T09:36:11 grabbing 0328 2010-07-08T09:45:11 *** alxp has joined #evergreen 2010-07-08T09:46:48 *** yboston has joined #evergreen 2010-07-08T09:55:57 any objections to adding an owner column to authority.record_entry and serial.record_entry - for the same "determine control number identifier / agency code" purposes? 2010-07-08T09:56:26 (and possibly similar controlled sharing measures, should we get to that point) 2010-07-08T10:15:23 Cataloguers: rejoice in r16878 2010-07-08T10:17:47 dbs++ # r16878, no opinion on owner columns 2010-07-08T10:18:33 we can probably preserve horizontal cursor positioning with a little work 2010-07-08T10:19:23 phasefx: I considered that, but thought that that would probably be undesired in most cases 2010-07-08T10:19:58 * phasefx can see it either way. Some folks do seem to want a simple text editor for MARC, and that's how text editors behave 2010-07-08T10:19:59 If you're moving from a 245 to a 650 or a 700, who cares about horizontal positioning? 2010-07-08T10:20:22 heh, the subfields mess all of that up anyway in the legacy MARC editor 2010-07-08T10:20:44 true that, didn't think about fun the subfields would make it 2010-07-08T10:20:51 how fun, even 2010-07-08T10:21:38 well, miker_'s marc breaker view for marc editing will give folks their text editor if desired 2010-07-08T10:22:11 Yeah - there is definitely interest in that view; plan to spawn it via a button from the legacy MARC editor or what? 2010-07-08T10:22:22 I think so, a toggle of some sort 2010-07-08T10:24:14 one goal is multiple marc records on screen in some split view, with marc breaker allowing easy cut/copy/paste between them. Though we could implement drag&drop with the legacy editor if we're feeling saucy :) 2010-07-08T10:25:49 heh, people would love that sauciness, but would also just love wordwrap with the legacy editor 2010-07-08T10:26:26 that too. One incarnation of the editor tried dynamically resizing textboxes, but was imperfect 2010-07-08T10:26:55 I remember spending a few hours trying to beat it into wordwrapped shape a year or so ago. not fun. 2010-07-08T10:27:05 dbs: sre.owner makes sense 2010-07-08T10:27:29 I think the very first prototype didn't use textboxes at all, but managed a label for every character. Easy wrapping there, but lack of convenience functionality bundled into modern textboxes 2010-07-08T10:28:15 dbs: re ownership columns, owner_on_SRE++ .... should authority records have a share depth too? also, SRE owner should probably be NOT NULL, but ARE nullable (like BRE) eh? 2010-07-08T10:28:15 are.owner also makes sense, but is not quite sufficient - tracking the thesaurus (or name list) that a given authority record supplies headings for is more on the mark 2010-07-08T10:29:08 gmcharlt: that should be coverable by extending authority.rec_descriptor with a thesaurus column extracted from the authority fixed fields, no? 2010-07-08T10:29:33 and then, of course, a thesaurus_map table, like language_map et al 2010-07-08T10:29:48 yep, that would get us most of the way 2010-07-08T10:30:27 with a bit of config UI support to allow catalogers to explicitly specify any local thesauri or name lists they create local authority records for 2010-07-08T10:30:27 yeah, are.owner should be kept separate from thesaurus issues 2010-07-08T10:30:39 gmcharlt: indeed 2010-07-08T10:31:31 I FEEL A (bunch of) NEW MARC-CODES TAB(s) FOR CONIFY IN OUR FUTURE! 2010-07-08T10:32:26 speak up, I couldn't hear you 2010-07-08T10:33:22 I FEEL SOMEONE OTHER THAN ME WRITING CONIFY INTERFACES IN OUR FUTURE! 2010-07-08T10:33:24 ;) 2010-07-08T10:33:27 miker++ 2010-07-08T10:35:17 *** youdonotexist has joined #evergreen 2010-07-08T11:33:17 r16884 will also make cataloguers happy 2010-07-08T11:38:06 as an aside, it seems that our "for (var i in NodeList)" constructions fail because iterating over a NodeList that way isn't cool 2010-07-08T11:38:45 dbs: you mean a DOM NodeList? 2010-07-08T11:38:48 aye 2010-07-08T11:39:37 yeah 2010-07-08T11:39:51 we did some refactoring of that last year 2010-07-08T11:40:10 (broke some of DojoSRF in the process ;) ) 2010-07-08T11:40:17 heh, i recall that ;) 2010-07-08T11:40:21 (my fault, got overzealous) 2010-07-08T11:40:57 IIRC, I just looked at non-staff-client js 2010-07-08T11:41:37 that was all prompted by the attempt to sort the OUs in the tree correctly in Chrome, IIRC. damned Chrome! 2010-07-08T11:41:42 * dbs also curses i18n 2010-07-08T11:42:41 hmm, the one case I was looking at in marcedit.js is probably okay because the returned elements are immediately tested for the existence of the getAttribute function 2010-07-08T11:43:46 chome sort's differently? 2010-07-08T11:43:54 s/'// 2010-07-08T11:44:17 and i missed an 'r'... bad typing day all around 2010-07-08T11:44:34 we were iterating over an associative array (ou list), and the order in which elements are returned is undefined. 2010-07-08T11:45:19 chrome was the only one that took advantage of that undefined nature to optimize ass.array access and return everything in alpha order. but the others will probably follow 2010-07-08T11:45:21 ah... that makes sense... 2010-07-08T11:49:10 *** Dyrcona has joined #evergreen 2010-07-08T11:50:06 *** dbs has quit IRC 2010-07-08T12:13:03 *** jenny1 has joined #evergreen 2010-07-08T12:14:45 *** jenny has quit IRC 2010-07-08T12:19:08 @later tell dbs btw, you should have access to dojo in marcedit.js if you want to use it (stuff like dojo.forEach, etc.) 2010-07-08T12:19:08 phasefx: The operation succeeded. 2010-07-08T12:50:01 *** pmplett has joined #evergreen 2010-07-08T13:19:04 Anyone run into a problem w/ Apache after an aptitude upgrade to latest one? I've got a choice between "cannot bind to 0.0.0.0:80" and a "segmentation fault"... 2010-07-08T13:28:55 anyone object to me wiring up the opac.barcode_regex setting to the patron editor (and the Retrieve Patron interface)? 2010-07-08T13:29:46 phasefx: to what end? 2010-07-08T13:30:24 folks are entering leading/trailing spaces. Those get stripped in the latter interface 2010-07-08T13:32:35 *** b_bonner has joined #evergreen 2010-07-08T13:36:16 in the case of the retrieve patron by barcode interface, I could just make it warning if the entered barcode does not validate against the regexp 2010-07-08T13:38:40 but for the patron editor.. we could require that the barcode match the regexp, and that usrname either equals the barcode, or does not match the regexp 2010-07-08T13:57:40 *** kmlussier has joined #evergreen 2010-07-08T13:59:18 *** shopkins has quit IRC 2010-07-08T14:01:56 *** mrpeters-isl has quit IRC 2010-07-08T15:20:51 *** pmplett is now known as pmpafk 2010-07-08T15:26:24 *** dbs has joined #evergreen 2010-07-08T15:47:30 *** kmlussier has quit IRC 2010-07-08T15:48:16 *** kmlussier has joined #evergreen 2010-07-08T15:49:49 *** granitize has quit IRC 2010-07-08T16:25:11 phasefx: looking at persist_helper(), trying to figure out what it would take to make the last MARC template that was chosen sticky - am I looking in the right area? 2010-07-08T16:27:40 phasefx: also, thanks for the tip on dojo in marcedit.js; didn't see it pulled in in marcedit.xul so I was leery, figured I would get something working first and make it purty later 2010-07-08T16:39:17 *** gdunbar has quit IRC 2010-07-08T16:42:59 *** Melissa has left #evergreen 2010-07-08T16:43:12 *** kmlussier has quit IRC 2010-07-08T16:48:23 *** sfortin has quit IRC 2010-07-08T17:15:08 *** b_bonner has quit IRC 2010-07-08T17:15:17 *** pmpafk is now known as pmplett 2010-07-08T17:25:01 *** yboston has quit IRC 2010-07-08T17:30:13 *** Dyrcona has quit IRC 2010-07-08T17:32:57 *** jenny1 has left #evergreen 2010-07-08T17:36:03 *** dbs has quit IRC 2010-07-08T17:51:18 *** _bott_ has quit IRC 2010-07-08T17:51:56 *** _bott_ has joined #evergreen 2010-07-08T18:11:08 @later tell dbs persist_helper is all about setting attributes on an element, so if you change an attribute on an element, and that attribute is itself listed in the oils_persist attribute on the same element, then there are two situations for what can happen next: 2010-07-08T18:11:08 phasefx: The operation succeeded. 2010-07-08T18:12:29 @later tell dbs certain elements with @oils_persist defined will get special event handlers added to them when persist_helper() is invoked. Those event handlers will save attributes whenever they catch the event 2010-07-08T18:12:29 phasefx: The operation succeeded. 2010-07-08T18:14:32 *** alxp has quit IRC 2010-07-08T18:15:20 @later tell dbs ah, looks like I put more into it than I remembered. Every element will get an event handler for a virtual event called "oils_persist", and then by default certain types of elements get handlers for real events, that merely fire the virtual event 2010-07-08T18:15:20 phasefx: The operation succeeded. 2010-07-08T18:16:26 @later tell dbs you can fire the virtual eventually manually with the oils_persist() function if needed 2010-07-08T18:16:26 phasefx: The operation succeeded. 2010-07-08T18:16:43 @later tell dbs s/eventually/event/ 2010-07-08T18:16:43 phasefx: The operation succeeded. 2010-07-08T18:17:58 @later tell dbs you can also dictate a list of events for persist_helper to handle with the oils_persist_events attribute for a given element 2010-07-08T18:17:58 phasefx: The operation succeeded. 2010-07-08T18:19:25 @later tell dbs sadly, all these events are surrogates for what we're really interested in, a change-attribute-event. I think some future DOM models might have stuff like that 2010-07-08T18:19:25 phasefx: The operation succeeded. 2010-07-08T18:41:38 *** youdonotexist has quit IRC 2010-07-08T19:11:21 @later tell dbs can any empty string for an entity break the i18n build? 2010-07-08T19:11:21 phasefx: The operation succeeded. 2010-07-08T19:39:59 *** pmplett has quit IRC 2010-07-08T19:47:48 *** dbs has joined #evergreen 2010-07-08T19:48:01 phasefx: thanks for the flood of tips 2010-07-08T19:48:48 No, not just any empty string can break i18n. It takes a special confluence of a bad i18n build with a previous script and that particular empty string. 2010-07-08T19:49:45 persist stuff sounds pretty complex; more than my little mind can handle atm 2010-07-08T19:50:31 was trying to figure out how in the heck saving a record in the MARC editor is now generating the and elements in the saved MARC record 2010-07-08T19:50:57 stubbed out my changes in case it was a regression, but will roll the thing back completely tomorrow when I've had some sleep 2010-07-08T19:51:11 * dbs adapts to late-night hacking in any time zone 2010-07-08T19:51:13 *** dbs has quit IRC 2010-07-08T19:56:28 @later tell dbs I have a [Swap editor type] button for the marc editor that flips between the xul editor and an xhtml:textbox markbreaker editor ... will commit soon ... just a heads up 2010-07-08T19:56:28 miker_: Error: "Swap" is not a valid command. 2010-07-08T19:56:46 @later tell dbs I have a "Swap editor type" button for the marc editor that flips between the xul editor and an xhtml:textbox markbreaker editor ... will commit soon ... just a heads up 2010-07-08T19:56:46 miker_: The operation succeeded. 2010-07-08T20:23:54 @later tell dbs there's also util.widgets.save_attributes and .load_attributes, as another mechanism you could use, if you don't like persist. Or I can persist-ify your widget after you commit if you'd like 2010-07-08T20:23:54 phasefx: The operation succeeded. 2010-07-08T20:28:39 *** _bott_ has left #evergreen 2010-07-08T23:55:02 *** mck9 has left #evergreen