uPortal IRC Logs-2011-03-17

[12:10:28 CDT(-0500)] <athena> EricDalquist: just to confirm, the right way to implement this badge numbers bit is to look for the portlet response property and set that as a request attribute on the servlet request?
[12:11:17 CDT(-0500)] <EricDalquist> well where do you need access to the badge # value?
[12:12:03 CDT(-0500)] <DrewWills> provavly in the theme transform
[12:12:08 CDT(-0500)] <DrewWills> er probably
[12:12:16 CDT(-0500)] <athena> yes, in the theme transform
[12:12:50 CDT(-0500)] <athena> initially implemented it sort of like the titles - added a new PortletPlaceholderEventSource and such
[12:13:03 CDT(-0500)] <EricDalquist> yeah that is what I was going to suggest
[12:13:14 CDT(-0500)] <athena> and then had the PortletRenderingIncorporationComponent look for it
[12:13:18 CDT(-0500)] <athena> does that all sound right?
[12:13:20 CDT(-0500)] <EricDalquist> yeah
[12:13:33 CDT(-0500)] <athena> ok, great
[12:13:46 CDT(-0500)] <athena> thinking maybe naming the property "newItemCount"?
[12:13:50 CDT(-0500)] <EricDalquist> the only thing to remember with all of this is it all needs to be thread safe
[12:13:54 CDT(-0500)] <athena> so it's not specific to iPhone verbiage
[12:14:02 CDT(-0500)] <EricDalquist> sounds good
[12:14:11 CDT(-0500)] <EricDalquist> you're going to have N portlets all setting that response property
[12:14:31 CDT(-0500)] <EricDalquist> so you need to make sure your access to the portal's request attribute APIs is thread safe
[12:14:45 CDT(-0500)] <EricDalquist> and the updates to your data structure that tracks the newItemCount is thread safe as well
[12:15:58 CDT(-0500)] <athena> i'd kind of tried to follow what the portlet title logic seemed to be doing
[12:16:09 CDT(-0500)] <athena> added a new field to PortletRenderResult
[12:16:43 CDT(-0500)] <athena> then modified PortletRendererImpl to look for that property on the request
[12:17:19 CDT(-0500)] <EricDalquist> sounds great
[12:17:36 CDT(-0500)] <athena> which is set by a request properties manager that looks at the portlet response property
[12:17:41 CDT(-0500)] <EricDalquist> that should account for all the threading issues since those rendering results are coming out of the thread pool
[12:17:43 CDT(-0500)] <EricDalquist> yup
[12:17:45 CDT(-0500)] <athena> ok, great
[12:18:09 CDT(-0500)] <athena> i guess my one thought while doing it was wondering whether we wanted a more generic API for the PortletRenderResult and PortletRendererImpl
[12:18:17 CDT(-0500)] <athena> so that adding new properties doesn't require modifying that class
[12:18:27 CDT(-0500)] <athena> but it certainly wasn't a big deal to do, of course
[12:19:26 CDT(-0500)] <EricDalquist> yeah
[12:19:29 CDT(-0500)] <EricDalquist> that's probably a good idea
[12:20:09 CDT(-0500)] <athena> ok, maybe a thought to keep in mind for the future
[12:20:16 CDT(-0500)] <EricDalquist> yup
[12:20:31 CDT(-0500)] <EricDalquist> so do you have it working yet?
[12:20:34 CDT(-0500)] <athena> yeah!
[12:20:37 CDT(-0500)] <EricDalquist> great!
[12:20:38 CDT(-0500)] <athena> cleaning it up to commit
[12:20:50 CDT(-0500)] <EricDalquist> the placeholder stuff plays nice with the caching too
[12:20:51 CDT(-0500)] <athena> a couple blockers to really using it right now
[12:21:03 CDT(-0500)] <athena> 1. most of our portlets don't actually implement minimized mode correctly, which i'm quickly fixing
[12:21:04 CDT(-0500)] <EricDalquist> so it doesn't have to re-run the XSL to update those badge # values
[12:21:29 CDT(-0500)] <athena> 2. there's no way to return a portlet to minimized mode as part of the link to the main navigation, so after you focus one portlet it never returns to minimized mode
[12:21:38 CDT(-0500)] <EricDalquist> uhg ok
[12:21:45 CDT(-0500)] <EricDalquist> I'll see if I can take a look at 2 this weekend
[12:21:49 CDT(-0500)] <EricDalquist> well
[12:22:06 CDT(-0500)] <EricDalquist> try generating a portletUrl (instead of a portalUrl) that minimizes the current portlet
[12:22:09 CDT(-0500)] <EricDalquist> that might work{color}
[12:22:10 CDT(-0500)] <athena> and the other issues is that we're not getting the icon url param right now, but i think you're already fixing that
[12:22:14 CDT(-0500)] <athena> hm, ok
[12:22:18 CDT(-0500)] <EricDalquist> yeah
[12:22:26 CDT(-0500)] <athena> we'd have to unfocus the portlet to
[12:22:34 CDT(-0500)] <athena> so maybe a link to minimized mode, normal window state?
[12:23:32 CDT(-0500)] <EricDalquist> minimized is a window state
[12:23:39 CDT(-0500)] <EricDalquist> the portlet mode shouldn't need to change at all
[12:24:01 CDT(-0500)] <EricDalquist> hitting the back link would still target that portlet with the request but it would render minimized
[12:24:20 CDT(-0500)] <EricDalquist> along with everything else that the structure outputs for the non-focused view
[12:26:15 CDT(-0500)] <athena> but we don't want to have that portlet targeted anymore, right?
[12:26:20 CDT(-0500)] <athena> so we'd have to exit focus mode
[12:26:41 CDT(-0500)] <EricDalquist> the targeting only matters for the portlet's cache use
[12:26:48 CDT(-0500)] <EricDalquist> it shouldn't matter for the rendering of the UI
[12:27:16 CDT(-0500)] <athena> oh oh
[12:27:21 CDT(-0500)] <athena> i'm sorry, my brain is switched on now
[12:27:29 CDT(-0500)] <EricDalquist> no problem, it is all a little weird
[12:27:34 CDT(-0500)] <athena> yes, we want to change the window state, ie set it back to minimized
[12:27:37 CDT(-0500)] <EricDalquist> since you have a url that targets a specific portlet
[12:27:43 CDT(-0500)] <EricDalquist> but that portlet isn't nessesarily focused
[12:27:57 CDT(-0500)] <athena> yeah
[12:28:15 CDT(-0500)] <athena> do we really have a concept of focused anymore outside of just setting an individual portlet to maximized?
[12:28:59 CDT(-0500)] <EricDalquist> I don't think so
[12:29:15 CDT(-0500)] <athena> ok, cool
[13:01:40 CDT(-0500)] <athena> yay - that works!
[13:01:47 CDT(-0500)] <EricDalquist> yay
[13:01:53 CDT(-0500)] <athena> so i can check this stuff in
[13:02:13 CDT(-0500)] <athena> though maybe i should hold off on checking in the theme update until we make all the portlets support minimization
[13:02:28 CDT(-0500)] <EricDalquist> the only down-side I can see is that if the user refreshes the dashboard page after minimizing a portlet it will cause that portlet to re-render and skip any caching it had requested
[13:02:38 CDT(-0500)] <EricDalquist> but that isn't really a big deal
[13:02:51 CDT(-0500)] <athena> ah
[13:03:10 CDT(-0500)] <EricDalquist> you know in your mobile theme XSL you could just skip writing out the <channel> tag
[13:03:17 CDT(-0500)] <EricDalquist> and you won't get any content then
[13:03:50 CDT(-0500)] <athena> will it cause the portlet to get requested and set it's attributes then?
[13:04:28 CDT(-0500)] <EricDalquist> yeah
[13:04:35 CDT(-0500)] <EricDalquist> portlets start rendering after the structure transform
[13:05:03 CDT(-0500)] <EricDalquist> then placeholders in the output the theme cause the portal to wait for the portlet to complete execution and get the data needed for the placeholder
[13:05:04 CDT(-0500)] <athena> didn't we have a problem w/ that in 3.2 before?
[13:05:34 CDT(-0500)] <athena> wasn't there some issue where we had the <channel> element in the structure but not the theme, and the portlets crashed because of it sometimes?
[13:05:48 CDT(-0500)] <EricDalquist> so the problem is if the portlet starts rendering after the structure and there is no placholder of any kind for that portlet in the theme
[13:05:48 CDT(-0500)] <athena> or was that something else?
[13:05:58 CDT(-0500)] <EricDalquist> then you get this orphaned portlet rendering thread
[13:06:18 CDT(-0500)] <EricDalquist> and if it is still running after the portal completes handling the request you get ugly errors
[13:06:32 CDT(-0500)] <EricDalquist> I have some scratch code to do a orphaned portlet rendering check
[13:06:38 CDT(-0500)] <athena> ah ok
[13:06:51 CDT(-0500)] <EricDalquist> and warn in the logs if a portlet gets started by the structure and never joined on due to lack of a placeholder of any type
[13:06:53 CDT(-0500)] <athena> so the portlet title and badge number would count as enough of a placeholder?
[13:06:57 CDT(-0500)] <EricDalquist> yup
[13:07:03 CDT(-0500)] <athena> oh cool
[13:07:08 CDT(-0500)] <EricDalquist> they all wait for the portlet rendering result to complete I believe
[13:07:12 CDT(-0500)] <athena> so we don't actually have to worry about the minimized issue then
[13:07:12 CDT(-0500)] <EricDalquist> and if they don't that's a bug
[13:07:37 CDT(-0500)] <athena> awesome
[13:08:11 CDT(-0500)] <athena> getting closer and closer
[13:08:16 CDT(-0500)] <EricDalquist>
[13:29:18 CDT(-0500)] <EricDalquist> anyone here used any libraries to deal with csrf issues?
[13:47:16 CDT(-0500)] <athena> i have not
[13:48:21 CDT(-0500)] <athena> committed backend support for the new item count
[13:48:27 CDT(-0500)] <EricDalquist> yay
[13:48:30 CDT(-0500)] <athena> yeah (
[13:48:33 CDT(-0500)] <athena> going to clean up the theme stuff
[13:48:44 CDT(-0500)] <athena> i'm actually a lot happier with just not rendering channels
[13:48:48 CDT(-0500)] <athena> rather than including as minimized
[13:48:54 CDT(-0500)] <athena> should be a lot less fragile
[13:49:18 CDT(-0500)] <athena> was worried that if a portlet crashed and output the error channel it would break things
[13:49:26 CDT(-0500)] <athena> or if a portlet gets included that doesn't support minimization
[13:49:30 CDT(-0500)] <EricDalquist> well they will still be rendered
[13:49:36 CDT(-0500)] <EricDalquist> you'll just be ignoring the output
[13:49:44 CDT(-0500)] <athena> yeah - not included in the page, i guess
[13:49:46 CDT(-0500)] <athena> just seems like less to go wrong
[13:49:50 CDT(-0500)] <EricDalquist> yup
[13:50:11 CDT(-0500)] <athena> though still better performance-wise to support the proper minimization, i'd think
[13:50:28 CDT(-0500)] <athena> hm.
[13:50:30 CDT(-0500)] <athena> speaking of
[13:50:34 CDT(-0500)] <EricDalquist> right
[13:50:38 CDT(-0500)] <EricDalquist> since proper support just returns
[13:50:52 CDT(-0500)] <athena> so i guess we still want to render portlets minimized even though the result isn't being displayed
[13:51:02 CDT(-0500)] <athena> should improve performance
[13:51:55 CDT(-0500)] <EricDalquist> yeah
[13:52:06 CDT(-0500)] <EricDalquist> rendering them minimized is still important
[13:53:26 CDT(-0500)] <athena> ergh
[13:53:44 CDT(-0500)] <athena> which class was it again that initialized the portlet window? think i might have accidentally reverted that code
[13:54:18 CDT(-0500)] <EricDalquist> PortletWindowRegistryImpl
[13:55:38 CDT(-0500)] <athena> ah there we go, thanks
[13:55:54 CDT(-0500)] <athena> so eventually we'll need some way to configure in a list of profile names for which to initialize portlet windows as minimized
[13:56:11 CDT(-0500)] <EricDalquist> yup
[13:56:26 CDT(-0500)] <athena> but i can just hard-code it for now, i guess
[13:57:30 CDT(-0500)] <EricDalquist> oh so I decided to rename entity to "portal data"
[13:57:59 CDT(-0500)] <athena> sounds good to me
[13:58:25 CDT(-0500)] <athena> i know that's a nitpicky detail, but no need to make the portal naming conventions confusing
[13:58:44 CDT(-0500)] <EricDalquist> no its good
[13:58:47 CDT(-0500)] <EricDalquist> naming is important
[14:02:29 CDT(-0500)] <athena> yeah
[14:02:37 CDT(-0500)] <athena> hate to accidentally introduce conflicting names
[14:02:46 CDT(-0500)] <athena> will probably matter in the long run
[17:11:51 CDT(-0500)] <Bananobot> Where does uPortal store the user session information that links the session IDs to accounts?
[17:12:48 CDT(-0500)] <Bananobot> Basically, I have uPortal installed on the same domain as a PHP app, and I'm trying to find out if there's any way to look at the session cookies from uPortal and link that to a username. Assume the PHP app has access to uPortal's database.
[17:13:25 CDT(-0500)] <Bananobot> (and that it can see the session cookies)
[17:41:05 CDT(-0500)] <athena> i'd imagine that should be in-memory only?
[17:41:23 CDT(-0500)] <athena> i don't think session cookies should appear in the up database