[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
[15:00:53 CST(-0600)] <athena> though this seems like more of an installation-wide setting
[15:00:54 CST(-0600)] <athena> yeah
[15:00:54 CST(-0600)] <EricDalquist> prefs would be better
[15:01:05 CST(-0600)] <EricDalquist> then they could be set without modifying portlet.xml
[15:01:09 CST(-0600)] <athena> yeah
[15:01:16 CST(-0600)] <athena> if you have multiple installations have to set it each time
[15:01:18 CST(-0600)] <athena> but that's fine
[15:01:23 CST(-0600)] <athena> ok, i'll just switch to that instead
[15:01:53 CST(-0600)] <athena> since this is mostly true/false i guess it'll be fine to just use the JSP
[16:22:21 CST(-0600)] <athena> argh
[16:22:33 CST(-0600)] <athena> i have no idea what's going on, but the login portlet isn't showing up for the guest user
[16:22:35 CST(-0600)] <athena> but only in mobile
[16:22:52 CST(-0600)] <athena> looks like the pre-structure document is missing that channel from the header
[16:23:02 CST(-0600)] <athena> do you have any idea what could possibly account for that EricDalquist?
[16:23:29 CST(-0600)] <EricDalquist> but it shows up for the desktop view?
[16:24:19 CST(-0600)] <athena> yeah
[16:24:43 CST(-0600)] <athena> looking at the logs, and the layout doc has it when i hit the desktop view, but the header folder is empty in mobile
[16:24:51 CST(-0600)] <athena> should be a channel element in the header folder, normally
[16:25:02 CST(-0600)] <EricDalquist> same user
[16:25:05 CST(-0600)] <EricDalquist> and same dlm fragments?
[16:25:22 CST(-0600)] <EricDalquist> what does the post-layoutManager XML logger show?
[16:25:42 CST(-0600)] <athena> hmm.
[16:25:49 CST(-0600)] <athena> same user, though there is that extra DLM fragment for mobile
[16:25:55 CST(-0600)] <athena> could disable that and see if it makes a difference
[16:25:58 CST(-0600)] <athena> though that wouldn't make a lot of sense
[16:27:17 CST(-0600)] <EricDalquist> yeah, though drew did work around dlm and header/footer merging
[16:27:23 CST(-0600)] <EricDalquist> so maybe it is something to do with that?
[16:31:12 CST(-0600)] <athena> maybe, though the way it's set up is that the the user has the channel in its header, and none of the fragments do
[16:31:23 CST(-0600)] <athena> so would be kind of weird if that one fragment made a difference
[16:31:44 CST(-0600)] <EricDalquist> is the portlet setup to not show for mobile by chance?
[16:31:56 CST(-0600)] <athena> nope
[16:32:03 CST(-0600)] <athena> works ok when logged in
[16:32:27 CST(-0600)] <athena> even if it weren't set to show for mobile it would show up in the logged layout doc
[16:32:39 CST(-0600)] <EricDalquist> yeah ...
[16:32:41 CST(-0600)] <EricDalquist> :/
[16:58:14 CST(-0600)] <athena> ok, yeah, removing that fragment didn't change anything
[16:58:16 CST(-0600)] <athena> gahhhhh
[16:58:32 CST(-0600)] <athena> i'm not sure i even know where to start with this
[17:09:19 CST(-0600)] <athena> could it be related to any of the recent work that supports the mobile theme?
[17:13:36 CST(-0600)] <athena> OH.
[17:13:47 CST(-0600)] <athena> heh.
[17:14:12 CST(-0600)] <athena> bet the desktop profile is linked to the guest layout and the mobile is using the default . . .