[09:33:36 CST(-0600)] <ernst_> hi there
[09:33:43 CST(-0600)] <EricDalquist> hello
[09:35:04 CST(-0600)] <ernst_> I noticed there are several artifacts built by the uPortal4 package that are not published. E.g. WebProxyPortlet and uportal-maven-tasks. Is this correct or are they in a different repository perhaps?
[09:36:10 CST(-0600)] <EricDalquist> those portlets are published as stand-alone projects
[09:36:22 CST(-0600)] <EricDalquist> the uPortal 4 versions are overlays customized for the specific deployment
[09:36:28 CST(-0600)] <EricDalquist> and have no real value beyond the local build
[09:38:09 CST(-0600)] <ernst_> ah, I see
[09:39:23 CST(-0600)] <ernst_> we sort of created our own EAR from the published artifacts for uportal3 (doing a war-overlay and adding our own portlets/channels in the EAR).
[09:39:41 CST(-0600)] <EricDalquist> ok
[09:39:56 CST(-0600)] <EricDalquist> so I'd recommend just copying the overlay configurations for the few portlets that are included with uPortal out of the box
[09:40:13 CST(-0600)] <ernst_> (Ernst from University of Amsterdam. Sorry for not introducing myself)
[09:40:19 CST(-0600)] <EricDalquist> 
[09:40:31 CST(-0600)] <EricDalquist> we do something similar, we have a maven project that is essentially an ear module and then an overlays module with one sub-module per webapp
[09:40:47 CST(-0600)] <EricDalquist> we just clone the overlay configuration for those few portlets into our big ear/overlay project
[09:42:04 CST(-0600)] <ernst_> that's probably the way to go yeah
[09:43:11 CST(-0600)] <ernst_> thanks! I'll have another look at the feasibility of that strategy in our current setup
[09:43:27 CST(-0600)] <ernst_> bye
[13:25:32 CST(-0600)] <rlewis> Hi, In the Map portlet I need to replace google.maps with an ArcGis API, which I am told is built on google maps. I think I see in mapView.jsp where to do the substitution. However, I do not understand what mapView_jsp.java does,and there are at least two places in that file where google.maps is used. Please someone tell me what is relationship btw mapView_jsp.java and mapView.jsp? Thanks.
[13:25:59 CST(-0600)] <EricDalquist> where are you seeing mapView_jsp.java?
[13:26:16 CST(-0600)] <athena> that's autogenerated by tomcat from mapView.jsp
[13:26:17 CST(-0600)] <EricDalquist> that sounds like it is the java code that is generated by the JSP compiler at build time
[13:26:21 CST(-0600)] <athena> that's just kind of how JSPs work, yeah
[13:26:30 CST(-0600)] <athena> so if you make changes to the base JSP file that should udpate
[13:26:46 CST(-0600)] <athena> there are a lot of calls that use the map API within the imported javascript file though
[13:27:08 CST(-0600)] <athena> i'd recommend building a new portlet from scratch, rather than replacing the existing maps portlet
[13:27:29 CST(-0600)] <rlewis> Okay, Thanks!
[13:27:33 CST(-0600)] <athena> if it's easier, you might even start w/ just a bare-bones HTML/JS page to work through the javascript
[13:27:48 CST(-0600)] <rlewis> Ok
[14:26:42 CST(-0600)] <athena> EricDalquist: what's your thought on the best way to get a portlet init param into a JSP page?
[14:27:04 CST(-0600)] <athena> wasn't sure if there's a good way to do it from the JSP or if it would be best to write a RenderFilter to add it to the request or something
[14:27:06 CST(-0600)] <EricDalquist> hrm
[14:27:57 CST(-0600)] <EricDalquist> http://docs.oracle.com/javaee/1.4/tutorial/doc/JSPIntro7.html
[14:28:15 CST(-0600)] <EricDalquist> $
[14:28:20 CST(-0600)] <EricDalquist> that looks like it should work
[14:28:27 CST(-0600)] <EricDalquist> scroll down on that page to "Implicit Objects"
[14:28:38 CST(-0600)] <athena> ah! terrific
[14:28:42 CST(-0600)] <athena> better than i was hoping for even
[14:28:43 CST(-0600)] <athena> thanks
[14:29:22 CST(-0600)] <EricDalquist> yup
[14:29:26 CST(-0600)] <EricDalquist> I do something similar for portlet preferences
[14:29:30 CST(-0600)] <EricDalquist> since you get get them as a map
[14:29:44 CST(-0600)] <athena> awesome
[14:30:13 CST(-0600)] <EricDalquist> $
[14:31:17 CST(-0600)] <athena> excellent
[14:31:20 CST(-0600)] <athena> not pretty, but works
[14:31:25 CST(-0600)] <EricDalquist> yup
[14:31:42 CST(-0600)] <EricDalquist> if I need them a lot I usually assign renderRequest.preferences.map to a page variable named "prefs"
[14:38:49 CST(-0600)] <athena> makes sense
[14:56:16 CST(-0600)] <athena> hmm.
[14:56:24 CST(-0600)] <athena> not having much luck w/ the initParam
[14:56:27 CST(-0600)] <athena> does that generalize to portlets?
[14:56:52 CST(-0600)] <athena> looks like actually it applies to the application
[14:57:01 CST(-0600)] <EricDalquist> is this a init param in web.xml?
[14:57:05 CST(-0600)] <athena> no, in portlet.xml
[14:57:11 CST(-0600)] <EricDalquist> ah
[14:57:31 CST(-0600)] <athena> though it could be one of a number of config type thigns
[14:57:48 CST(-0600)] <athena> basically the use case is setting a flag to determine whether the portal's js libraries should be used
[14:57:50 CST(-0600)] <athena> the default is no
[14:57:58 CST(-0600)] <EricDalquist> then you need to look at "PLT.26.1 defineObjects Tag" of the portlet spec
[14:58:06 CST(-0600)] <EricDalquist> that page is just for servlets
[14:58:07 CST(-0600)] <athena> but if you know you're running w/ a compatible library in the base portal js it speeds up the mobile side a lot to share
[14:58:08 CST(-0600)] <EricDalquist> so web.xml only
[14:58:35 CST(-0600)] <athena> so it seems like maybe portlet.xml is a reasonable option
[14:59:05 CST(-0600)] <EricDalquist> and it looks like there is no equiv for portlet init params 
[14:59:17 CST(-0600)] <EricDalquist> portletConfig is an implicit var
[14:59:20 CST(-0600)] <athena> yes
[14:59:27 CST(-0600)] <athena> and might be hard to get params out of that, given the API
[14:59:29 CST(-0600)] <EricDalquist> and you can do portletConfig.portletcontext
[14:59:48 CST(-0600)] <EricDalquist> but portletContext doesn't expose portlet.xml init params in a way that is easy to access from a JSP
[14:59:53 CST(-0600)] <athena> right
[14:59:57 CST(-0600)] <EricDalquist> without resorting to a scriptlet
[15:00:00 CST(-0600)] <athena> yes.
[15:00:10 CST(-0600)] <athena> ok, so back to square one
[15:00:21 CST(-0600)] <EricDalquist> yup
[15:00:22 CST(-0600)] <athena> so my original thought, because was worried this was going to be hard given the API
[15:00:31 CST(-0600)] <athena> possibly a filter?
[15:00:40 CST(-0600)] <athena> could make them be portlet prefs too, i guess
[15:00:40 CST(-0600)] <EricDalquist> sad that the portlet spec didn't better define their API