Page Comparison

[09:02:26 CDT(-0500)] * JASIGLogBot (n=PircBot@mammoth.doit.wisc.edu) has joined ##uportal
[09:02:26 CDT(-0500)] * Topic is 'go uP3 go' set by EricDalquist on 2006-09-19 10:24:54 CDT(-0500)
[09:46:03 CDT(-0500)] * dmccallum (n=dmccallu@uni1.unicon.net) has joined ##uportal
[11:23:58 CDT(-0500)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[11:44:13 CDT(-0500)] * peterk_ (i=[U2FsdGV@66.226.77.81) has joined ##uportal
[11:56:43 CDT(-0500)] <EricDalquist> hey peterk_ got your email about the portlet mode/state parameters
[11:56:57 CDT(-0500)] <EricDalquist> the issue is with maximizing a portlet
[11:57:09 CDT(-0500)] <EricDalquist> I believe that is passed in as a XSLT parameter to the transformer
[11:58:00 CDT(-0500)] <EricDalquist> my 'solution' right now is the SaxFilter that looks at all the portlets being rendered has a reference to the TransformationFilter and gets the Transformer from it
[11:58:12 CDT(-0500)] <EricDalquist> I'm not sure this is a very valid solution though
[11:58:34 CDT(-0500)] <EricDalquist> and it definetly relies on the transform not starting until the endDocument event
[11:59:10 CDT(-0500)] <peterk_> right, that's not very good
[11:59:47 CDT(-0500)] <EricDalquist> the minimized and edit/help/view I can do via XML attributes in startElement
[11:59:50 CDT(-0500)] <peterk_> hmm ... so all this is to allow portlet to focus on itself by switching to a maximized state during the action processing?
[11:59:56 CDT(-0500)] <EricDalquist> but maximized is a bit of a problem
[12:00:28 CDT(-0500)] <EricDalquist> well right now the portlet changing it's state in any way doesn't affect the style sheet rendered UI
[12:00:54 CDT(-0500)] <EricDalquist> so the goal is to have a strong connection between the actuall WindowStates of things renderings in a user's layout and what the style sheets are doing
[12:01:06 CDT(-0500)] <peterk_> right, I understand.
[12:01:35 CDT(-0500)] <peterk_> but let's focus on that maximized state. How can it change ? 1. by incoming request param (i.e. user hits chrome button) or 2. by portlet changing its state
[12:01:36 CDT(-0500)] <peterk_> right?
[12:01:43 CDT(-0500)] <EricDalquist> yup
[12:01:44 CDT(-0500)] <peterk_> and 2. can only happen during action processing
[12:02:05 CDT(-0500)] <EricDalquist> and a portlet can change its state via a RenderUrl, ActionUrl or via a direct API call in processAction
[12:02:36 CDT(-0500)] <peterk_> well, url processing is done before rendering starts. so is action
[12:02:47 CDT(-0500)] <EricDalquist> ok
[12:02:48 CDT(-0500)] <peterk_> so we could take care of that state before we even get to the rendering pipeline
[12:03:20 CDT(-0500)] <EricDalquist> so we need to move the processing for maximized up in the chain for the up2 context
[12:03:51 CDT(-0500)] <EricDalquist> something that checks the state of the targeted portlet after all the URL/action processing and sets the appropriate structure parameter?
[12:04:31 CDT(-0500)] <peterk_> well, what you want to do is make sure that xslt param is updated whenever any portlet is switched to maximized mode (which can happen by three different ways we've listed)
[12:11:08 CDT(-0500)] * peterk_ (i=[U2FsdGV@66.226.77.81) has joined ##uportal
[12:12:55 CDT(-0500)] <peterk_> Eric: there's another way to fix the first solution
[12:13:22 CDT(-0500)] <EricDalquist> the first solution?
[12:13:27 CDT(-0500)] <EricDalquist> the chrome side is all set
[12:13:51 CDT(-0500)] <EricDalquist> its the PortletWindow side that needs the work
[12:14:41 CDT(-0500)] <peterk_> ok, not sure I get it. The implementation you have right now is acquiring transformer from the filter, and hopes that the transformation hasn't started, right?
[12:14:52 CDT(-0500)] <peterk_> what's the portletwindow problem?
[12:15:52 CDT(-0500)] <EricDalquist> yes
[12:16:16 CDT(-0500)] <peterk_> we can modify TransformerFilter to call renderingAttributeInjector.prepareTransformer() on startElement instead of the start of the rendering cycle as it's currently done.
[12:16:16 CDT(-0500)] <EricDalquist> so, I have a URL processor that can take all of the crome commands for state and mode and apply them to the PortletWindow
[12:16:35 CDT(-0500)] <peterk_> Then you can modify your filter into a buffer (there's a base class for that), and just inject the appropriate rendering attribute provider
[12:17:09 CDT(-0500)] <EricDalquist> the PortletWindow part is making sure the XSLT parameters and XML attributes are in sync with the modes and states of all the portlets in the layout
[12:18:19 CDT(-0500)] <peterk_> isn't that just setting appropriate rendering attributes?
[12:18:47 CDT(-0500)] <peterk_> in the filter
[12:19:14 CDT(-0500)] <EricDalquist> do you mean XSLT Transformer parameters?
[12:19:29 CDT(-0500)] <peterk_> XSLT transformer params come from rendering attribute provider
[12:19:38 CDT(-0500)] <EricDalquist> so yes
[12:19:42 CDT(-0500)] <EricDalquist> it is doing that
[12:20:07 CDT(-0500)] <EricDalquist> the problem is the rendering attributes are read from the provider before any code knows what portlets are on the page
[12:20:57 CDT(-0500)] <EricDalquist> so what we were talking about earlier should work, some uP2 context specific code that watches for a portlet being maximized in the URL processing and portletAction handling sections
[12:21:01 CDT(-0500)] <peterk_> right, that's why I am saying we should modify TransformerImpl to call renderingAttributeInjector.prepareTransformer() on documentStart call, instead of the start of the rendering cylce as it's currently done. It is that call that moves the values of the rendering attributes into transformer params
[12:21:18 CDT(-0500)] <EricDalquist> yeah
[12:21:20 CDT(-0500)] <EricDalquist> that would work
[12:21:26 CDT(-0500)] <EricDalquist> then the buffer idea would work
[12:21:30 CDT(-0500)] <peterk_> if you place a sax buffer upstream of the transformations that will pick out portlets and set appropriate values of the rendering attributes on the providers, it should work
[12:21:35 CDT(-0500)] <EricDalquist> then the buffer idea would work
[12:22:37 CDT(-0500)] <EricDalquist> ok, so I'll modify TransformationFilter to do the prepareTransformer call in startDocument
[12:22:47 CDT(-0500)] <peterk_> That call is now in TransformerImpl:119, and should be moved to line 312 or something
[12:22:55 CDT(-0500)] <EricDalquist> yup
[12:23:28 CDT(-0500)] <EricDalquist> then I'll create an extension of SaxBufferImpl that updates the structure and theme transform attributes based on the portlet modes and states
[12:23:30 CDT(-0500)] <peterk_> and your filter should extend SaxBufferImpl then
[12:23:35 CDT(-0500)] <peterk_> right
[12:23:35 CDT(-0500)] <peterk_>
[12:23:48 CDT(-0500)] <EricDalquist> when that buffer see's endDocument it will flush the buffer
[12:23:53 CDT(-0500)] <peterk_> correct
[12:24:00 CDT(-0500)] <EricDalquist> cool
[12:24:41 CDT(-0500)] <deuce_> i like auto-flushing technology
[12:25:06 CDT(-0500)] <peterk_> particularly in the airports
[12:25:13 CDT(-0500)] <EricDalquist> you know you can train cats to do that?
[12:25:27 CDT(-0500)] <deuce_> wish i could train mine
[12:26:03 CDT(-0500)] <EricDalquist> Problem is they are usually entertained by it
[12:26:08 CDT(-0500)] <EricDalquist> and will spend hours just flushing
[12:26:13 CDT(-0500)] <EricDalquist> gets a bit expensive
[13:52:52 CDT(-0500)] <EricDalquist> Looking for some validation here ... the URL parameters uP_edit_target/uP_help_target/uP_about_target aren't actually used by the structure/theme style sheets for anything right?
[13:59:50 CDT(-0500)] <peterk_> shoudln't be - in uP2 these are just processed by the framework to generate appropriate channel events
[14:11:18 CDT(-0500)] <EricDalquist> ok
[14:29:25 CDT(-0500)] <EricDalquist> yay ... just found a bug in the portlet URL generation code
[14:30:24 CDT(-0500)] <peterk_> :/
[14:31:06 CDT(-0500)] <EricDalquist> it always sets the mode to View and state to Normal unless your portlet URL requests something else
[14:31:13 CDT(-0500)] <EricDalquist> instead of just leaving them be
[14:31:18 CDT(-0500)] <EricDalquist> easy fix
[14:31:20 CDT(-0500)] <EricDalquist> just annoying
[19:14:44 CDT(-0500)] * EricDalquist (n=dalquist@adsl-76-208-67-25.dsl.mdsnwi.sbcglobal.net) has joined ##uportal