uPortal IRC Logs-2009-05-18

Owned by Apereo Infrastructure
Last updated: May 18, 2009Version comment

[23:59:22 EDT(-0400)] * tsnfoo (n=tsnfoo@cpe-173-88-27-191.columbus.res.rr.com) has joined ##uportal
[00:07:35 EDT(-0400)] * tsnfoo_ (n=tsnfoo@140.141.92.6) has joined ##uportal
[03:33:46 EDT(-0400)] * higmad (n=chatzill@pcit-8752.hig.se) has joined ##uportal
[09:14:41 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[09:19:45 EDT(-0400)] * tsnfoo (n=tsnfoo@wso-mbp15.test.denison.edu) has joined ##uportal
[09:33:05 EDT(-0400)] * [jlee] (n=jlee@adsl-219-42-56.asm.bellsouth.net) has joined ##uportal
[11:07:19 EDT(-0400)] * SusanBramhall (i=susanbra@susan-x200.its.yale.edu) has joined ##uportal
[11:36:00 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:41:10 EDT(-0400)] <SusanBramhall> commit question
[11:41:22 EDT(-0400)] <SusanBramhall> for anyone...
[11:44:20 EDT(-0400)] <SusanBramhall> We are still using xslt and web proxy channels. 3.1 has new feature for these called GCCC (global content caching). It has a bug in it such that cache entries never expire. since Yale is using it I created and tested a fix for uportal 3.1.1. I am a committer but have committed in so so long that i wanted to get a go ahead before doing it.
[11:44:32 EDT(-0400)] <SusanBramhall> jira is http://www.ja-sig.org/issues/browse/UP-2434
[11:53:12 EDT(-0400)] * apetro (n=apetro@ip68-3-207-51.ph.ph.cox.net) has joined ##uportal
[11:53:22 EDT(-0400)] <holdorph> i'm sure you remember that you need to do it in both the branch and trunk, right?
[11:55:29 EDT(-0400)] <SusanBramhall> i did think of that... but would have forgotten.
[11:56:13 EDT(-0400)] <holdorph> otherwise, I'd say full speed ahead
[11:59:53 EDT(-0400)] <athena> SusanBramhall: did the web proxy portlet ever get any casification?
[12:00:08 EDT(-0400)] <athena> i'm pretty sure someone told me some work was done on that, but i can't remember who i talked to about it
[12:00:38 EDT(-0400)] <athena> actually probably the best way tto change it would be to do it in the trunk, then backport it to the branch using svnmerge
[12:10:51 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[12:42:22 EDT(-0400)] <SusanBramhall> athena: we aren't using web proxy portlet (yet) still on channels until next release
[12:42:37 EDT(-0400)] <athena> ok - i wasn't sure if you'd checked it out yet or not
[12:42:44 EDT(-0400)] <athena> i don't see any evidence of casification
[12:42:55 EDT(-0400)] <athena> although i could swear someone told me some school had worked on it
[12:43:07 EDT(-0400)] <SusanBramhall> this is a fix to the channel - GCCC is implemented in the CGenericXSLT and webproxy channels
[12:55:46 EDT(-0400)] * Sememmon (n=Sememmon@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[13:01:02 EDT(-0400)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[13:02:16 EDT(-0400)] * apetro_ (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[13:13:06 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[14:25:25 EDT(-0400)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[15:04:08 EDT(-0400)] * apetro_ (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[15:15:46 EDT(-0400)] <athena> so, i'd added a unique key on the fname column for channels in uportal
[15:15:53 EDT(-0400)] <athena> which seemed appropriate
[15:15:54 EDT(-0400)] <EricDalquist> +1
[15:16:11 EDT(-0400)] <athena> the one issue is it prevents you from re-using that fname after you "delete" a channel
[15:16:21 EDT(-0400)] <EricDalquist> yeah
[15:16:25 EDT(-0400)] <athena> because current deletion actually is un-approval of the channel
[15:16:32 EDT(-0400)] <EricDalquist> well we probably want to look at changing that to a real delete
[15:16:43 EDT(-0400)] <athena> well, there's also that whole lifecycle discussion
[15:16:49 EDT(-0400)] <athena> which i'm hoping to follow up w/ gary on this week
[15:16:50 EDT(-0400)] <EricDalquist> yeah
[15:17:00 EDT(-0400)] <athena> it seems like we probably really want both "disapprove" and "delete"
[15:17:10 EDT(-0400)] <EricDalquist> or for a short term hack do a dirty trick with the fname when you 'delete' right now
[15:17:29 EDT(-0400)] <EricDalquist> change it to originalFname_DELETED_TIMESTAMP
[15:17:35 EDT(-0400)] <athena> oh hm, interesting point (smile)
[15:17:41 EDT(-0400)] <EricDalquist> not my prefered solution
[15:17:46 EDT(-0400)] <athena> yeah
[15:17:46 EDT(-0400)] <EricDalquist> but until the lifecycle stuff is fixed
[15:17:51 EDT(-0400)] <athena> that sounds reasonable
[15:17:52 EDT(-0400)] <EricDalquist> that may be a valid hack
[15:17:59 EDT(-0400)] <athena> yeah, i think that's a reasonable solution
[15:18:05 EDT(-0400)] <athena> better than taking the constraint off anyway
[15:18:17 EDT(-0400)] <EricDalquist> I was even thinking that we could create a fnametype for hibernate
[15:18:26 EDT(-0400)] <EricDalquist> similar to the custom string and text types we have right now
[15:18:28 EDT(-0400)] <athena> i just don't want to make anyone's life hard until we get all the lifecycle stuff implemented, because i don't think it'll be in the next couple weeks
[15:18:43 EDT(-0400)] <athena> interesting
[15:18:46 EDT(-0400)] <EricDalquist> that enforces the [a-zA-Z0-9_-] restriction
[15:18:50 EDT(-0400)] <athena> ah! cool
[15:18:56 EDT(-0400)] <athena> yeah that's some validation that i haven't added yet
[15:18:59 EDT(-0400)] <EricDalquist> since fnames are a concept that will likely spread
[15:19:12 EDT(-0400)] <athena> should at least add that to the form validator, but having that be at a lower level as well sounds like a good idea
[15:19:22 EDT(-0400)] <athena> what other custom types do we have now?
[15:20:59 EDT(-0400)] <EricDalquist> take a look in org.jasig.portal.dao.usertype
[15:21:11 EDT(-0400)] <EricDalquist> we currently use EscapedTextType and EscapedStringType
[15:21:26 EDT(-0400)] <EricDalquist> for places where we need to store a string and the difference between null and "" matters
[15:21:31 EDT(-0400)] <EricDalquist> since oracle is dumb about that
[15:22:27 EDT(-0400)] <athena> ah, gotcha
[15:23:25 EDT(-0400)] <athena> by the way, i had some questions about how we want to treat editing portlets
[15:23:32 EDT(-0400)] <EricDalquist> ok
[15:24:05 EDT(-0400)] <athena> right now i have things set up such that if you edit a portlet and you've set up some sort of manual preference nto through the UI, you'll probably lose it
[15:24:39 EDT(-0400)] <athena> because it goes through and validates the parameters and preferences that are defined in the CPD, then only adds other preferences and parameters if the portlet defines an arbitrary parameters or preferences section
[15:24:52 EDT(-0400)] <EricDalquist> ah
[15:25:00 EDT(-0400)] <athena> in some ways it seems like the right thing to do, since you'd get updates if you change the channel type or the CPD changes
[15:25:16 EDT(-0400)] <EricDalquist> can we just not present the UI to set arbitrary prefs section if it is not specified in the cpd?
[15:25:17 EDT(-0400)] <athena> but less good if you intentionally set a parameter or preference by editing directly in the database
[15:25:29 EDT(-0400)] <EricDalquist> ah
[15:25:29 EDT(-0400)] <EricDalquist> well
[15:25:37 EDT(-0400)] <EricDalquist> that should never be the case
[15:25:43 EDT(-0400)] <athena> yes
[15:25:48 EDT(-0400)] <EricDalquist> manually editing hibernate managed tables is asking for disaster
[15:25:59 EDT(-0400)] <athena> and presumably if a parameter disappeared in the CPD, you probably don't need it in your config anymore either
[15:26:05 EDT(-0400)] <EricDalquist> yeah
[15:26:36 EDT(-0400)] <athena> so does that seem like the right way to handle orphaned preferences?
[15:26:57 EDT(-0400)] <athena> i kind of don't really want to have preferences that stick around forever that you can't edit in the UI
[15:27:18 EDT(-0400)] <EricDalquist> yeah
[15:27:21 EDT(-0400)] <EricDalquist> I think so
[15:27:28 EDT(-0400)] <EricDalquist> perhaps log what happens at WARN
[15:27:37 EDT(-0400)] <EricDalquist> since it should be fairly rare that shouldn't pollute logs
[15:27:43 EDT(-0400)] <EricDalquist> but likely won't get lost either
[15:27:51 EDT(-0400)] <athena> sounds reasonable
[15:28:04 EDT(-0400)] <athena> i was thinking maybe we want a confirmation screen when someone changes the channel type?
[15:28:20 EDT(-0400)] <EricDalquist> oh
[15:28:28 EDT(-0400)] <EricDalquist> that is a new feature then huh?
[15:28:40 EDT(-0400)] <athena> make sure users really want to change the type (since that affects the parameters), and then if they really do, only copy over the parameters that are still relevant
[15:28:49 EDT(-0400)] <athena> well, it doesn't exist yet, but potentially yes (smile)
[15:28:55 EDT(-0400)] <athena> i don't know what CChannelManager does
[15:29:03 EDT(-0400)] <EricDalquist> you can't
[15:29:06 EDT(-0400)] <athena> oh, really?
[15:29:11 EDT(-0400)] <EricDalquist> I don't think so
[15:29:12 EDT(-0400)] <athena> i didn't realize that
[15:29:15 EDT(-0400)] <EricDalquist> there is no back button on the first screen
[15:29:38 EDT(-0400)] <athena> ah, interesting
[15:29:42 EDT(-0400)] <EricDalquist> oh
[15:29:43 EDT(-0400)] <EricDalquist> wit
[15:29:44 EDT(-0400)] <EricDalquist> there is
[15:29:45 EDT(-0400)] <EricDalquist> hrm
[15:29:50 EDT(-0400)] <athena> i thought you could edit it for an already-persisted channel
[15:29:52 EDT(-0400)] <EricDalquist> I guess I don't know
[15:29:58 EDT(-0400)] <athena> i don't know what it does w/ the existing parameters
[15:29:58 EDT(-0400)] <EricDalquist> seems dangerous
[15:30:02 EDT(-0400)] <athena> yeah, it does
[15:30:04 EDT(-0400)] <EricDalquist> I'd actually vote to disable that
[15:30:15 EDT(-0400)] <athena> force a user to just re-create it?
[15:30:25 EDT(-0400)] <EricDalquist> I'm trying to thing when it would be useful?
[15:30:49 EDT(-0400)] <athena> at yale i know we used it to update channels without causing them to disappear from user layouts
[15:31:00 EDT(-0400)] <EricDalquist> tricky
[15:31:03 EDT(-0400)] <athena> so say we moved from the old columbia weather channel to the new weather portlet
[15:31:12 EDT(-0400)] <athena> we'd update the channel, leaving the old fname and such in place
[15:31:16 EDT(-0400)] <EricDalquist> ah
[15:31:34 EDT(-0400)] <athena> that way it would continue to be valid for any users that had manually added it to their layout
[15:31:44 EDT(-0400)] <athena> instead of just disappearing or displaying a "missing" error
[15:31:58 EDT(-0400)] <EricDalquist> yeah
[15:32:03 EDT(-0400)] <EricDalquist> so I guess that is reasonable
[15:32:07 EDT(-0400)] <athena> but if you were trying to do something like that you wouldn't want all the old prefs copied over
[15:32:10 EDT(-0400)] <EricDalquist> but a warning would probably be good
[15:32:14 EDT(-0400)] <athena> as they wouldn't make sense anymore
[15:32:15 EDT(-0400)] <athena> yeah
[15:32:28 EDT(-0400)] <EricDalquist> 'warning, changing channel types will cause all parameters and preferences to be cleared'
[15:32:37 EDT(-0400)] <athena> yeah
[15:41:00 EDT(-0400)] <SusanBramhall> how hard would it be to skin the swapped user courtesy of identity swapper similar to the fragment admin. it would be great to have a colorful remonder of that the identity is swapped. Are the two funstions using similar implementations or completely different?
[15:41:26 EDT(-0400)] <EricDalquist> they are using the same code to achieve the id swap
[15:41:36 EDT(-0400)] <EricDalquist> no idea how the special skin for swapped fragments is getting triggered
[15:41:54 EDT(-0400)] <SusanBramhall> cool - so perhaps could get similar skinning behavior
[15:42:17 EDT(-0400)] <EricDalquist> yeah
[15:42:30 EDT(-0400)] <EricDalquist> awills did the swapped fragment skinning I think
[15:42:35 EDT(-0400)] <SusanBramhall> hidden channel in header i think but will look into it if i get a chance
[15:45:47 EDT(-0400)] <SusanBramhall> on the topic of 'warning, changing channel types will cause all parameters and preferences to be cleared' - that's not the experience we've had
[15:46:25 EDT(-0400)] <SusanBramhall> more like all the old parameters hang around in the database and show up on the exported channel but are not displayed because cpd doesn't know about them
[15:47:07 EDT(-0400)] <SusanBramhall> we pruned some off between export and import
[15:50:34 EDT(-0400)] <EricDalquist> yeah, so this would be a fix for that
[15:50:41 EDT(-0400)] <SusanBramhall> ahhh
[15:50:51 EDT(-0400)] <EricDalquist> the code would explicitly purge prefs & params when you switched types
[15:51:19 EDT(-0400)] <SusanBramhall> perfect
[16:31:43 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[19:14:48 EDT(-0400)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[19:25:07 EDT(-0400)] * SusanB (i=susanbra@dhcp128036045008.central.yale.edu) has joined ##uportal
[19:28:30 EDT(-0400)] * tsnfoo (n=tsnfoo@cpe-173-88-27-191.columbus.res.rr.com) has joined ##uportal
[20:07:21 EDT(-0400)] * SusanBramhall (i=susanbra@susan-x200.its.yale.edu) has joined ##uportal
[20:39:17 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has left ##uportal
[22:11:18 EDT(-0400)] * Sememmon (n=Sememmon@ip70-190-32-223.ph.ph.cox.net) has joined ##uportal