Page Comparison

[08:20:40 CDT(-0500)] * dmccallum (n=dmccallu@uni1.unicon.net) has joined ##uportal
[08:51:12 CDT(-0500)] * bszabo (n=bszabo@uni1.unicon.net) has joined ##uportal
[09:16:34 CDT(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[10:52:52 CDT(-0500)] * shawnlonas (n=shawn@uni1.unicon.net) has joined ##uportal
[12:39:06 CDT(-0500)] <shawnlonas> Anyone, does uportal have a coding standard for tabs vs spaces, etc?
[12:39:31 CDT(-0500)] <dmccallum> please say 'spaces'
[12:39:44 CDT(-0500)] <bszabo> Yes. spaces only. Let me find the link on Confluence
[12:39:53 CDT(-0500)] <shawnlonas> I actually found it. thx
[12:40:03 CDT(-0500)] <shawnlonas> tab=4 spaces
[12:41:11 CDT(-0500)] <shawnlonas> http://www.ja-sig.org/wiki/display/UPC/Code+Best+Practices
[12:42:09 CDT(-0500)] <bszabo> It is also echoed in http://www.ja-sig.org/wiki/display/UPC/Developer+Conventions
[12:57:01 CDT(-0500)] * andrewpetro (n=microcli@uni1.unicon.net) has joined ##uportal
[14:38:10 CDT(-0500)] * andrewpetro (n=microcli@uni1.unicon.net) has joined ##uportal
[15:27:23 CDT(-0500)] <dmccallum> Eric, we're having some difficulty around adding permissions management to the portlet manager workflow. Was wondering if you might be able to answer some questions in peter's absence
[15:38:56 CDT(-0500)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[16:08:13 CDT(-0500)] * apetro (n=microcli@uni1.unicon.net) has joined ##uportal
[16:08:52 CDT(-0500)] <EricDalquist> sure
[16:09:00 CDT(-0500)] <EricDalquist> if you're still in need of answering
[16:09:27 CDT(-0500)] <dmccallum> I think we've straightened ourselves out a bit
[16:09:34 CDT(-0500)] <EricDalquist> ok
[16:10:00 CDT(-0500)] <EricDalquist> I appologize for that code ... I wish the spring portlet MVC had existed in its current state when I wrote it
[16:10:51 CDT(-0500)] <dmccallum> Hey, no problem
[16:12:59 CDT(-0500)] <dmccallum> We were trying to shove a complete permissions management workflow into that portlet defintion workflow and were running afoul of situations where the portlet definition was still in process of being created and there was therefore no target to query for activities
[16:13:24 CDT(-0500)] <EricDalquist> ah
[16:14:10 CDT(-0500)] * andrewwilliampet (n=microcli@uni1.unicon.net) has joined ##uportal
[16:14:53 CDT(-0500)] <andrewwilliampet> see, uPortal 3 isn't late, it's early
[16:15:02 CDT(-0500)] <andrewwilliampet> needed Spring PortletMVC to become fully baked
[16:15:08 CDT(-0500)] <EricDalquist> yup
[16:15:16 CDT(-0500)] <EricDalquist> there is a lot of stuff in Spring2 that uP3 needs
[16:15:16 CDT(-0500)] <dmccallum> So we decided to revert to something similar to the uP2 approach where we'll just select a set of groups using a group selector widget and assign subscription permissions at the end of the definition workflow, bypassing the permissionsmanager flow altogether
[16:15:24 CDT(-0500)] <EricDalquist> like we can now remove all the custom session scoped bean code I wrote
[16:15:38 CDT(-0500)] <EricDalquist> which promptly got added to spring 2 beta like a week after I wrote it :/
[16:15:53 CDT(-0500)] <EricDalquist> sounds like a valid approach
[16:17:38 CDT(-0500)] <andrewwilliampet> I think for now going with the "subscribe permissions are just group selections that we turn into permissions at the end" is an excellent choice.
[16:17:42 CDT(-0500)] <andrewwilliampet> Achievable, understandable
[16:18:03 CDT(-0500)] <andrewwilliampet> doesn't really close any doors – if we need to add more permissions in the future, well, then we revisit the workflow
[16:18:22 CDT(-0500)] <dmccallum> yes, i would very much like to revisit the workflow.
[16:19:09 CDT(-0500)] <andrewwilliampet> all the more reason to go with "the simplest thing that could possibly work" for now
[16:19:24 CDT(-0500)] <dmccallum> it seems perfectly appropriate to me to append a step in which users can configure portlet-owned permissions, in the case where the portlet has chosen to participate in a uPortal-specific authorization framework
[16:20:07 CDT(-0500)] <andrewwilliampet> yes
[16:20:11 CDT(-0500)] <andrewwilliampet> I buy it
[16:20:25 CDT(-0500)] <andrewwilliampet> I think it should be solved concurrently with introducing a portlet that will use this feature
[16:20:39 CDT(-0500)] <EricDalquist> it would be nice to just get a whole re-design of that UI form the 'portal admin' and 'portal dev' personas
[16:20:42 CDT(-0500)] <andrewwilliampet> and maybe it connects more generally with the portlet-specific workflow idea
[16:20:59 CDT(-0500)] <andrewwilliampet> that is, I might need special permissions for the announcements portlet
[16:21:10 CDT(-0500)] <andrewwilliampet> but I just as much need labelled and strongly typed parameters for the RSS reader portlet
[16:21:10 CDT(-0500)] <andrewwilliampet> etc.
[16:26:08 CDT(-0500)] <dmccallum> agreed. the heartbreaking thing for me, in realizing that we're going to revert back to the group selection widget, is that I had hoped to unify the act of setting permissions under a common UI, regardless of owner.
[16:27:13 CDT(-0500)] <andrewwilliampet> yeah
[16:27:29 CDT(-0500)] <andrewwilliampet> there are some "special case" effects going on here
[16:27:43 CDT(-0500)] <andrewwilliampet> when the permission is implicit rather than explicit (permission to subscribe)
[16:27:54 CDT(-0500)] <andrewwilliampet> and where there's just one rather than several permissions
[16:28:04 CDT(-0500)] <andrewwilliampet> then the groups selection UI seems just more appropriate
[16:28:44 CDT(-0500)] <andrewwilliampet> and sure, I know we're going to come out the other end with a generic UI for configuring basically arbitrary permissions
[16:29:03 CDT(-0500)] <andrewwilliampet> but I'm always going to suspect that there's a more pleasant experience to be had in producing domain-specific UIs that happen to use the permissions service on the back end
[16:29:25 CDT(-0500)] <andrewwilliampet> i.e., configuring permissions on announcements topics goes alongside where you put announcements into those topics, rather than someplace else that feels different
[16:29:34 CDT(-0500)] <andrewwilliampet> but whatever, we're not there yet
[16:30:24 CDT(-0500)] * andrewwilliampet (n=microcli@uni1.unicon.net) has left ##uportal
[16:30:31 CDT(-0500)] <dmccallum> i'm going to argue that the groups selector in this case is not domain-specific but rather a path of least resistance.
[16:31:55 CDT(-0500)] * andrewpetro (n=microcli@uni1.unicon.net) has joined ##uportal
[17:58:04 CDT(-0500)] * EricDalquist (n=dalquist@ppp-70-226-154-187.dsl.mdsnwi.ameritech.net) has joined ##uportal
[18:21:29 CDT(-0500)] * edalquist (n=dalquist@adsl-70-226-187-31.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[19:16:24 CDT(-0500)] * shawnlonas (n=shawn@uni1.unicon.net) has left ##uportal
[19:40:08 CDT(-0500)] * bszabo (n=bszabo@uni1.unicon.net) has left ##uportal
[22:42:25 CDT(-0500)] * deuce (n=deuce@ip70-190-171-187.ph.ph.cox.net) has joined ##uportal
[23:35:26 CDT(-0500)] * dmccallum (n=dmccallu@uni1.unicon.net) has left ##uportal