uPortal IRC Logs-2009-03-10

Owned by Apereo Infrastructure
Last updated: Mar 10, 2009Version comment
8 min read

[04:54:49 EDT(-0400)] * higmad (n=chatzill@pcit-8752.hig.se) has joined ##uportal
[08:39:28 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[08:41:08 EDT(-0400)] * anastasiac (n=stasia@142.150.154.189) has joined ##uportal
[09:17:58 EDT(-0400)] <dstn> what are <dlm-positionSet>'s and where are they supposed to reside in a .layout?
[09:20:36 EDT(-0400)] * dstn doesn't understand the internals of dlm
[09:24:02 EDT(-0400)] * athena doesn't know
[09:24:14 EDT(-0400)] <dstn> (sad)
[09:24:18 EDT(-0400)] <athena> i've been seeing some weird issues the last day or to in trunk :/
[09:24:28 EDT(-0400)] <athena> i'm hoping it's just me - i haven't had time to investigate
[09:24:31 EDT(-0400)] <dstn> oh ya, like what?
[09:24:36 EDT(-0400)] <athena> the tab i added seems to randomly move around
[09:24:42 EDT(-0400)] <dstn> lol
[09:25:10 EDT(-0400)] <athena> and sometimes i wind up with the content of a channel stuck towards the top of the page and cant' get rid of it
[09:25:25 EDT(-0400)] <dstn> weird
[09:25:34 EDT(-0400)] <dstn> weird issues are the story of my life
[09:26:52 EDT(-0400)] <athena> taken out of context that may not completely be the message you want to broadcast (tongue)
[09:27:22 EDT(-0400)] <dstn> you trying to say I have issues?
[09:27:33 EDT(-0400)] * dstn knows this already
[09:27:42 EDT(-0400)] <dstn> :-p
[09:28:25 EDT(-0400)] <athena> lol
[09:28:30 EDT(-0400)] <athena> hey i'm not saying anything!
[09:28:48 EDT(-0400)] <athena> but i do hope that you were talking about import/export
[09:28:48 EDT(-0400)] <athena> lol
[09:29:11 EDT(-0400)] <athena> i do understand some of the DLM internals, but i'm not sure about the position setes
[09:29:13 EDT(-0400)] <athena> er, sets
[09:29:25 EDT(-0400)] <athena> so you may have to wait for someone west of us to wake up
[09:30:23 EDT(-0400)] <dstn> lol
[09:30:59 EDT(-0400)] * dstn wishes DLM was more documented
[09:39:17 EDT(-0400)] <athena> yeah
[09:39:34 EDT(-0400)] <athena> i worry that we don't have a lot of people who know a lot about DLM these days
[09:39:44 EDT(-0400)] <athena> sad that mark boyd left
[09:40:35 EDT(-0400)] <dstn> ya, its definitely esoteric
[10:07:56 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined ##uportal
[10:08:27 EDT(-0400)] <dstn> athena, what happened to all the icons in media skins? did they get moved to the resource server?
[10:08:33 EDT(-0400)] <athena> yes
[10:08:34 EDT(-0400)] <dstn> in RC2
[10:08:35 EDT(-0400)] <dstn> ok
[10:08:40 EDT(-0400)] <dstn> thanks
[10:08:41 EDT(-0400)] <athena> all the ones that were part of the famfamfam icon set anyway
[10:08:51 EDT(-0400)] <athena> there are still a few up-specific ones that seem to have been added there
[10:09:05 EDT(-0400)] <athena> you should be able to include images the same way you'd include javascript files from the resource server
[10:09:14 EDT(-0400)] <athena> and as of rc2, they should have appropriate cache headers
[10:09:24 EDT(-0400)] <athena> i also added the famfamfam international flags set of icons
[10:12:42 EDT(-0400)] <dstn> sweet
[11:12:02 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:22:34 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[11:32:51 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:58:50 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[12:06:54 EDT(-0400)] <athena> hi colinclark - do you guys need any help getting your daily uportal build back up and running?
[12:07:19 EDT(-0400)] <athena> gary said he and jacob were looking to do a code review tomorrow
[13:06:34 EDT(-0400)] * dstn is merging RC2
[13:13:45 EDT(-0400)] <EricDalquist> (smile)
[13:14:52 EDT(-0400)] <dstn> EricDalquist, do you have time today to help me with understand dlm:positionSets and dlm:editsets in a .layout file? I'm not sure where they are supposed to reside and under what conditions and even what they are...
[13:15:04 EDT(-0400)] <dstn> understanding*
[13:15:22 EDT(-0400)] <EricDalquist> I can probably answer a few questions
[13:15:41 EDT(-0400)] <EricDalquist> are you familiar with how DLM works when tracking a user's changes?
[13:15:41 EDT(-0400)] <dstn> ok
[13:15:50 EDT(-0400)] * dstn admits he is not
[13:16:45 EDT(-0400)] <EricDalquist> so in DLM when you move something what DLM does is add a node in the destination location as to what you moved
[13:16:51 EDT(-0400)] <EricDalquist> deleting is similar
[13:17:02 EDT(-0400)] <EricDalquist> a delete set keeps track of the nodes that you have deleted from the fragment
[13:17:54 EDT(-0400)] <EricDalquist> when building your layout DLM looks at those move and delete nodes, looks up the references and tries to apply the changes (moves, deletes) as long as the dlm permissions still allow them
[13:19:37 EDT(-0400)] <EricDalquist> in the database the node references use actual layout ids:
[13:19:51 EDT(-0400)] <EricDalquist> u123l1n34 (user 123, layout 1, node 34)
[13:20:17 EDT(-0400)] <EricDalquist> when we export the data we look that up into a layout owner and a XPath expression to the node
[13:22:15 EDT(-0400)] <dstn> like this right: user:/layout/root/tab[2]/column[2]/channel[1]
[13:28:55 EDT(-0400)] <EricDalquist> right
[13:32:50 EDT(-0400)] * dstn finished merging RC2 with no conflicts
[13:32:55 EDT(-0400)] <dstn> now to test
[13:33:07 EDT(-0400)] <athena> woo
[14:19:45 EDT(-0400)] <dstn> RC2 runs on the import I did with RC1
[14:28:10 EDT(-0400)] <EricDalquist> right
[14:28:18 EDT(-0400)] <EricDalquist> I don't; think there were any db changes
[14:28:33 EDT(-0400)] <dstn> ok, just reporting for testing purposes I guess ;-D
[14:36:57 EDT(-0400)] <EricDalquist> good to know though (smile)
[14:37:14 EDT(-0400)] <athena> by the way, did anyone ever figure out what adam's problem with the 3.0.3 build was?
[14:37:33 EDT(-0400)] <EricDalquist> no idea
[14:37:53 EDT(-0400)] <dstn> no, but Susan has the same problems occasionally
[14:38:06 EDT(-0400)] <dstn> its always on first check out
[14:38:19 EDT(-0400)] <EricDalquist> weird
[14:38:51 EDT(-0400)] <athena> so like build once and get it, build again and don't get it?
[14:54:07 EDT(-0400)] <dstn> ya, exactly
[14:58:30 EDT(-0400)] <athena> hm, interesting
[14:59:33 EDT(-0400)] <athena> i thought adam wasn't able to build it at all though - not just on first attempt
[15:10:05 EDT(-0400)] <dstn> so none of the <dlm-node>'s are touched by the export-layout.xsl in exporting our layout
[15:10:49 EDT(-0400)] <dstn> the stylesheet does <xsl:apply-templates select="//dlm-node[@struct-id = $me/@next-struct-id]" mode="branch"/> at the end of the root element but the next-struct-id is always 0, not a dlm-node
[15:11:26 EDT(-0400)] <dstn> the struct-id's of the dlm-nodes are next-struct-ids of <folder> and <channel> elements that I've seen so far
[15:16:49 EDT(-0400)] <dstn> so I added some xsl:apply-templates to follow the struct-ids and I get an layout but I am honestly not sure it makes sense
[15:17:14 EDT(-0400)] <dstn> This is what it looks like
[15:17:15 EDT(-0400)] <dstn> http://uportal.pastebin.com/m6e7c450b
[15:17:47 EDT(-0400)] <dstn> specifically I'm not sure about the <dlm:positionSet> that are underneath the footer folder
[15:21:03 EDT(-0400)] <dstn> and this is the pre xslt of the users layout: http://uportal.pastebin.com/m431bbd1a
[15:24:24 EDT(-0400)] <athena> hm, apparently adam's error doesn't go away on windows
[15:26:57 EDT(-0400)] <dstn> oh, then perhaps the problems are different
[15:27:05 EDT(-0400)] <dstn> Susan's went away
[15:27:06 EDT(-0400)] <athena> perhaps
[15:27:10 EDT(-0400)] <athena> sounds similar, but not the same
[15:48:54 EDT(-0400)] <dstn> so db target in RC2 has a failonerror="true" which causes a failed build when oracle tries to create an index that already exists
[15:49:44 EDT(-0400)] <EricDalquist> dstn: just got back from a meeting ...
[15:50:20 EDT(-0400)] <dstn> k, would love to hear if you have any input on the dlm-node stuff...not sure where to go on that
[15:54:22 EDT(-0400)] <EricDalquist> dstn: I think what you've done makes sense
[15:54:42 EDT(-0400)] <EricDalquist> when I did the original dlm node handling work we only let users modify channels within a tab
[15:54:56 EDT(-0400)] <EricDalquist> it looks like your user re-arranged their tab ordering
[15:55:16 EDT(-0400)] <EricDalquist> which is why the positionSet is a child of <root>
[15:55:36 EDT(-0400)] <EricDalquist> so adding the xsl:apply-templates call is probably appropriate
[15:55:45 EDT(-0400)] <EricDalquist> though I'm not sure the import code will handle that right
[15:56:10 EDT(-0400)] <EricDalquist> it was all written to assume position and move nodes referred to channels
[15:56:11 EDT(-0400)] <EricDalquist> grr
[15:56:35 EDT(-0400)] <dstn> i c
[15:56:44 EDT(-0400)] <EricDalquist> I'm also not 100% sure on the support for the editSet and what exactly those did
[15:56:51 EDT(-0400)] <EricDalquist> but for the tab positionSet import
[15:57:03 EDT(-0400)] <EricDalquist> it will likely give you warning messages about not being able to find the right channel
[15:57:42 EDT(-0400)] <dstn> ok well that makes me feel a bit better
[15:58:02 EDT(-0400)] <EricDalquist> yeah, this is likely a bug in both the export and import
[15:58:24 EDT(-0400)] <EricDalquist> what would be really handy is if I could look at the DB data for this user and the fragment owners
[15:58:31 EDT(-0400)] <EricDalquist> I'm just not sure what exactly the edit set does
[15:58:47 EDT(-0400)] <dstn> my original statement about the root next-struct-id always being zero was not entirely correct, there are some users with a non-zero next-struct-id that leads a a dlm-deleteSet
[15:59:13 EDT(-0400)] <dstn> which fails outside of root
[15:59:28 EDT(-0400)] <EricDalquist> right
[15:59:30 EDT(-0400)] <dstn> I think I get the data
[15:59:49 EDT(-0400)] <dstn> brb
[16:00:34 EDT(-0400)] <EricDalquist> brb here as well ...
[16:07:01 EDT(-0400)] <EricDalquist> I have a few ideas when you get back dstn
[16:17:39 EDT(-0400)] <dstn> back
[16:18:13 EDT(-0400)] <dstn> so how do you want the data? excel or just raw sql or what?
[16:18:48 EDT(-0400)] <EricDalquist> hrm ... well I haven't even thought about the edit node yet
[16:18:57 EDT(-0400)] <EricDalquist> just thinking about the tab position set
[16:19:21 EDT(-0400)] <dstn> k
[16:20:40 EDT(-0400)] <dstn> maybe editset is renaming a tab?
[16:21:01 EDT(-0400)] <EricDalquist> I think that may be it
[16:21:04 EDT(-0400)] * dstn has to leave in 10 so you know
[16:21:07 EDT(-0400)] <EricDalquist> ok
[16:21:13 EDT(-0400)] <EricDalquist> well just an overview for now then
[16:21:35 EDT(-0400)] <EricDalquist> what is likely going to need to happen is that lookup-dlm-noderef.crn becomes a little more flexible
[16:21:54 EDT(-0400)] <EricDalquist> right now it assumes it is exporting a reference to a <channel>
[16:22:15 EDT(-0400)] <EricDalquist> we need to extend it so it checks the node type it finds
[16:22:29 EDT(-0400)] <EricDalquist> and writes out the NODEREF_DATA array correctly
[16:22:36 EDT(-0400)] <EricDalquist> the NODEREF_DATA array is likely also going to need to change
[16:22:37 EDT(-0400)] <EricDalquist> (sad)
[16:22:43 EDT(-0400)] <EricDalquist> this is probably going to be a pita
[16:22:49 EDT(-0400)] <dstn> lol
[16:23:20 EDT(-0400)] <dstn> so I discussed this with my manager a minute ago and we may be able to let Unicon do some of this work
[16:23:30 EDT(-0400)] <EricDalquist> right now for NODEREF_DATA [0]=referenced layout owner name, [1]=xpath, [2]=fname
[16:23:34 EDT(-0400)] * athena thinks that sounds like a most excellent idea
[16:23:45 EDT(-0400)] <dstn> of course she does
[16:23:48 EDT(-0400)] <athena> (smile)
[16:23:49 EDT(-0400)] <dstn> :-D
[16:23:51 EDT(-0400)] <EricDalquist> it is going to need to return an additional bit of data which is the targeted node type
[16:23:58 EDT(-0400)] <EricDalquist> so channel/tab/?
[16:24:12 EDT(-0400)] <EricDalquist> and the fname becomes more a generic 'key' value that depends on the type
[16:24:27 EDT(-0400)] * dstn is looking at lookup-dlm-noderef
[16:24:55 EDT(-0400)] <EricDalquist> it is going to be interesting to see if this can be fixable and still fit into a 3.0 format .layout file
[16:25:09 EDT(-0400)] <EricDalquist> so line 108 of lookup-dlm-noderef
[16:25:29 EDT(-0400)] <EricDalquist> that is where it finds the layout node the dlm node is pointing to
[16:26:05 EDT(-0400)] <EricDalquist> DrewW really needs to read this conversation
[16:26:21 EDT(-0400)] <EricDalquist> so once lookup is fixed to return four bits of data instead of 3
[16:26:41 EDT(-0400)] <EricDalquist> all the places that call it need to be updated to handle the type value correctly
[16:26:52 EDT(-0400)] <EricDalquist> and really we should replace that array with a Map or a strongly typed object
[16:27:02 EDT(-0400)] <EricDalquist> because passing data around in an array like that is ... dumb
[16:29:44 EDT(-0400)] * dstn needs to absorb this more
[16:33:44 EDT(-0400)] * athena waves a magic wand and turns dstn into a sponge
[16:34:32 EDT(-0400)] <holdorph> Sponge Dustin Square Pants?
[16:39:40 EDT(-0400)] <dstn> wow, that's so helpful, thanks
[16:39:58 EDT(-0400)] <EricDalquist> no problem ... that is only part of it
[16:40:25 EDT(-0400)] <EricDalquist> once that is done we have to figure out how to make .layout files deal with different types of noderefs (probably not that hard)
[16:40:43 EDT(-0400)] <EricDalquist> then we have to make the import deal with the different types of noderefs
[16:40:48 EDT(-0400)] <EricDalquist> which I haven't even thought about yet
[16:40:58 EDT(-0400)] <EricDalquist> just getting the data exporting correctly first is the big thing
[17:41:00 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[17:58:19 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has left ##uportal
[18:01:13 EDT(-0400)] * SusanBramhall (i=susanbra@susan-x200.its.yale.edu) has joined ##uportal
[18:02:26 EDT(-0400)] <SusanBramhall> i have a question - not sure if should be on a list or here..
[18:44:28 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[18:53:32 EDT(-0400)] * awills (n=awills@208.71.38.194) has joined ##uportal
[18:53:39 EDT(-0400)] * awills (n=awills@208.71.38.194) has left ##uportal
[19:06:40 EDT(-0400)] * awills (n=awills@208.71.38.194) has joined ##uportal
[19:06:57 EDT(-0400)] * awills (n=awills@208.71.38.194) has left ##uportal
[20:35:56 EDT(-0400)] * tsnfoo_ (n=tsnfoo@cpe-65-24-108-125.columbus.res.rr.com) has joined ##uportal
[21:18:16 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[22:38:35 EDT(-0400)] * apetro (n=apetro@static-68-161-246-193.ny325.east.verizon.net) has joined ##uportal
[22:54:27 EDT(-0400)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has joined ##uportal