[11:00:06 CDT(-0500)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[11:19:03 CDT(-0500)] * shawnlonas (n=shawn@uni1.unicon.net) has joined ##uportal
[12:45:49 CDT(-0500)] * andrewpetro (n=microcli@uni1.unicon.net) has joined ##uportal
[13:02:26 CDT(-0500)] * bszabo (n=bszabo@uni1.unicon.net) has joined ##uportal
[13:08:28 CDT(-0500)] * arybicki (n=arybicki@uni1.unicon.net) has joined ##uportal
[13:30:11 CDT(-0500)] <EricDalquist> Unicon folks ... is there I # I should call in to for the sprint meeting?
[13:30:21 CDT(-0500)] <EricDalquist> I've had a rather crazy morning and am just now available for a call
[13:31:55 CDT(-0500)] <deuce_> i think we finished up the sprint planning yesterday
[13:32:10 CDT(-0500)] <EricDalquist> ok
[13:33:05 CDT(-0500)] <deuce_> did charise contact you about working on any issues?
[13:33:42 CDT(-0500)] <EricDalquist> we were supposed to have a call this morning
[13:33:51 CDT(-0500)] <EricDalquist> but I've been at home taking care of a pumbing problem
[13:33:58 CDT(-0500)] <andrewpetro> sorry to hear about the plumbing
[13:34:05 CDT(-0500)] <andrewpetro> I hope the turtle didn't escape in the flood
[13:34:36 CDT(-0500)] <EricDalquist> rather frustraiting ... second time this month we've had a problem with the feed line for the toilet, before the shut off valve of course
[13:35:45 CDT(-0500)] * dmccallum (n=dmccallu@uni1.unicon.net) has joined ##uportal
[13:39:52 CDT(-0500)] <dmccallum> Eric, sorry we didn't catch you this morning. I see you had some plumbing trouble this morning
[13:40:10 CDT(-0500)] <EricDalquist> yeah, a bit of a frustraiting day so far
[13:41:33 CDT(-0500)] <dmccallum> Charise had mentioned you were about 40% done with UPT-209. We had looked at UPT-57 and UPT-153 as additional tickets you might be interested in
[13:41:52 CDT(-0500)] <EricDalquist> talking about that with her via aim right now 
[13:41:59 CDT(-0500)] <dmccallum> ok. good deal
[13:42:08 CDT(-0500)] <EricDalquist> ok, so yes I'll see what I can do on those this week
[13:42:28 CDT(-0500)] <EricDalquist> er 'work on
[13:42:57 CDT(-0500)] <EricDalquist> UPT-153 should be pretty short I'll just want to sync with everyone before I do it since I'll be moving all the spring config XMLs around
[13:43:39 CDT(-0500)] <EricDalquist> UPT-209 is almost done but I'm stuck on how to influence the XSLT parameters from a component in the rendering pipeline
[13:44:50 CDT(-0500)] <deuce_> threats work nicely
[13:44:52 CDT(-0500)] <dmccallum> on UPT-153.... if we can hold off on that for a little bit, we've got a good chunk of context config we still need to check in for the perm. mgr. portlet.
[13:45:04 CDT(-0500)] <EricDalquist> no problem
[13:45:24 CDT(-0500)] <EricDalquist> @ deuce_ ... I'll try growling at it and see if that helps 
[14:48:17 CDT(-0500)] <EricDalquist> hrm ... anyone here at least passingly familiar with the rendering chain for the up2 context?
[14:50:53 CDT(-0500)] <dmccallum> i'm not at all. deuce may know something, but i think he's out for the afternoon. or i can track down allen haws. he's probably our next best bet with peter unavailable
[14:51:25 CDT(-0500)] <EricDalquist> hrm ... ok I may just put finishing this off for a bit ...
[14:51:59 CDT(-0500)] <EricDalquist> the issue I have is I need to look at all the portlets on a user's layout to get WindowStates/PortletModes and set the correct XSLT parameters
[14:52:32 CDT(-0500)] <EricDalquist> problem is the only way I know to get the portlets in the layout is with a SAX filter but at that point it is too late to set XSLT parameters on the transformer
[14:52:34 CDT(-0500)] <EricDalquist> :/
[15:23:24 CDT(-0500)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[15:37:36 CDT(-0500)] <andrewpetro> shot from the hip
[15:37:45 CDT(-0500)] <andrewpetro> you could have two transforms
[15:37:58 CDT(-0500)] <andrewpetro> an initial no-op transform for applying the sax filter to detect the portlets
[15:38:10 CDT(-0500)] <andrewpetro> that then provides input to the second (present) actually-work-doing transform
[15:38:30 CDT(-0500)] <andrewpetro> sounds like it would just slow things down, but presumably the immediate pressure is on demonstrating functionality at all and performance can be optimized laterish
[15:39:14 CDT(-0500)] <EricDalquist> yeah
[15:39:24 CDT(-0500)] <EricDalquist> not sure what the best way to acomplish that is
[15:39:48 CDT(-0500)] <EricDalquist> this is really just an issue in the up2 context
[15:40:08 CDT(-0500)] <EricDalquist> the up3 context we can just say that the window state is an attribute on the <portlet> layout element
[15:40:11 CDT(-0500)] <EricDalquist> thats easy to do
[15:55:55 CDT(-0500)] <deuce_> "performance optimized laterish" – bah
[15:55:58 CDT(-0500)] <deuce_>
[15:58:12 CDT(-0500)] <EricDalquist>
[15:59:57 CDT(-0500)] <EricDalquist> so my current plan is to put a SaxBufferImpl after the sax fitler that detects the modes/states for all of the portlets in a user's layout
[16:00:16 CDT(-0500)] <EricDalquist> that detecting filter will write the changes to the structure rendering attributes object
[16:00:56 CDT(-0500)] <EricDalquist> once endDocument is called on the detecting filter it will flush the buffer and the structure transform will actually get the correct parameters for min/max/etc..
[16:01:12 CDT(-0500)] <deuce_> why is buffering needed?
[16:02:41 CDT(-0500)] <EricDalquist> oh yeah you missed the problem
[16:03:10 CDT(-0500)] <deuce_> :-/
[16:03:12 CDT(-0500)] <EricDalquist> so I'm working on code to make sure the XSLT rendering parameters are set right in the uP2 context for the WindowStates/PortletModes of the portlets on a user's layout
[16:03:50 CDT(-0500)] <EricDalquist> first thought was to just have a SaxFilter in the rendering pipe to look at the PortletWindow for each portlet in the layout and include the appropriate info
[16:03:58 CDT(-0500)] <deuce_> right
[16:04:04 CDT(-0500)] <EricDalquist> the problem is the uP2 XSL expects the info as XSLT rendering parameters
[16:04:32 CDT(-0500)] <EricDalquist> by the time I'm looking at the portlets in the SAX event stream its too late to set rendering parameters on the Transformer
[16:04:43 CDT(-0500)] <EricDalquist> *If I understand this all correctly
[16:05:59 CDT(-0500)] <deuce_> i see .. you could probably invent a sax filter that knew about the transformer and could inject xsl params on-the-fly
[16:06:15 CDT(-0500)] <deuce_> hmm
[16:06:19 CDT(-0500)] <EricDalquist> I could but I believe the sax chain is being fed right into the transformer
[16:06:28 CDT(-0500)] <EricDalquist> which means that I would have to buffer the events
[16:06:46 CDT(-0500)] <EricDalquist> since I don't think I can set parameters on the transformer once it has started transforming
[16:06:50 CDT(-0500)] <deuce_> it is .. but the transformation doesn't actually happen until the closing document element i believe
[16:06:55 CDT(-0500)] <EricDalquist> ah
[16:07:18 CDT(-0500)] <deuce_> could be possible .. just a suggestion
[16:07:20 CDT(-0500)] <EricDalquist> hrm, I'll try hacking that up and seeing if it work
[16:07:27 CDT(-0500)] <deuce_>
[16:07:32 CDT(-0500)] <EricDalquist> thanks for the suggestion
[16:07:58 CDT(-0500)] <deuce_> sure .. the only problem is that it's transformer engine dependent, so probably not ideal
[16:08:09 CDT(-0500)] <EricDalquist> yeah :/
[16:08:45 CDT(-0500)] <EricDalquist> this would be a non-issue if the state/mode info was encoded in the attributes on the portlet nodes in the layout vs via XSLT parameters
[16:09:13 CDT(-0500)] <deuce_> what would it take to convert it?
[16:09:36 CDT(-0500)] <EricDalquist> well for the up3 context I think we'll just plan on it
[16:09:46 CDT(-0500)] <deuce_> gotcha
[16:09:51 CDT(-0500)] <EricDalquist> for up2 we have this unfortunate 'backwards compatibility' issue
[16:09:58 CDT(-0500)] <deuce_> ah yes
[16:10:07 CDT(-0500)] <deuce_> fbc
[16:10:07 CDT(-0500)] <EricDalquist> I'd rather just tweak the XSL
[16:10:22 CDT(-0500)] <EricDalquist> but we want people to be able to just drop in their uP2 XSLs
[16:10:38 CDT(-0500)] <deuce_> yepo
[16:12:42 CDT(-0500)] <EricDalquist> hey, on a different note
[16:13:06 CDT(-0500)] <EricDalquist> what is your opinion on how we get reqest/response objects passed around the rendering pipeline (and other parts of the framework)?
[16:14:24 CDT(-0500)] <deuce_> are you talking about the string and sax components?
[16:14:46 CDT(-0500)] <EricDalquist> well and just in general
[16:15:00 CDT(-0500)] <EricDalquist> it seems like the issue with multiple simultaneous requests from a user relates to this
[16:15:31 CDT(-0500)] <EricDalquist> like for this portlet mode/state filter I just wrote I have to get the request from the pipeline event and store it in an instance variable
[16:15:45 CDT(-0500)] <EricDalquist> so the filter can never be used by more than one thread at a time
[16:16:23 CDT(-0500)] <EricDalquist> even though that request is really the only thing that makes it non-thread safe
[16:16:54 CDT(-0500)] * arybicki (n=arybicki@uni1.unicon.net) has left ##uportal
[16:18:24 CDT(-0500)] <deuce_> Any instance of IPortalRenderer should have access to the servlet objects
[16:20:23 CDT(-0500)] <EricDalquist> well the renderer does but the way the they are provieded to parts of the pipeline in the renderer is the issue
[16:20:38 CDT(-0500)] <EricDalquist> or is the plan right now to have the entire renderer synchronized
[16:22:20 CDT(-0500)] <deuce_> we added that because not all the rendering components are thread safe
[16:22:31 CDT(-0500)] <EricDalquist> ok
[16:23:19 CDT(-0500)] <deuce_> peter has a page written up about it
[16:23:25 CDT(-0500)] <deuce_> http://www.ja-sig.org/wiki/display/UP3/Multiple+concurrent+requests+for+the+same+user+%28session%29
[16:23:29 CDT(-0500)] <EricDalquist> thanks
[18:49:20 CDT(-0500)] * bszabo (n=bszabo@uni1.unicon.net) has left ##uportal
[19:06:18 CDT(-0500)] * shawnlonas (n=shawn@uni1.unicon.net) has left ##uportal
[19:32:56 CDT(-0500)] * dmccallum (n=dmccallu@uni1.unicon.net) has left ##uportal
[23:43:37 CDT(-0500)] * andrewpetro (n=microcli@uni1.unicon.net) has left ##uportal
General
Content
Integrations