[10:42:09 CST(-0600)] <Bananobot> I'm trying to get a portlet to read the client's GET request parameters to select the output. But it seems as though the output is being cached too heavily, so when I feed it a different value in the URL, the output isn't updated. Is there a way for the portlet to work around this without forcing all navigation to use POST?
[11:10:36 CST(-0600)] <holdorph> Bananobot, there are two things you need to look at. One, make sure the portlet.xml doesn't have caching turn on.
[11:11:16 CST(-0600)] <holdorph> Two, you must use the portlet container to create any URLs that the user can click on. Hand crafting URLs is not supported by the portlet spec
[11:11:46 CST(-0600)] <holdorph> that means, for example if you are using a .jsp file, using the portlet tag library and creating renderUrls
[11:11:49 CST(-0600)] <Bananobot> Caching is turned on in portlet.xml, but I would think that if a GET parameter is specified, targeting that specified portlet, the portal should know that it can't use the same cache as a request with a different GET parameter..
[11:12:30 CST(-0600)] <holdorph> you're right, assuming your following the second consideration i mention
[11:12:39 CST(-0600)] <Bananobot> Okay, I'll look into that
[11:13:45 CST(-0600)] <EricDalquist> If a portlet is targeted by a URL generated by the portlet API for that portlet the cache will be invalidated
[11:13:46 CST(-0600)] <Bananobot> Actually, hm... I'm using Spring's form tags, and I'm setting the "path" attributes for the form controls. The generated "name" attributes in the HTML are just being set to the literal value, rather than something translated for the portal..
[11:14:00 CST(-0600)] <EricDalquist> also all forms for portlets must use POST
[11:14:07 CST(-0600)] <EricDalquist> and the path must be set to a portlet API generated URL
[11:14:43 CST(-0600)] <Bananobot> EricDalquist: Why do they all have to be POST? The form isn't to post content, it's to request a resource.
[11:14:52 CST(-0600)] <EricDalquist> the portlet specification says so
[11:14:55 CST(-0600)] <Bananobot> :/
[11:15:09 CST(-0600)] <EricDalquist> if you want I can give you a 2 page technical explination as to why
[11:15:10 CST(-0600)] <holdorph> not true
[11:15:13 CST(-0600)] <Bananobot> Did the portlet specification authors read the HTTP specification before they wrote it?
[11:15:15 CST(-0600)] <holdorph> you can use render urls
[11:15:19 CST(-0600)] <EricDalquist> you can use render URLs
[11:15:21 CST(-0600)] <holdorph> and change the render parameters
[11:15:24 CST(-0600)] <EricDalquist> but they have to be POSTs
[11:15:38 CST(-0600)] <EricDalquist> there is a sound technical reason for this requirement
[11:15:51 CST(-0600)] <holdorph> hmm.... I didn't remember that part.
[11:16:09 CST(-0600)] <holdorph> i know if it's a form, it has to be a post, but I didn't know that render urls had to be posts too.
[11:16:20 CST(-0600)] <EricDalquist> if it is a form it has to be a post
[11:16:38 CST(-0600)] <EricDalquist> the reason is the portal can't appropriately namespace parameters defined as form <input> tags
[11:16:44 CST(-0600)] <holdorph> right, but if it's not a form and it's not a action url, i think it can be a get
[11:16:48 CST(-0600)] <EricDalquist> no
[11:16:50 CST(-0600)] <EricDalquist> it can;'t
[11:16:51 CST(-0600)] <EricDalquist> trust me
[11:16:57 CST(-0600)] <EricDalquist> let me find the spec reference
[11:17:02 CST(-0600)] <Bananobot> Okay.. from the jsp, how do I set a field's name attribute to be prefixed with the portal's stuff?
[11:17:14 CST(-0600)] <Bananobot> I have the action attribute all set up by the portal, but not the name attributes
[11:17:29 CST(-0600)] <holdorph> huh?
[11:17:33 CST(-0600)] <EricDalquist> PLT.7.1 PortletURL
[11:17:39 CST(-0600)] <holdorph> are you using a portlet url Bananobot ?
[11:17:42 CST(-0600)] <EricDalquist> Because some portal/portlet-containers implementations may encode internal state as part
[11:17:42 CST(-0600)] <EricDalquist> of the URL query string, portlet developers should not code forms using the HTTP GET
[11:17:42 CST(-0600)] <EricDalquist> method.
[11:17:56 CST(-0600)] <holdorph> that says 'forms'
[11:18:07 CST(-0600)] <EricDalquist> right
[11:18:15 CST(-0600)] <EricDalquist> so any <form> tag must use method="post"
[11:18:16 CST(-0600)] <Bananobot> holdorph: I have a <portlet:renderURL var="formRender">...</portlet:renderURL> thing, which I use for the form's action attribute.
[11:18:32 CST(-0600)] <Bananobot> In the generated HTML, I see action="/uPortal/render.userLayoutRootNode.target.n62.uP?pltc_target=81_n62_8.n62&pltc_type_81_n62_8.n62=RENDER&pltp_81_n62_8.n62_action=form"
[11:18:43 CST(-0600)] <EricDalquist> yup
[11:18:45 CST(-0600)] <Bananobot> But the "name" attributes for the inputs aren't prefixed with anything
[11:18:46 CST(-0600)] <EricDalquist> that looks right
[11:18:49 CST(-0600)] <holdorph> you don't do that stuff Bananobot
[11:18:57 CST(-0600)] <holdorph> that's done by the portal container
[11:19:18 CST(-0600)] <EricDalquist> ok so here is the reason the POST is required
[11:19:20 CST(-0600)] <Bananobot> I see <select id="Pluto_81_n62_8_n62_institution" name="institution" style="max-width:100%">
[11:19:27 CST(-0600)] <EricDalquist> yup
[11:19:34 CST(-0600)] <EricDalquist> that is correct as well
[11:20:04 CST(-0600)] <EricDalquist> when a browser submits a form using GET it simply appends the <input> parameters to the URL
[11:20:17 CST(-0600)] <EricDalquist> the problem with that is portal URLs are complex
[11:20:27 CST(-0600)] <EricDalquist> there is more than one portlet on a page plus other information the portal needs to track
[11:20:34 CST(-0600)] <EricDalquist> and these appended parameters are not namespaced
[11:21:01 CST(-0600)] <Bananobot> I just redeployed the portlet and reloaded it in Tomcat. When I go to the main uPortal page, I see the main portlet view. When I hit refresh in my browser, it suddenly looks like I had a GET parameter..
[11:21:11 CST(-0600)] <EricDalquist> there is no good way for the portal to track what is coming from the form and what isn;t
[11:21:25 CST(-0600)] <EricDalquist> when you do a POST the form <input> parameters are sent in the body of the HTTP request
[11:21:43 CST(-0600)] <Bananobot> BRB
[11:21:51 CST(-0600)] <EricDalquist> this allows the portal to know that these parameters were submitted in a form for the portlet targeted by the requested URL
[11:21:57 CST(-0600)] <EricDalquist> that is why the POST requirement is there
[11:30:16 CST(-0600)] <Bananobot> Why would request.getParameter("institution") (for a RenderRequest) return non-null if my client URL is just http://localhost:8080/uPortal/render.userLayoutRootNode.uP ?
[11:30:48 CST(-0600)] <EricDalquist> portlets are re-rendered with their last request parameters unless directly targeted by a URL they generated
[11:30:51 CST(-0600)] <EricDalquist> again part of the portlet spec
[11:31:36 CST(-0600)] <Bananobot> How would I manually reset that, for testing purposes?
[11:31:46 CST(-0600)] <EricDalquist> you need to click on a link generated by your portlet
[11:35:25 CST(-0600)] <Bananobot> If forms have to be POST, then how would I use a simple link to point to a different "page" of the portlet?
[11:35:44 CST(-0600)] <Bananobot> Since links are always GET
[11:35:57 CST(-0600)] <EricDalquist> links as get are fine
[11:36:04 CST(-0600)] <EricDalquist> since you add parameters to them using the portlet:param tag
[11:36:07 CST(-0600)] <holdorph> that's what I was trying to say earlier
[11:36:16 CST(-0600)] <holdorph> when you kept telling me i was wrong
[11:36:49 CST(-0600)] <EricDalquist> sorry I thought you were refering to forms still
[11:37:02 CST(-0600)] <holdorph> no
[11:37:04 CST(-0600)] <Bananobot> Then it seems like it should be possible to use a similar method to set up the name attributes for the inputs. If that isn't possible, it seems like that's just an oversight of the portlet standard rather than a real technical limitation.
[11:37:27 CST(-0600)] <EricDalquist> so why is using a POST for a form a problem?
[11:38:02 CST(-0600)] <EricDalquist> and also that is true, the portlet spec could have provided a portlet tag to generate <input> names
[11:38:06 CST(-0600)] <EricDalquist> they didn't though
[11:38:19 CST(-0600)] <EricDalquist> so we're stuck with having to use method="POST" for forms
[11:38:47 CST(-0600)] <EricDalquist> if you want to user to end up at a "GET" URL you can POST to an ActionUrl and have the processAction code simply copy the parameters over to renderParameters
[11:39:18 CST(-0600)] <holdorph> we can debate whether what the spec ended up being was good or bad, but it is a spec formally adopted by the JCP process. We have to obey the spec, if we're trying to say we're compliant with it
[11:39:19 CST(-0600)] <EricDalquist> all portlet actions result in a 302 redirect to a render URL with any render parameters set on the URL during processAction included in the URL
[11:39:28 CST(-0600)] <holdorph> as either the portlet container implementor or as a portlet developer
[11:39:37 CST(-0600)] <Bananobot> If you send the user to a page using POST, that makes the user's back button not work as well (since POST is for modifications of server data, so browsers don't just resend POST requests automatically). It looks like the portal improves things by then redirecting the user to a GET request, but that's additional overhead that shouldn't be necessary for something that should be a GET request from the beginning
[11:39:57 CST(-0600)] <EricDalquist> right so that's why using an actionURL helps
[11:40:16 CST(-0600)] <EricDalquist> because POST->action->302->render results in the POST never making it into the Back history
[11:40:27 CST(-0600)] <EricDalquist> also the back button does NOT play nicely with portlets
[11:40:36 CST(-0600)] <Bananobot> Right, but that's a whole additional user request that really shouldn't be needed.
[11:40:40 CST(-0600)] <EricDalquist> due to the last-render-parameters requirement in the spec
[11:41:01 CST(-0600)] <EricDalquist> true, but that is the only way to solve the problem
[11:41:14 CST(-0600)] <EricDalquist> and is latency that high that you'll have problems from that 302?
[11:41:23 CST(-0600)] <EricDalquist> in practice they appear quite fast
[11:41:44 CST(-0600)] <EricDalquist> also any time you are modifying data on the backend (which most form submits do) you really should be doing that in an action
[11:42:07 CST(-0600)] <EricDalquist> actions have the nice guarantee due to the POST, redirect, GET semantic that they are non-repeatable
[11:43:21 CST(-0600)] <Bananobot> Right, any request that modifies server state should be a POST. But something like a search form (which is essentially what this is) shouldn't need to modify server state, and it shouldn't need a redirect.
[11:43:42 CST(-0600)] <EricDalquist> right
[11:44:00 CST(-0600)] <EricDalquist> unfortunately the post, redirect, get is the best way to do what you want in a portlet
[11:45:43 CST(-0600)] <Bananobot> I'm really new to development in portals. I'm used to PHP programming, where you're working much more closely with the HTTP layer, and the "best practices" of HTTP are very easy to implement. It's just sort of weird for me working in an environment that, by specification, doesn't follow a lot of those practices.
[11:46:14 CST(-0600)] <Bananobot> And I get that there are reasons for some of that
[11:46:33 CST(-0600)] <EricDalquist> right, the problem is portlets are not servlets or other plain old webapps
[11:46:44 CST(-0600)] <EricDalquist> a portlet is one of N applications all rendering on the same page
[11:46:48 CST(-0600)] <EricDalquist> sharing a single URL
[11:47:53 CST(-0600)] <EricDalquist> it is definitely a switch, and the issues you're running into are really common when coming from a 'plain old webapp' development background
[11:48:07 CST(-0600)] <Bananobot> Right. There are rough equivalents in things like Joomla modules, Moodle blocks, etc., and I've developed my own implementation of this sort of thing. But they're typically a lot more loosely-defined and kinda free-for-all than Java portlets. And, there pros and cons to that.
[11:48:17 CST(-0600)] <EricDalquist> yup
[11:48:28 CST(-0600)] <EricDalquist> the big pros that portlets have is with the strict API they are very portable
[11:48:38 CST(-0600)] <EricDalquist> the same portlets that work in uPortal 2.5 works in every version since
[11:49:04 CST(-0600)] <EricDalquist> having that spec makes it easy to do portal side improvements without breaking portlet implementations
[11:49:36 CST(-0600)] <Bananobot> The one major con, from a web standards purist like me, is that the portlets conforming to Portlet API 1.0 can't add stuff to the document head, which means stylesheets have to be implemented in invalid ways
[11:49:53 CST(-0600)] <holdorph> portlet 2.0 addresses that
[11:49:56 CST(-0600)] <Bananobot> Right
[11:50:05 CST(-0600)] <EricDalquist> yeah, that is unfortunate
[11:50:26 CST(-0600)] <EricDalquist> and from the portal point of view we can't realistically enforce xhtml compliance either
[11:50:30 CST(-0600)] <EricDalquist> I tried that in trunk a while back
[11:50:43 CST(-0600)] <EricDalquist> and since portlets just return blobs of text we get invalid XML all over the place
[11:51:42 CST(-0600)] <Bananobot> Yeah, considering the applications for portlets, it would seem reasonable (except maybe from a performance point of view) for the portlet spec to have required some sort of DOM response from portlets
[11:52:13 CST(-0600)] <EricDalquist> yeah, the problem with that is it rules out all the existing java web technologies
[11:52:23 CST(-0600)] <EricDalquist> no JSPs, JSF, struts, tiles, etc
[11:52:37 CST(-0600)] <EricDalquist> since all of those simply assume writing content to a PrintWriter
[12:46:00 CST(-0600)] <EricDalquist> mpolizzotti: do you know if the gallery patch touched how data in the portlet manager is populated?
[12:48:12 CST(-0600)] <mpolizzotti> I cannot be certain. I worked with Jen on the Gallery and we each worked on separate parts.
[12:48:20 CST(-0600)] <EricDalquist> ok
[12:48:53 CST(-0600)] <mpolizzotti> The portlet manager is just the mechanism by which a user toggles through the portlets in the gallery...correct?
[12:49:19 CST(-0600)] <EricDalquist> it is the administrative tool used to publish new portlets
[12:49:26 CST(-0600)] <mpolizzotti> oh...okay.
[12:49:45 CST(-0600)] <EricDalquist> the problem I'm having is it should be populating the pager with all channels, not just those in categories
[12:49:47 CST(-0600)] <mpolizzotti> I think Jen can speak more to how the data is handled in that regard.
[12:50:01 CST(-0600)] <EricDalquist> but the non-categorized channels are not showing up
[12:50:12 CST(-0600)] <EricDalquist> thanks, I'll go hunt her down
[12:50:17 CST(-0600)] <mpolizzotti> k
[14:28:53 CST(-0600)] <athena> EricDalquist: i've managed to reproduce that mobile first-request bug now, which makes me think my previous fix didnt' actually work
[14:29:12 CST(-0600)] <athena> what i'm getting is
[14:29:12 CST(-0600)] <athena> Nested Exception is java.lang.NullPointerException
[14:29:13 CST(-0600)] <athena> at org.apache.pluto.tags.NamespaceTag.doStartTag(NamespaceTag.java:40)
[14:29:26 CST(-0600)] <athena> from that stack trace, it looks like this is probably returning null:
[14:29:36 CST(-0600)] <athena> RenderResponse renderResponse = (RenderResponse) pageContext
[14:29:37 CST(-0600)] <athena> 39: .getRequest().getAttribute("javax.portlet.response");
[15:01:14 CST(-0600)] <EricDalquist> huh
[15:01:21 CST(-0600)] <EricDalquist> so renderResponse is null?
[15:01:34 CST(-0600)] <EricDalquist> hrm
[15:02:01 CST(-0600)] <athena> yeah, it seems like that's what's happening
[15:02:10 CST(-0600)] <athena> getting an NPE on the line that uses it
[15:02:20 CST(-0600)] <EricDalquist> uhg
[15:02:21 CST(-0600)] <EricDalquist> weird
[15:02:27 CST(-0600)] <EricDalquist> very weird
[15:02:38 CST(-0600)] <athena> yeah
[15:02:43 CST(-0600)] <athena> i mean . . . mobile's not that different
[15:02:54 CST(-0600)] <athena> basically the difference is that the initial view doesn't show any portlets
[15:03:05 CST(-0600)] <athena> so maybe if there's something that gets initialized normally before going to focus mode?
[15:03:22 CST(-0600)] <EricDalquist> yeah
[15:03:36 CST(-0600)] <EricDalquist> did you need to do anything special to reproduce it?
[15:06:53 CST(-0600)] <athena> no, just hammer at it
[15:06:56 CST(-0600)] <athena> seems pretty random
[15:07:19 CST(-0600)] <athena> log out, log in, hit course schedule portlet (the one i'm testing with at the moment)
[15:07:42 CST(-0600)] <athena> haven't been able to reproduce it w/ the normal theme via using focus mode, though that uses fname rather than root
[15:07:54 CST(-0600)] <EricDalquist> ok
[15:08:22 CST(-0600)] <athena>
[15:08:43 CST(-0600)] <EricDalquist> I'm traveling tomorrow but might be able to take a look on Thursday
[15:08:55 CST(-0600)] <athena> that'd be appreciated - i'm really not sure what's going on
[15:32:03 CST(-0600)] <EricDalquist> I wish eclipse gave me the same refactoring tools for JS as it does for Java
[15:32:09 CST(-0600)] <EricDalquist> I want "extract method"
[15:33:37 CST(-0600)] <athena> yeah
[15:45:42 CST(-0600)] <EricDalquist> ok ... I got it all fixed but now All shows up twice in the drop down
[16:15:00 CST(-0600)] <EricDalquist> weather portlet 1.0.7 released
[17:06:37 CST(-0600)] <mpolizzotti> Evening everyone. Just a quick note. I just checked in some updates to the Groups Administration Portlet's search feature for UP-2742. Any feed back is welcome.

Browser not supported