Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 17 Current »

[10:06:48 CDT(-0500)] * dmccallum (n=dmccallu@uni1.unicon.net) has joined ##uportal
[12:02:33 CDT(-0500)] * deuce (n=deuce@uni1.unicon.net) has joined ##uportal
[16:41:17 CDT(-0500)] * peterk_ (i=[U2FsdGV@66.226.77.81) has joined ##uportal
[17:18:55 CDT(-0500)] <deuce> peter?
[17:20:44 CDT(-0500)] <peterk_> hi Nick
[17:22:07 CDT(-0500)] <deuce> in what case(s) would a portlet get render request params if they are not targeted?
[17:22:47 CDT(-0500)] <peterk_> if the render param was set at any point earlier
[17:23:04 CDT(-0500)] <peterk_> the portal hangs on to the values and resends them at every request
[17:23:14 CDT(-0500)] <peterk_> that's in the spec (which was a surprise to me, I remember)
[17:24:30 CDT(-0500)] <deuce> hmmm .. but doesn't that mean that in those cases, the portlet will not be pulling from cache? because we explictly invalidate the portlet cache
[17:25:29 CDT(-0500)] <deuce> essentially .. if i click into a portlet, it will not ever pull from cache again?
[17:25:45 CDT(-0500)] <peterk_> no, won't pull from cache
[17:25:52 CDT(-0500)] <peterk_> but the render params are independent from cache
[17:25:52 CDT(-0500)] <deuce> that's bad
[17:26:12 CDT(-0500)] <peterk_> "not pulling from cache" upon interaction is in the spec too (sad)
[17:26:57 CDT(-0500)] <deuce> that's understandable, but if i don't interact with a portlet, i'd expect it to try to pull from cache
[17:27:12 CDT(-0500)] <peterk_> that it will do
[17:27:27 CDT(-0500)] <peterk_> but if you hit a url on it, it won't pull from cache.
[17:27:58 CDT(-0500)] <deuce> well, it will try, but if a render param has previously set, the cache will always be invalidated
[17:28:05 CDT(-0500)] <deuce> ?
[17:28:38 CDT(-0500)] <peterk_> no, only if a new render param value was passed
[17:28:54 CDT(-0500)] <deuce> i thought you said they were carried along
[17:29:00 CDT(-0500)] <peterk_> basically, invalidation is handled by the PortletWindowManagerImpl ... line 260 is where it gets invalidated for new render params
[17:29:13 CDT(-0500)] <deuce> yep .. looking at that
[17:29:19 CDT(-0500)] <peterk_> they are carried along, but the cacheis only cleared if new param values are passed
[17:29:33 CDT(-0500)] <peterk_> essentially, this method is only called when new values are passed, not when the old ones are being reused
[17:29:36 CDT(-0500)] <deuce> but i'm hitting that for a portlet i'm not interacting with
[17:30:03 CDT(-0500)] <peterk_> and it's not reusing the cache? is it getting into that method?
[17:30:09 CDT(-0500)] <deuce> yes
[17:30:33 CDT(-0500)] <peterk_> weird .. what's the stack trace?
[17:30:43 CDT(-0500)] <deuce> no stack
[17:30:47 CDT(-0500)] <deuce> no error
[17:30:57 CDT(-0500)] <deuce> it just re-renders .. incorrectly
[17:31:11 CDT(-0500)] <peterk_> no, I mean where was setPortletRenderRequestParameters() called from?
[17:31:19 CDT(-0500)] <peterk_> for that window Id
[17:32:01 CDT(-0500)] <deuce> oh .. PortletRequestParameterProcessor:116
[17:33:08 CDT(-0500)] <peterk_> hmm, looks odd. let me check it out
[17:33:20 CDT(-0500)] <deuce> want a use case?
[17:34:39 CDT(-0500)] <peterk_> so in that location, what's the targetWindow value ?
[17:34:52 CDT(-0500)] <peterk_> that windowMap should contain only target window (which means that the window was somehow targeted)
[17:34:52 CDT(-0500)] <deuce> 28
[17:35:18 CDT(-0500)] <peterk_> is that the window that you're trying not to interact with ? (smile)
[17:36:14 CDT(-0500)] <deuce> targetWindow=28, windowId=29
[17:37:49 CDT(-0500)] <peterk_> can you paste the url (or is this a put?)
[17:38:21 CDT(-0500)] <deuce> there are no parameters in the parameters Map which correspond to window 29
[17:39:12 CDT(-0500)] <peterk_> yah, but if it endedup with windowId 29, this should only be able to happen at line 82, which means that there was some param that was targeting window 29 ...
[17:39:26 CDT(-0500)] <peterk_> or the parameterSyntax implementation is screwy
[17:40:16 CDT(-0500)] <peterk_> can you try to put a breakpoint at PortletRequestParameterProcessor:82 and see what param gets you windowId of 29?
[17:40:23 CDT(-0500)] <deuce> yup
[17:41:46 CDT(-0500)] <deuce> well, lookie there .. there is one for 29
[17:42:41 CDT(-0500)] <peterk_> where did it come from ? (smile)
[17:42:46 CDT(-0500)] <deuce> ha!
[17:43:09 CDT(-0500)] <deuce> that's where the fun begins (actually, it began about 3 hours ago)
[17:43:10 CDT(-0500)] <deuce> (smile)
[17:43:21 CDT(-0500)] <peterk_> servant stuff? (smile)
[17:43:25 CDT(-0500)] <deuce> si
[17:44:44 CDT(-0500)] <deuce> hmmm .. i wonder if webflow is doing a setRenderParameter
[17:45:06 CDT(-0500)] <peterk_> can't help you there man
[17:45:17 CDT(-0500)] <deuce> no problem .. thanks
[17:45:23 CDT(-0500)] <peterk_> welcome.
[19:15:36 CDT(-0500)] * dmccallum (n=dmccallu@uni1.unicon.net) has left ##uportal
[19:31:43 CDT(-0500)] * deuce (n=deuce@uni1.unicon.net) has joined ##uportal
[20:32:57 CDT(-0500)] * peterk (n=Kharchen@24-181-226-126.dhcp.oxfr.ma.charter.com) has joined ##uportal
[20:33:06 CDT(-0500)] <peterk> deuce: still workin?
[21:08:30 CDT(-0500)] * peterk_ (n=Kharchen@24-181-226-126.dhcp.oxfr.ma.charter.com) has joined ##uportal
[21:16:15 CDT(-0500)] * deuce (n=deuce@ip70-190-171-187.ph.ph.cox.net) has joined ##uportal

  • No labels