Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 33 Next »

[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

  • No labels