uPortal IRC Logs-2012-02-20

[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)]

[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)]

[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 . . .