uPortal IRC Logs-2011-01-12

Owned by Apereo Infrastructure
Last updated: Jan 12, 2011Version comment
7 min read

[11:31:51 CST(-0600)] <EricDalquist> GreaseMonkey script for uPortal that uses the portal's jQuery library: http://uportal.pastebin.com/K7NzCkaz
[11:37:56 CST(-0600)] <athena> what's it do?
[11:38:06 CST(-0600)] <athena> change a title?
[11:38:13 CST(-0600)] <athena> neat that that works (smile)
[11:38:34 CST(-0600)] <EricDalquist> yeah
[11:38:36 CST(-0600)] <EricDalquist> doing help videos
[11:38:38 CST(-0600)] <EricDalquist> in prod
[11:38:40 CST(-0600)] <athena> oh!!
[11:38:42 CST(-0600)] <EricDalquist> but we have some pending changes
[11:38:43 CST(-0600)] <athena> that makes a lot of sense
[11:38:47 CST(-0600)] <athena> so you can just change stuff (smile)
[11:38:53 CST(-0600)] <EricDalquist> and I want the videos to reflect what will be there
[11:38:56 CST(-0600)] <athena> any of those help videos officially live yet?
[11:38:58 CST(-0600)] <EricDalquist> yeah
[11:38:59 CST(-0600)] <EricDalquist> not yet
[11:39:01 CST(-0600)] <EricDalquist> should be tomorrow
[11:39:08 CST(-0600)] <athena> so cool (smile)
[11:39:13 CST(-0600)] <athena> you'll have to show them to fluid as well
[12:26:12 CST(-0600)] <athena> EricDalquist: with fluid's help just got the uploader working with a JSP/ajax-based import portlet
[12:26:19 CST(-0600)] <EricDalquist> neat
[12:27:09 CST(-0600)] <athena> yeah, i think it has promise
[12:27:17 CST(-0600)] <athena> upgrading us to fluid 1.3 while i'm at it
[13:03:58 CST(-0600)] <athena> so the import/export portlet right now relies on portlet preferences for configuration
[13:04:17 CST(-0600)] <athena> that determines which entities can be import/exported/deleted
[13:04:27 CST(-0600)] <athena> i'm wondering if this would better be represented as permissions?
[13:04:32 CST(-0600)] <EricDalquist> probably
[13:04:42 CST(-0600)] <EricDalquist> especially if we move it out to a REST service eventually
[13:04:44 CST(-0600)] <athena> that way we could have separate permissions for different groups without having to publish the portlet multiple times
[13:04:47 CST(-0600)] <athena> right
[13:04:57 CST(-0600)] <athena> so that's the other thing - this ajax implementation of course uses a servlet
[13:05:01 CST(-0600)] <athena> it's not actually exactly REST yet
[13:05:07 CST(-0600)] <athena> but it's awfully close to being there
[13:05:09 CST(-0600)] <EricDalquist> right
[13:05:46 CST(-0600)] <athena> so then we'd solve the issue of how to handle the permissions for those import/export servlets, which is currently an open issue
[13:06:12 CST(-0600)] <athena> if that seems reasonable i can likely get that implemented while i update the portlet to use JSPs
[13:07:56 CST(-0600)] <athena> ack.
[13:08:12 CST(-0600)] <athena> the portlet preferences are saved as a comma-delimited string instead of multiple values?
[13:08:35 CST(-0600)] <EricDalquist> lol
[13:08:48 CST(-0600)] <athena> that doesn't seem ideal either (smile)
[13:09:04 CST(-0600)] <EricDalquist> nope
[13:09:18 CST(-0600)] <athena> though guess i can ignore that if we're just goign to replace it w/ permissions anyway
[13:09:34 CST(-0600)] <athena> though . . . we probably don't actually have a way to list the available import/export types
[13:10:22 CST(-0600)] <athena> so might need some sort of pref/property for that
[13:13:28 CST(-0600)] <EricDalquist> Hrm ... with the tab inline edit I just realized I can't click a 2nd time to select the text
[13:13:31 CST(-0600)] <EricDalquist> that causes the edit to go way
[13:13:34 CST(-0600)] <EricDalquist> away*
[13:15:42 CST(-0600)] <athena> hm
[13:16:16 CST(-0600)] <athena> yeah, you're right
[13:16:21 CST(-0600)] <athena> maybe something to bring up w/ fluid?
[13:16:30 CST(-0600)] <athena> guess you can use the cursor
[13:55:24 CST(-0600)] <b-rock> Greetings uPortal devs: I needed to change the method signature int eh WebProxyPortelt from doDispatch to doView because I noticed that the doDispatch method was not being ran everytime I refreshed the proxy portlet page.
[13:55:51 CST(-0600)] <b-rock> Is that by design or maybe it should be named doView?
[14:14:03 CST(-0600)] <athena> EricDalquist: do you think it's possible to call a resource URL from one portlet from another?
[14:14:13 CST(-0600)] <athena> like say call a resource URL in the calendar portlet from the email portlet?
[14:15:07 CST(-0600)] <EricDalquist> I don't think that is possible through pure JSR-286
[14:15:27 CST(-0600)] <EricDalquist> what is your use case?
[14:15:38 CST(-0600)] <EricDalquist> dodispatch simply delegates to doview
[14:15:54 CST(-0600)] <athena> potentially displaying a list of upcoming calendar events in the email portlet
[14:16:16 CST(-0600)] <athena> like say you have an exchange or gmail account that supports both email and calendaring and you have that account in both portlets in uportal
[14:16:27 CST(-0600)] <athena> maybe you get a calendar preview in the email portlet, or something like that
[14:16:32 CST(-0600)] <EricDalquist> hrm
[14:16:51 CST(-0600)] <athena> the calendar portlet already outputs JSON of the events that could be reusable
[14:16:58 CST(-0600)] <athena> but not sure we can actually access it
[14:17:15 CST(-0600)] <EricDalquist> you might be able to kind of hack it with events ... but that would require an action initialy
[14:17:21 CST(-0600)] <athena> gotcha
[14:17:32 CST(-0600)] <athena> ok - definitely appreciate the initial answer at least
[14:18:15 CST(-0600)] <EricDalquist> brb
[14:22:04 CST(-0600)] <EricDalquist> so I really do wonder if there is a way we could do that in 286
[14:22:21 CST(-0600)] <EricDalquist> I'm not really thinking of any way we could get it working with the basic spec APIs though
[14:22:29 CST(-0600)] <athena> gotcha
[14:22:34 CST(-0600)] <athena> it'd definitely be interesting if we could
[14:23:14 CST(-0600)] <athena> this isn't something we could re-use that config mode embedding for i assume?
[14:23:26 CST(-0600)] <EricDalquist> it could be
[14:23:39 CST(-0600)] <EricDalquist> and I did put that together in a way that in theory it could be broken out of the portal
[14:23:52 CST(-0600)] <EricDalquist> essentially you'd need an API to get a request dispatcher to another portlet context
[14:24:04 CST(-0600)] <EricDalquist> and then generate a PortletUrl object from that dispatcher
[14:24:23 CST(-0600)] <EricDalquist> the hardest part of this is the initial view
[14:24:40 CST(-0600)] <EricDalquist> if you can make the user take an action then you can hack all sorts if IPC together via events
[14:25:03 CST(-0600)] <EricDalquist> but initial page view just results in parallel render requests
[14:25:08 CST(-0600)] <athena> gotcha
[14:25:13 CST(-0600)] <athena> that makes sense
[14:25:13 CST(-0600)] <EricDalquist> with no real ability to do any IPC work
[14:25:24 CST(-0600)] <athena> but ajax might still be a problem with that i imagine?
[14:25:31 CST(-0600)] <athena> i know in the past we haven't been able to use ajax in config mode
[14:25:33 CST(-0600)] <EricDalquist> even setting public render parameters isn't useful because they won't be seen until the next request
[14:25:36 CST(-0600)] <EricDalquist> well you could now
[14:25:41 CST(-0600)] <athena> oh cool - that's good to know
[14:25:42 CST(-0600)] <EricDalquist> if the ajax uses resource urls
[14:26:00 CST(-0600)] <EricDalquist> the problem wasn't the support logic for config mode it was webflow
[14:26:28 CST(-0600)] <EricDalquist> since the action request in webflow couldn't result in a redirect to a servlet without ending the flow
[14:58:37 CST(-0600)] <b-rock> EricDalquist: hello Eric. did you happen to see my question about the WebProxyPortlet above?
[14:58:53 CST(-0600)] <EricDalquist> yeah, so I don't see what renaming it will do
[14:59:06 CST(-0600)] <EricDalquist> in generic portlet1 doDispatch simply delegates to doView
[15:00:01 CST(-0600)] <b-rock> When I renamed it I saw the logs fire for each page load but with just doDispatch, a refresh of the page didn't cause the logs to output which made me think the method wasn't executing for a page reload.
[15:01:37 CST(-0600)] <b-rock> I know doView seems to be fired for every refresh of the page. I haven't figured out why doDispatch doesn't trigger on a page refresh which is what I think we want to happen for the contents of that method.
[15:03:33 CST(-0600)] <EricDalquist> right but I have no idea why that change would matter
[15:03:34 CST(-0600)] <EricDalquist> http://svn.apache.org/viewvc/portals/pluto/tags/import/src/api/javax/portlet/GenericPortlet.java?revision=35768&amp;view=markup
[15:03:48 CST(-0600)] <EricDalquist> you can take a look at the doDispatch method in GenericPortlet there to see what it does
[15:04:07 CST(-0600)] <EricDalquist> essentially for your doView method to be called doDispatch must be called
[15:04:29 CST(-0600)] <EricDalquist> the call chain is Portlet.render -> GenericPortlet.doDispatch -> GenericPortlet.doView
[15:04:33 CST(-0600)] <b-rock> I was just looking there. I'm thinking maybe something else is getting called affecting that.
[15:06:17 CST(-0600)] <b-rock> I see the doDispatch determines that doView is called, but doDispatch is not being called for each page load. do you see that in your logs as well or maybe something else here in my setup is to blame.
[15:06:35 CST(-0600)] <EricDalquist> we don't have that level of logging enabled
[15:06:46 CST(-0600)] <EricDalquist> but all our proxy portlets are working as expected
[15:06:53 CST(-0600)] <EricDalquist> do you have caching enabled in the portlet.xml?
[15:07:40 CST(-0600)] <b-rock> oh ok. I see this <expiration-cache>-1</expiration-cache> does that make caching happen? Its the default
[15:08:12 CST(-0600)] <EricDalquist> -1 never expire, 0 never cache, N>0 cache for N seconds
[15:08:26 CST(-0600)] <EricDalquist> so in this case the portlet will not re-render unless directly interacted with
[15:09:13 CST(-0600)] <b-rock> sweet. I'm testing that now. I did not see this flag before I have just been looking in the portlet preferences
[15:09:24 CST(-0600)] <EricDalquist> and that flag is handled at the portal level
[15:10:01 CST(-0600)] <EricDalquist> so once a portlet renders, if the expiration cache is set to -1, the portal will not call render on that portlet again until a user explicitly interacts with it
[15:10:14 CST(-0600)] <b-rock> gotcha
[15:15:43 CST(-0600)] <b-rock> yeah, changing the <expiration-cache>-1</expiration-cache> to <expiration-cache>0</expiration-cache> turned off the caching with evidence in the logs now. Thanks EricDalquist.
[15:25:35 CST(-0600)] <holdorph> you have to wonder about someone coming up with a spec, using XML and yet relying on '-1' and '0' to mean something so specific and yet opposite of each other
[15:26:28 CST(-0600)] <holdorph> would it have really been that hard to have a <expiration-cache always-cache="false" never-cache="true"/> or something along those lines
[15:26:35 CST(-0600)] <holdorph> shrug
[15:31:34 CST(-0600)] * EricDalquist agrees with holdorph
[15:43:53 CST(-0600)] <athena> ok, so we have entity files with both dashes and underscores in the extension name
[15:44:20 CST(-0600)] <athena> seems like it'll be easier to do this all programmatically if we can have a consistent rule
[15:44:30 CST(-0600)] <athena> so we don't have to have another map just to track what file names we're using
[15:58:56 CST(-0600)] <athena> hm.
[15:59:09 CST(-0600)] <EricDalquist> yeah
[15:59:14 CST(-0600)] <EricDalquist> +1 for a consistent rule
[15:59:20 CST(-0600)] <EricDalquist> and right now the file extensions don't matter
[15:59:20 CST(-0600)] <athena> we really need to come up with a way to inject a user into these crn import/export/delete tasks
[15:59:28 CST(-0600)] <EricDalquist> the crn code looks at the first element in the DOM I believe
[15:59:28 CST(-0600)] <athena> ok, i'll set them to all dashes then?
[15:59:40 CST(-0600)] <athena> yeah that's probably true
[15:59:42 CST(-0600)] <EricDalquist> yup
[15:59:52 CST(-0600)] <athena> awesome
[16:00:05 CST(-0600)] <athena> really wish we could rely on the actual permissions for these entities
[16:00:18 CST(-0600)] <athena> like, i'd prefer to just delegate to the permission for deleting a portlet
[16:00:22 CST(-0600)] <athena> rather than duplicating that permission
[16:00:36 CST(-0600)] <EricDalquist> that would be nice
[16:01:21 CST(-0600)] <athena> yeah
[16:01:30 CST(-0600)] <athena> we'd need to update all the CRN tasks to take a user though
[16:01:55 CST(-0600)] <athena> i did actually include a user in the new API for portlet publishing
[16:02:06 CST(-0600)] <athena> but the crn script can only actually use the system user