...
[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 <drewwills> so... any fancy Spring class to turn "/some/url/{p1}?foo={p2}" into "/some/url/with?foo={bar}" 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