uPortal IRC Logs-2013-08-28

[13:02:36 CDT(-0500)] <drewwills> tlev, jwennmacher, et al – I'm updating the background switcher... have a situation where an ajax request is using an action url (because it needs to adjust portlet prefs)... i don't need the whole portal page to be regenerated, so I'd like to end the action request handler method w/ sendRedirect(), but I'm not entirely sure what to redirect to

[13:03:18 CDT(-0500)]

[13:03:24 CDT(-0500)] <drewwills> that would be plenty

[13:03:54 CDT(-0500)] <drewwills> can anyone think of an elegant, existing way to do that?

[13:04:20 CDT(-0500)] <jwennmacher> I assume resource requests can't update portlet preferences?

[13:04:41 CDT(-0500)] <drewwills> they cannont, nor can you generate a resourceURL within an action request

[13:04:51 CDT(-0500)] <drewwills> (which completely blows)

[13:05:33 CDT(-0500)] <drewwills> changing prefs requires an action request, which triggers a full page render unless you redirect (afaik)

[13:05:34 CDT(-0500)] <tlev> couldn't you just redirect to a render request method that returned json?

[13:06:15 CDT(-0500)] <drewwills> I can if I hard-code the renderURL... rely on the fact that I know what that URL would look like

[13:07:03 CDT(-0500)] <tlev> is this in the portlet scope or uportal webapp?

[13:07:24 CDT(-0500)] <drewwills> it's within the up webapp, since it's a framework portlet

[13:13:36 CDT(-0500)] <drewwills> Here's an idea... I could add a very simple (12ish lines) AjaxSuccessController (Spring MVC, not Portlet MVC) to org.jasig.portal.rest, which would respond with that JSON snippet and be generally available for the next time we need it

[13:14:13 CDT(-0500)] <tlev> that would be good. maybe have a fail as well?

[13:14:32 CDT(-0500)] <drewwills> @RequestMapping(value="/ajax-success")

[13:14:38 CDT(-0500)] <drewwills> yes, sounds good

[13:15:01 CDT(-0500)] <drewwills> well... with a fail you might want to add value (describe the failure)

[13:15:14 CDT(-0500)] <tlev> true

[13:15:36 CDT(-0500)] <jwennmacher> how does sendRedirect avoid the whole page from rendering? Is that something in the spec?

[13:16:56 CDT(-0500)] <drewwills> don't know if the spec is specific on that or not, but i believe uP does not enter into event/resource/render phases – nor the whole page rendering pipeline – on a redirect

[13:18:29 CDT(-0500)] <jwennmacher> That's interesting. That doesn't match how I interpret the api docs http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/ActionResponse.html

[13:19:12 CDT(-0500)] <jwennmacher> That indicates a browser redirect

[13:25:06 CDT(-0500)] <drewwills> i believe it's implemented as an HTTP 302 FOUND (redirect location in the response headers)

[13:25:58 CDT(-0500)] <jwennmacher> That doesn't cause the browser to redirect to that URL?

[13:30:16 CDT(-0500)] <drewwills> it does... perhaps i'm not following

[13:52:28 CDT(-0500)] <jwennmacher> Drew filled me in on the obvious (which I didn't get) that its an Ajax request making the ActionRequest, hence the need for pass/fail ajax response

[15:01:50 CDT(-0500)] <tlev> hi all. did anyone else get an email from world weather online (one of the 2 weather providers we use for uPortal weather portlet) stating there old keys will stop working on August 31st?

[15:13:14 CDT(-0500)] <jwennmacher> No but I did see that Mark M at Ohio did have an email in his inbox from world weather online, probably the same thing you are talking about

[15:13:22 CDT(-0500)] <jwennmacher> Do we need to make changes to the portlet?

[15:28:57 CDT(-0500)] <tlev> its looking that way

[15:29:53 CDT(-0500)] <tlev> yes, the end points are different for the new api

[15:31:06 CDT(-0500)] <jwennmacher> I assume all users who registered (and are using that API) got notified. I assume you are? Will you have a chance to make the changes in time (seems like an awfully short notice).

[15:34:45 CDT(-0500)] <tlev> well, they sent the initial notice of the new api in March.

[15:35:48 CDT(-0500)] <jwennmacher> Ahhh. This is the first I heard of it since we don't use it.

[15:36:54 CDT(-0500)] <tlev> I think the notice of them ending the old api just went out yesterday. it is a little short notice

[15:37:00 CDT(-0500)] <tlev> of the end of service

[15:37:35 CDT(-0500)] <tlev> We (UW) are going to look at what it will take to migrate to the new API. At first glance it seems like it will be some work, but there is an example java code project

[15:38:02 CDT(-0500)] <tlev> https://github.com/WorldWeatherOnline/JavaWWO/

[15:39:21 CDT(-0500)] <tlev> the jaxb classes don't seem much different

[15:39:28 CDT(-0500)] <tlev> but i'll send out an update tomorrow