uPortal IRC Logs-2009-05-29

[03:34:19 EDT(-0400)] * higmad (n=chatzill@pcit-8752.HIG.SE) has joined ##uportal
[09:35:38 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[10:02:07 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined ##uportal
[10:02:30 EDT(-0400)] * michelled (n=team@142.150.154.193) has left ##uportal
[10:02:53 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined ##uportal
[10:08:56 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[10:09:53 EDT(-0400)] * invisibill (i=80876350@gateway/web/ajax/mibbit.com/x-c7f0d57b0103e1ca) has joined ##uportal
[10:33:50 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[10:35:44 EDT(-0400)] <athena> EricDalquist: it seems to me like it shouldn't be possible to access the web proxy portlet ProxyServlet without first acquiring a session through the WebProxyPortlet class
[10:35:48 EDT(-0400)] <athena> does that seem right to you?
[10:36:01 EDT(-0400)] <EricDalquist> I believe so
[10:36:08 EDT(-0400)] <athena> ok, cool
[10:36:21 EDT(-0400)] <EricDalquist> and even with a session it shouldn't proxy arbitrary URLs
[10:36:31 EDT(-0400)] <athena> it seems like it should be safe to count on being able to retrieve an already-existing HttpManager from the user session
[10:36:32 EDT(-0400)] <EricDalquist> It should be getting the URL to proxy from the session
[10:36:37 EDT(-0400)] <EricDalquist> yeah
[10:36:40 EDT(-0400)] <athena> rather than also having logic to create it if it doesnt' currently exist
[10:36:55 EDT(-0400)] <athena> which i think would simplify the logic, and also make it easier to do the shibboleth setup
[10:55:10 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:58:18 EDT(-0400)] <EricDalquist> are there any known issues with rendering a channel by fname for the guest user?
[11:00:07 EDT(-0400)] <athena> hm, good question
[11:00:19 EDT(-0400)] <athena> i know it works at yale, but i also know that was at one point a local mod
[11:00:23 EDT(-0400)] <athena> and i don't knwo if that was contributed back
[11:00:30 EDT(-0400)] <EricDalquist> it looks like it has to do with the layout caching
[11:00:42 EDT(-0400)] <EricDalquist> I really dislike the special handling for guest layout caching
[11:00:53 EDT(-0400)] <athena> one of the historical problems was that the guest layout uses the immutable layout, so you can't actually instantiate a channel by fname if it's not already in the layout
[11:00:59 EDT(-0400)] <athena> yeah, it's really ugly
[11:01:14 EDT(-0400)] <athena> so at yale, we had a mod to wrap that request in a transient layout handler or something
[11:01:37 EDT(-0400)] <EricDalquist> uhg
[11:01:39 EDT(-0400)] <athena> it's also really stupid that you have to restart the portal to pick up a layout change
[11:01:48 EDT(-0400)] <EricDalquist> not what I want to deal with on a Friday
[11:02:48 EDT(-0400)] <athena> seems related: http://osdir.com/ml/java.jasig.uportal.devel/2007-12/msg00007.html
[11:05:57 EDT(-0400)] <EricDalquist> oh, thanks
[11:07:09 EDT(-0400)] <EricDalquist> that's a really easy change ...
[11:14:18 EDT(-0400)] <EricDalquist> then I read the part about that change not working any more
[11:14:19 EDT(-0400)] <EricDalquist> hrm
[11:15:38 EDT(-0400)] <athena> yeah
[11:15:53 EDT(-0400)] <athena> the other thing is that seems to be a 2.6-ish thread
[11:15:58 EDT(-0400)] <EricDalquist> yeah
[11:16:08 EDT(-0400)] <athena> so i may have committed the change, but i think all that turned out to be different in 3.0
[11:16:26 EDT(-0400)] <athena> i did some initial mods for yale, but i don't know that those were ever shared
[11:17:09 EDT(-0400)] <athena> dstn might know, but i think he's probably left yale by now
[11:17:37 EDT(-0400)] <EricDalquist> ok
[11:18:55 EDT(-0400)] <athena> maybe we could get in touch with susan?
[11:19:04 EDT(-0400)] <athena> and see if she can help enable sharing those mods?
[11:19:09 EDT(-0400)] <EricDalquist> yeah
[12:18:37 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[12:49:32 EDT(-0400)] <athena> EricDalquist: it looks like the non-Simple Web Proxy Portlet doesn't work in 3.1
[12:49:45 EDT(-0400)] <athena> i think because the channel manager channel saves all the empty parameters as ""
[12:50:03 EDT(-0400)] <athena> which causes the portlet to then pass through headers like "": ""
[12:50:13 EDT(-0400)] <athena> and results in a Bad Request
[13:26:06 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[13:34:36 EDT(-0400)] <holdorph> yeh, it's mucho broken in 3.1.1
[13:34:55 EDT(-0400)] <holdorph> i submitted one jira on it, but it's even more broken then what I originally reported
[13:35:08 EDT(-0400)] <holdorph> whole screens aren't showing up any more as well.
[13:37:14 EDT(-0400)] <athena> whole screens of proxied content?
[13:37:38 EDT(-0400)] <holdorph> no whole screens in the channel publishing process
[13:37:44 EDT(-0400)] <athena> oh really?
[13:37:50 EDT(-0400)] <athena> i haven't seen that yet
[13:38:00 EDT(-0400)] <athena> is that editing already-published channels?
[13:38:37 EDT(-0400)] <athena> it seems more stable in the new portlet admin portlet, but that doesn't really help us for 3.1, unfortunately
[13:38:57 EDT(-0400)] <athena> anyway, i'm not sure what the best way to address this is
[13:39:06 EDT(-0400)] <athena> whether we should make uportal not save empty string preferences
[13:39:16 EDT(-0400)] <athena> or fix the portlet to treat null and empty string values similarly
[13:39:17 EDT(-0400)] <athena> or both
[13:39:41 EDT(-0400)] <holdorph> the jira i submitted was for editing portlets with cpd's
[13:39:45 EDT(-0400)] * Sememmon (n=Sememmon@uni1.unicon.net) has joined ##uportal
[13:39:52 EDT(-0400)] <holdorph> none of the portlet preferences show up when you modify them
[13:39:57 EDT(-0400)] <athena> i suspect that it's appropriate to update the portlet to handle empty string values properly regardless of what we do in uportal just for stability and sanity's sake
[13:40:07 EDT(-0400)] <athena> interesting
[13:40:10 EDT(-0400)] <holdorph> and then to make matters worse, reviewing and saveing will clear out values previously set
[13:40:17 EDT(-0400)] <athena> yuck
[13:40:36 EDT(-0400)] <holdorph> yeah, it's like 0.25 % better then what the 3.1.0 situation was
[13:40:45 EDT(-0400)] <athena> lol
[13:40:46 EDT(-0400)] <holdorph> you can publish SOME portlets with CPD's the first time.
[13:41:05 EDT(-0400)] <holdorph> but after that your only choice is to essentially REPUBLISH the whole dam thing again
[13:41:05 EDT(-0400)] <athena> if you have time, i'd love to hear your opinions on the parameter/preference handling in the new portlet
[13:42:14 EDT(-0400)] <athena> it does seem like my previous values stuck for the web proxy portlet
[13:42:30 EDT(-0400)] <athena> though that's one i created post-3.1, which might make a difference
[13:43:05 EDT(-0400)] <holdorph> msg'ed you a portal you can logon and try it out with
[13:43:15 EDT(-0400)] <holdorph> don't 'finish' the portlet at the moment
[13:43:30 EDT(-0400)] <holdorph> but you can try publishing a new portlet, and modifying existing ones.
[13:43:30 EDT(-0400)] <athena> gotcha
[13:43:59 EDT(-0400)] <athena> got a good target to try modifying?
[13:44:09 EDT(-0400)] <holdorph> i guess there might not be any existing full web proxy portlets to modify, but if you try publish one you'll see why
[13:44:24 EDT(-0400)] <athena> yeah, they publish quite broken
[13:44:35 EDT(-0400)] <athena> from my testing it seems to be from passing headers w/ empty names and values
[13:44:44 EDT(-0400)] <holdorph> there are a lot of simple web proxy ones, that if you modify you'll see the 'base url' which had to be filled out, doesn't get repopulated.
[13:44:47 EDT(-0400)] <athena> the proxied site generally spits back a 400 Bad Request error
[13:45:17 EDT(-0400)] <athena> were these created pre-3.1?
[13:45:37 EDT(-0400)] <holdorph> no
[13:45:42 EDT(-0400)] <athena> yeah i see what you're seeing now
[13:46:01 EDT(-0400)] <holdorph> this is a new uportal, created from the 3.1.x branch, created about 2 days before the 3.1.1 official release.
[13:46:08 EDT(-0400)] <holdorph> so it should be nearly identical to 3.1.1
[13:46:15 EDT(-0400)] <athena> i've got some guesses as to why it might be happening
[13:46:18 EDT(-0400)] <athena> ick
[14:56:27 EDT(-0400)] <athena> eclipse is attempting to kill me today.
[16:06:12 EDT(-0400)] * jessm_ (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[16:45:01 EDT(-0400)] * michelled (n=team@142.150.154.193) has left ##uportal
[17:02:25 EDT(-0400)] <holdorph> the combination of the new theme in uportal 3.1 + the old channel manager = so painful. constant scrolling, top to bottom every single screen
[17:02:50 EDT(-0400)] <athena> is it taller than in the old theme?
[17:03:08 EDT(-0400)] <holdorph> it's outlandishly taller
[17:03:12 EDT(-0400)] * athena 's experience has been that accessible or not, it's a major PITA to use
[17:03:16 EDT(-0400)] <holdorph> it's buggy taller
[17:03:24 EDT(-0400)] <athena> ah, yeah . . . i think table padding changed or something
[17:03:42 EDT(-0400)] <athena> personally i think this is yet another example of why we shouldn't be maintaining our own CSS classnames
[17:03:50 EDT(-0400)] <athena> it just makes everything that much more complicated
[17:03:52 EDT(-0400)] <holdorph> basically gary (and whomever may have helped him) never went into channel manager when designing that theme
[17:04:09 EDT(-0400)] <athena> actually he changed the HTML of the channel manager significantly
[17:04:16 EDT(-0400)] <athena> to make it meet accessibility standards
[17:04:19 EDT(-0400)] <athena> so he must have seen it
[17:04:40 EDT(-0400)] <holdorph> the best (worst) though is the groups screen
[17:04:54 EDT(-0400)] <holdorph> where the checkbox for everyone is next to close group, instead of everyone
[17:05:20 EDT(-0400)] <athena> yeah i saw that
[17:05:23 EDT(-0400)] <athena> really confusing
[17:18:46 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[20:07:11 EDT(-0400)] * Sememmon (n=Sememmon@ip70-190-32-223.ph.ph.cox.net) has joined ##uportal