[00:03:11 CDT(-0500)] * deuce (n=deuce@ip70-190-171-187.ph.ph.cox.net) has joined ##uportal
[09:20:20 CDT(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[09:23:06 CDT(-0500)] * deuce_ (n=deuce@ip70-190-171-187.ph.ph.cox.net) has joined ##uportal
[10:40:19 CDT(-0500)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[10:46:54 CDT(-0500)] * andrewpetro (n=microcli@uni1.unicon.net) has joined ##uportal
[11:54:44 CDT(-0500)] * dmccallum (n=dmccallu@uni1.unicon.net) has joined ##uportal
[12:10:07 CDT(-0500)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[12:25:09 CDT(-0500)] * shawnlonas (n=shawn@uni1.unicon.net) has joined ##uportal
[12:42:47 CDT(-0500)] * peterk (i=[U2FsdGV@66.226.77.81) has joined ##uportal
[12:43:27 CDT(-0500)] <peterk> deuce_: I don't think it makes sense to have both ways of passing params to/from the servant portlets. We should either decide that the servant/client should be aware of the parameters that are coming from another portlet, or make it transparent. Allowing for both alternatives would just add confusion.
[12:44:07 CDT(-0500)] <peterk> Can you briefly describe why would using portlet-scoped params directly would be useful?
[12:58:07 CDT(-0500)] * shawnlonas (n=shawn@uni1.unicon.net) has left ##uportal
[13:06:02 CDT(-0500)] <deuce_> peter, for example, the permissions manager servant needs to know what owner, target and activities when utilized from the groups manager
[13:07:15 CDT(-0500)] <deuce_> and it's the web flow artifacts that are the recipients of this information and have no access to their window ids .. so they cannot access attributes set by the current ServantUtil
[13:07:38 CDT(-0500)] <deuce_> they can, however, access portlet scoped attributes in the portlet session
[13:10:54 CDT(-0500)] <peterk> you mean webflow constructs can't access information from some arbitrary static method call
[13:10:56 CDT(-0500)] <peterk> right?
[13:11:31 CDT(-0500)] <deuce_> not the ones in ServantUtil
[13:12:26 CDT(-0500)] <deuce_> they don't have direct access to the portlet session
[13:13:07 CDT(-0500)] <peterk> weird :/
[13:13:11 CDT(-0500)] <deuce_> er .. PorletRequest
[13:13:58 CDT(-0500)] <deuce_> yeah it's that abstraction that allows them to be used within a servant or portlet context i believe
[13:14:05 CDT(-0500)] <deuce_> servlet
[13:14:07 CDT(-0500)] <deuce_> 
[13:15:53 CDT(-0500)] <peterk> hmm ... on one hand, I think that we should have a consistent (i.e. a single) way of passing attributes between servants and clinets. On the other, I can picture weird problems arizing because servant overrides some param that the client doesn't expect or the other way around ...
[13:16:40 CDT(-0500)] <deuce_> instead .. perhaps we should think about how we could use controllers directly for servants
[13:17:19 CDT(-0500)] <deuce_> like ICallableController
[13:17:24 CDT(-0500)] <peterk> but they would still have to pass params to the servants somehow
[13:17:39 CDT(-0500)] <deuce_> it would be through that interface
[13:18:23 CDT(-0500)] <deuce_> the controller knows about the portlet session and can set portlet scoped attributes
[13:18:37 CDT(-0500)] <peterk> right
[13:18:45 CDT(-0500)] <peterk> except we'd have to redo controllers
[13:19:03 CDT(-0500)] <deuce_> slightly extend them yes
[13:20:33 CDT(-0500)] <peterk> well, that would be preferrable I guess. If we can't get this to work, let's change implementation to abandon attribute namespacing and use portlet scope directly
[13:20:53 CDT(-0500)] <deuce_> i think it might be more plausible to get non-spring portlets wrapped in a controller than wrapper spring portlets in the IServant
[13:21:59 CDT(-0500)] <deuce_> that's the way i currently have it working in my local env .. portlet scope only
General
Content
Integrations