Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

[15:26:09 CDT(-0500)] <EricDalquist> T callPortalRestApi(PortletRequest, PortletResponse, String uri, Map<String, String[]> params, HttpMessageConverter<T>)

[15:29:00 CDT(-0500)] <athena> and we could improve it from there

[15:29:05 CDT(-0500)] <drewwills> i would probably leave moving the search api as a roadmap item, for the same of triage

[15:29:15 CDT(-0500)] <athena> i can help with some of this, but certainly not anytime in the next week

[15:29:17 CDT(-0500)] <EricDalquist> we don't

[15:29:24 CDT(-0500)] <EricDalquist> I had this working a while back locally

[15:29:27 CDT(-0500)] <athena> i don't think there's any direct relationship between this and the search module

[15:29:28 CDT(-0500)] <EricDalquist> but it never went anywhere

[15:33:39 CDT(-0500)] <drewwills> if I had this I could hit ANY rest api... not just ones I had made interfaces for

[15:33:40 CDT(-0500)] <EricDalquist> so designing a whole new API, implementation and way to provide it as a portal context attribute?

[15:33:42 CDT(-0500)] <athena> it sort of seems like most of the planning is already there? you'd just need to implement the steps eric already laid out

[15:33:46 CDT(-0500)] <EricDalquist> right

[15:34:00 CDT(-0500)] <athena> yes, you could hit any of the existing rest services

[15:34:08 CDT(-0500)] <athena> plus quickly attach to new ones you created

[15:34:14 CDT(-0500)] <drewwills> yeah I was picturing a "whole new API" of 1 interface, maybe 2 methods (wink)

[15:34:14 CDT(-0500)] <EricDalquist> this already exists: https://github.com/Jasig/portlet-utils

[15:34:15 CDT(-0500)] <athena> so if you needed a new service you could jsut add it to uportal and go

[15:34:33 CDT(-0500)] <EricDalquist> yes but it needs to be a well thought out API

[15:34:36 CDT(-0500)] <athena> so we just need a small library that's a submodule of portlet-utils

[15:34:38 CDT(-0500)] <athena> yes, it does

[15:38:06 CDT(-0500)] <drewwills> this is about getting all oars in the same boat, rowing the same way

[15:38:47 CDT(-0500)] <EricDalquist> right

[15:39:00 CDT(-0500)] <EricDalquist> so I thinkt he least effort is the rest api proxy code

[15:44:33 CDT(-0500)] <athena> also i think there's a really interesting use case for leveraging the uportal permissions framework for portlet use

[15:44:46 CDT(-0500)] <drewwills> yes, totally

[15:44:59 CDT(-0500)] <drewwills> need discoverable groups & so forth

[15:45:12 CDT(-0500)] <athena> could even create custom permissions

[15:45:12 CDT(-0500)] <drewwills> isUserInRole only goes so far (tongue)

[15:45:14 CDT(-0500)] <athena> yes.

[15:45:25 CDT(-0500)] <athena> things like the announcement portlet feed permissions could really use uportal permissions

[15:45:30 CDT(-0500)] <EricDalquist> so one thing we'll have to look into is overhead

[15:45:33 CDT(-0500)] <athena> would take some dev to get to that point, but i's possible

[16:16:53 CDT(-0500)] <drewwills> one more question EricDalquist – calling the rest api from a servlet (not portlet) not a problem, correct?

[16:17:28 CDT(-0500)] <EricDalquist> using the request dispatcher approach?

[16:19:00 CDT(-0500)] <drewwills> yeah

[16:19:13 CDT(-0500)] <EricDalquist> right

[16:19:18 CDT(-0500)] <drewwills> fewer steps even

[16:19:18 CDT(-0500)] <EricDalquist> that isn't a problem

[16:19:21 CDT(-0500)] <EricDalquist> right

[16:19:26 CDT(-0500)] <EricDalquist> it is the same as the portlet

[16:19:29 CDT(-0500)] <EricDalquist> just one less step

[16:19:50 CDT(-0500)] <drewwills> whereas the java api/portal context approach could require extra finessing

[16:21:38 CDT(-0500)] <EricDalquist> right

[16:21:44 CDT(-0500)] <EricDalquist> since the servlet has no context from the portal]

[16:47:09 CDT(-0500)] <drewwills> can you stuff GET/POST/PUT/DELETE into a requestDispatcher?

[16:47:38 CDT(-0500)] <EricDalquist> if you fake ity

[16:47:48 CDT(-0500)] <EricDalquist> with a custom HttpServletRequestWrapper

[16:49:57 CDT(-0500)] <EricDalquist> but doable

[16:55:15 CDT(-0500)]

Wiki Markup
 &lt;drewwills&gt; so... any fancy Spring class to turn &#034;/some/url/{p1}?foo={p2}&#034; into &#034;/some/url/with?foo={bar}&#034; given \[ p1:with, p2:bar \]?

[16:55:41 CDT(-0500)] <athena> could take a look at the rest template source code

[16:55:47 CDT(-0500)] <athena> see if that's actually using another library

[16:58:48 CDT(-0500)] <athena> yeah

[16:58:54 CDT(-0500)] <athena> using an internal spring lib - UriTemplate

[17:10:40 CDT(-0500)] <athena> yes, i think we should use normal URL parameter behavior

[17:17:30 CDT(-0500)] <drewwills> sounds lovely... I thought I had seen that the getPeople() method expected differently, but I mis-remembered

[18:36:54 CDT(-0500)] <peterjhart> Here is a mockup of what a Fragment Manager UI could look like: https://wiki.jasig.org/display/UPC/uPortal+4+DLM+Fragment+Manager+Interface