[08:03:37 EST(-0500)] * jayshao (n=jayshao@jayshao.oirt.rutgers.edu) has joined ##uportal
[08:10:59 EST(-0500)] * jayshao (n=jayshao@jayshao.oirt.rutgers.edu) has joined ##uportal
[08:44:51 EST(-0500)] * awills (n=awills@tp-wireless.its.yale.edu) has joined ##uportal
[09:07:39 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[09:47:58 EST(-0500)] * colinclark (n=atrcwrk2@142.150.154.101) has joined ##uportal
[10:16:41 EST(-0500)] * michelled (n=team@142.150.154.114) has joined ##uportal
[12:07:05 EST(-0500)] <EricDalquist> morning all
[12:07:43 EST(-0500)] <EricDalquist> anyone here want to talk uportal structure/theme parameters with me?
[12:21:34 EST(-0500)] <awills> I'm game 
what's up?
[12:22:26 EST(-0500)] <EricDalquist> just working on the pluto integration (taking a lot longer than I hoped it would, but I'm making good changes to the pipeline) and want to see if an idea for syncing portlet states/modes with the layout sounds sane
[12:22:46 EST(-0500)] <awills> ok
[12:23:18 EST(-0500)] <EricDalquist> so right now UserInstace.renderState() is pretty much the pipeline
[12:23:28 EST(-0500)] <awills> you mean WindowStates and PortletModes specifically? or other stateful data as well?
[12:23:59 EST(-0500)] <awills> um yes... there's a lot of code in there
[12:24:00 EST(-0500)] <EricDalquist> in it UserPreferencesManagers.processUserPreferencesParameters(request) is called to update the layout prefs that control min/max and such for channels in the layout
[12:24:17 EST(-0500)] <EricDalquist> in this case just PortletModes & WindowStates
[12:24:30 EST(-0500)] <awills> alright, i follow
[12:24:40 EST(-0500)] <EricDalquist> so this parsing method works for channels because channels don't have a stateful idea of min/max/etc
[12:24:47 EST(-0500)] <EricDalquist> those are just channel events they are notified of
[12:25:18 EST(-0500)] <awills> gotcha... i think
[12:25:22 EST(-0500)] <EricDalquist> with portlets it is a pain, since they are stateful (ie once a portlet switches to minimized we have to keep telling it that it is minimized until that changes)
[12:25:31 EST(-0500)] <awills> yeppers
[12:26:20 EST(-0500)] <EricDalquist> so I'm thinking this ... we add a portlet state data -> layout state data syncing step in the rendering pipeline
[12:26:45 EST(-0500)] <EricDalquist> so when a portlet is clicked on and requests MAXIMIZED in the URL, that gets parsed by the URL processing code I'm just finishing up
[12:26:55 EST(-0500)] <EricDalquist> when we get to rendering we do the following logic:
[12:27:16 EST(-0500)] <EricDalquist> if the request targets a portlet and is maximized we update the layout prefs correctly to maximize that channel element
[12:27:20 EST(-0500)] <EricDalquist> else
[12:27:39 EST(-0500)] <awills> so essentially those parameters get re-added before UserPreferencesManagers.processUserPreferencesParameters(request) for portlet modes & window states?
[12:28:19 EST(-0500)] <EricDalquist> determine the channels on the currently targeted tab, for each channel see if it is a portlet, for each portlet we update the preferences for that channel element to sync with the current normal/minimized view/help/edit state & mode for the portlet
[12:28:31 EST(-0500)] <EricDalquist> yeah
[12:29:01 EST(-0500)] <EricDalquist> though I think I may see about moving the logic in UserPreferencesManagers.processUserPreferencesParameters(request) to the url parameter processing chain that now exists
[12:29:26 EST(-0500)] <awills> yes i think it's a good idea to look at that...
[12:29:55 EST(-0500)] <EricDalquist> so that sync step would explicitly update the theme layout preferences for all portlets on the tab
[12:30:14 EST(-0500)] <EricDalquist> ensuring that there isn't this sync problem, the state & mode for portlets will simply be mastered from the portlet window objects
[12:30:15 EST(-0500)] <awills> there are probably some thing that are don't in the rendering pipeline as first-class concepts that don't need to be... could be grouped w/ similar behavior
[12:30:27 EST(-0500)] <EricDalquist> yeah
[12:30:35 EST(-0500)] <EricDalquist> parameter processing is the first one of those to go
[12:30:48 EST(-0500)] <EricDalquist> then it all happens up front and in one place
[12:35:29 EST(-0500)] <awills> sounds great
[12:35:37 EST(-0500)] <EricDalquist> thanks
[12:35:51 EST(-0500)] <EricDalquist> it is really helpful to talk these things through here before I go and do them
[12:36:50 EST(-0500)] <awills> lol, meant to say: "there are probably some things that are done in the rendering pipeline as first-class concepts that don't need to be (first-class concepts)... and could be grouped w/ similar behavior"
[12:36:59 EST(-0500)] <awills> for the logs 
[12:54:43 EST(-0500)] * athena7 (n=athena7@tp-wireless.its.yale.edu) has joined ##uportal
[13:27:00 EST(-0500)] * ac_chan (n=alex@tempoutsidepix.pratt.edu) has joined ##uportal
[13:41:45 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[15:23:52 EST(-0500)] * athena7_ (n=athena7@lumina.its.yale.edu) has joined ##uportal
[15:25:19 EST(-0500)] * athena7 (n=athena7@tp-wireless.its.yale.edu) has joined ##uportal
[15:30:36 EST(-0500)] * colinclar1 (n=atrcwrk2@142.150.154.101) has joined ##uportal
[15:56:23 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[16:00:18 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[16:18:51 EST(-0500)] * clown (n=chatzill@guiseppi.atrc.utoronto.ca) has joined ##uportal
[17:27:33 EST(-0500)] * colinclark (n=atrcwrk2@142.150.154.101) has joined ##uportal
[17:31:48 EST(-0500)] * awills (n=awills@tp-wireless.its.yale.edu) has left ##uportal
[17:47:05 EST(-0500)] * clown (n=chatzill@guiseppi.atrc.utoronto.ca) has left ##uportal
[22:43:15 EST(-0500)] * EiNZTEiN (i=einztein@check.your.ignorelist.com) has joined ##uportal
[22:43:33 EST(-0500)] * lescour (n=lescour@129.244.24.211) has joined ##uportal
General
Content
Integrations