Page Comparison

[09:53:04 EST(-0500)] * EricDalquist (~dalquist@2607:f388:e:0:221:9bff:fe37:e768) has joined ##uportal
[09:56:54 EST(-0500)] * michelled (~michelled@142.150.154.141) has joined ##uportal
[09:57:05 EST(-0500)] * holdorph (~holdorph@wsip-72-215-204-133.ph.ph.cox.net) has joined ##uportal
[10:03:40 EST(-0500)] * lfuller (~sparhk@wsip-72-215-204-133.ph.ph.cox.net) has joined ##uportal
[11:55:08 EST(-0500)] * Sememmon (~Sememmon@unaffiliated/sememmon) has joined ##uportal
[12:55:33 EST(-0500)] * athena (~athena@ip-66-181-1-6.cust.i2bnetworks.com) has joined ##uportal
[12:56:55 EST(-0500)] <athena> wooo!
[12:57:02 EST(-0500)] <EricDalquist> yay
[12:57:05 EST(-0500)] <EricDalquist> how's the pool?
[12:57:10 EST(-0500)] <athena> awesome
[12:57:14 EST(-0500)] <athena> weather finally turned around
[12:57:28 EST(-0500)] <athena> we just dragged a bunch of pool tables together and managed to run out power
[12:58:02 EST(-0500)] <EricDalquist> nice
[12:58:23 EST(-0500)] <athena> but yeah we had a long discussion about how it was going to suck if we couldn't talk to you today
[12:58:32 EST(-0500)] <athena> anyway, i'm going to send you a slide from the mobile presentation we did yesterday
[12:58:41 EST(-0500)] <athena> maybe it'll be a start to the entity relationship diagram?
[12:58:56 EST(-0500)] <EricDalquist> great
[13:00:28 EST(-0500)] <EricDalquist> bug Nick to get in IRC
[13:00:45 EST(-0500)] <athena> just showed him my screen
[13:03:18 EST(-0500)] <EricDalquist> you can tell him that the latest version of Adium supports IRC now
[13:07:00 EST(-0500)] <athena> sounds like he's using that but having issues or something
[13:07:23 EST(-0500)] <holdorph> i blame petro or apple, it's kind of a toss up
[13:07:52 EST(-0500)] <EricDalquist> lol
[13:07:58 EST(-0500)] * nickblair (~Adium@ip-66-181-1-6.cust.i2bnetworks.com) has joined ##uportal
[13:08:12 EST(-0500)] <athena> ok, sending this to you EricDalquist
[13:08:21 EST(-0500)] <athena> slide from my presentation yesterday
[13:08:26 EST(-0500)] <EricDalquist> sounds good
[13:08:32 EST(-0500)] <athena> and you can let me know if you think it's a start
[13:09:03 EST(-0500)] <EricDalquist> looks good
[13:09:38 EST(-0500)] <EricDalquist> so: user 1-N profile, profile N-1 layout, user 1-N layout?
[13:09:47 EST(-0500)] <EricDalquist> a user can have multiple profiles
[13:09:53 EST(-0500)] <EricDalquist> a user can have multiple layouts
[13:10:05 EST(-0500)] <EricDalquist> actually profile 1-1 layout
[13:10:11 EST(-0500)] <EricDalquist> so a profile is associated with a layout
[13:10:22 EST(-0500)] <athena> right
[13:10:30 EST(-0500)] <EricDalquist> is there any actual user specific data in a profile?
[13:10:36 EST(-0500)] <athena> so right now in uportal a user can have multiple profiles, but they have to all have the same layout
[13:10:36 EST(-0500)] <athena> w
[13:10:39 EST(-0500)] <EricDalquist> or are profiles more system-wide objects?
[13:10:57 EST(-0500)] <athena> we want to be able to have multiple layouts, and have profiles either have their own layout, or share layouts, depending on how you configure everything
[13:11:10 EST(-0500)] <athena> i think some of the user prefs are maybe in the profile?
[13:11:20 EST(-0500)] <athena> think stuff like the skin preference winds up in there
[13:11:23 EST(-0500)] <EricDalquist> I think there are some prefs associated wityh it
[13:11:28 EST(-0500)] <nickblair> anyone know if org.jasig.portal.groups.filesystem.FileSystemGroupStore is widely used?
[13:11:37 EST(-0500)] <athena> yeah, i know skin at least winds up in there
[13:11:41 EST(-0500)] <EricDalquist> so you can say "in profile A user has porperty B"
[13:11:50 EST(-0500)] <EricDalquist> but that isn't really 'in' the profile
[13:12:07 EST(-0500)] <EricDalquist> the profile, if I understand this pdf, really just associates a theme and structure
[13:12:21 EST(-0500)] <EricDalquist> nickblair: I don't know
[13:12:22 EST(-0500)] <EricDalquist> why?
[13:12:24 EST(-0500)] <athena> yeah, it has preferences too, i think, which i didn't show because it wasn't relevant to what we were talking about
[13:13:30 EST(-0500)] <nickblair> it's another test no longer functional in the pluto 2 branch with the addition of spring 3
[13:13:38 EST(-0500)] <nickblair> doesnt seem channel related
[13:13:42 EST(-0500)] <athena> so i think it would be reasonable to decide you want to have the same layout for two profiles
[13:13:44 EST(-0500)] <nickblair> so not sure if we can remove it
[13:13:51 EST(-0500)] <EricDalquist> ah
[13:13:53 EST(-0500)] <athena> and it would also be reasonable to decide you want to have two different layouts
[13:14:00 EST(-0500)] <EricDalquist> it would be better to not remove the groups related tests
[13:14:07 EST(-0500)] <EricDalquist> though that code needs some serious tlc
[13:14:17 EST(-0500)] <EricDalquist> athena: yeah
[13:14:38 EST(-0500)] <EricDalquist> do you have any ideas in mind for what you would like the user/profile/layout data model to be?
[13:14:38 EST(-0500)] <athena> i found that something bad happens if you try to have two different profiles that reference the same theme, incidentally
[13:14:51 EST(-0500)] <EricDalquist> oi
[13:14:52 EST(-0500)] <athena> which doesn't really seem right, but maybe there are preferences that are associated w/ the theme or something?
[13:14:55 EST(-0500)] <athena> yeah.
[13:15:14 EST(-0500)] <athena> well, i think what we want is to be able to associate a profile with fnames for theme, structure, and layout
[13:15:39 EST(-0500)] <athena> so i say that my "android" profile is associated with the "muniversality" theme, the "mobile-columns" structure, and the "mobile" layout
[13:16:08 EST(-0500)] <athena> then "iphone" is associated with all the exact same theme, structure, and layout, but i set a different skin preference for it
[13:16:10 EST(-0500)] <EricDalquist> nickblair: I just committed some pom changes
[13:16:28 EST(-0500)] <athena> and then we have a "default" desktop layout, which uses "universality", "tab-columns", and uses a "default" layout
[13:16:33 EST(-0500)] <athena> does that sound like a reasonable use case?
[13:16:55 EST(-0500)] <EricDalquist> yeah
[13:16:58 EST(-0500)] <athena> and maybe some school decides that actually they want mobile and regular layouts to be the same, and they just change the mobile profiles to all use the "default" profile fname
[13:17:07 EST(-0500)] <athena> it seems like you should just get to make those decisions and have it work
[13:17:26 EST(-0500)] <EricDalquist> so I can see a Profile object being more of a system level object
[13:17:40 EST(-0500)] <EricDalquist> it can have default structure and theme parameters associated with it
[13:17:53 EST(-0500)] <athena> yeah - it's weird because right now we have system-level ones that are associated w/ the system and template users
[13:17:55 EST(-0500)] <EricDalquist> then structure and theme parameters for a specific user can be stored referencing that profile
[13:18:00 EST(-0500)] <athena> but all that information gets copied into user-specific profiles
[13:18:19 EST(-0500)] <athena> but maybe we don't actually want that data duplication? i can't think if we actually have a use case for that
[13:18:29 EST(-0500)] <athena> doesnt' seem to make sense to set an individual user to have a different theme or structure
[13:18:31 EST(-0500)] <EricDalquist> probably not
[13:18:40 EST(-0500)] <nickblair> ericD: me too, switched to BookmarksPortlet 1.0.10
[13:18:43 EST(-0500)] <athena> though it does make sense to be able to set things like the skin preference on a per-user preference, of course
[13:19:00 EST(-0500)] <EricDalquist> nickblair: I'm undoing your changes to cacheContext.xml
[13:19:10 EST(-0500)] <EricDalquist> the problem was a missing spring-context-support jar
[13:19:14 EST(-0500)] <EricDalquist> right athena
[13:19:32 EST(-0500)] <athena> i actually got bitten by that missing context jar two days ago
[13:19:33 EST(-0500)] <EricDalquist> so my thought is that those parameters gets layered
[13:19:45 EST(-0500)] <athena> so an overriding defaults kind of thing?
[13:19:48 EST(-0500)] <EricDalquist> yeah
[13:19:52 EST(-0500)] <athena> makes sense to me
[13:19:55 EST(-0500)] <EricDalquist> so at a portal-wide level
[13:20:05 EST(-0500)] <athena> maybe what we really need to start with is a set of concrete documented use cases
[13:20:09 EST(-0500)] <athena> and then create the diagrams?
[13:20:18 EST(-0500)] <EricDalquist> you have a profile which ties theme and structure together
[13:20:43 EST(-0500)] <EricDalquist> it also has two data structures for structureParmeters and themeParameters
[13:20:55 EST(-0500)] <EricDalquist> themeParameters is where you would store the default skin for example
[13:21:09 EST(-0500)] <EricDalquist> then at the user level there would be theme and structure parameter structures
[13:21:28 EST(-0500)] <EricDalquist> where they would store a key/value associated with that user and a specific profile
[13:21:36 EST(-0500)] <athena> i think that's sort of what we have now, but it's probably not that well organized
[13:21:41 EST(-0500)] <EricDalquist> right
[13:21:51 EST(-0500)] <athena> but sounds conceptually consistent, which is good
[13:21:59 EST(-0500)] <EricDalquist> the problem is since there is no real DAO layer we get lots of profile objects
[13:22:04 EST(-0500)] <athena> yeah
[13:22:17 EST(-0500)] <EricDalquist> where as in a jpa world there would only ever be a handful of profile objects
[13:22:23 EST(-0500)] <athena> that'll actually really simplify the logic and data model i think
[13:22:23 EST(-0500)] <EricDalquist> and all users just reference one of them
[13:22:26 EST(-0500)] <EricDalquist> yup
[13:22:29 EST(-0500)] <athena> since we won't be doing all this horrible copying
[13:22:36 EST(-0500)] <EricDalquist> there are a lot of great concepts in the uportal layout/rendering code
[13:22:40 EST(-0500)] <EricDalquist> just needs some cleanup
[13:22:48 EST(-0500)] <EricDalquist> so for use cases
[13:23:07 EST(-0500)] <athena> yeah, and to make the stuff that used to work be supported by import/export
[13:23:11 EST(-0500)] <nickblair> ericD: changes to cacheContext.xml?
[13:23:29 EST(-0500)] <EricDalquist> you had commented out the caching beans
[13:23:39 EST(-0500)] <nickblair> src/test/resources/cacheContext.xml
[13:23:47 EST(-0500)] <EricDalquist> yeah
[13:24:18 EST(-0500)] <EricDalquist> I assumed that was that way due to lack of classes from the missing spring-context-support JAR
[13:24:26 EST(-0500)] <nickblair> ah ha
[13:24:51 EST(-0500)] <EricDalquist> spring moved classes around from 2.5 to 3.0
[13:24:53 EST(-0500)] <nickblair> let me try the test that was failing from the cacheContext again
[13:25:02 EST(-0500)] <EricDalquist> and in 2.5 we didn't have the spring-context-support jar imported
[13:25:06 EST(-0500)] <EricDalquist> in 3.0 we need it
[13:25:07 EST(-0500)] <nickblair> org.jasig.portal.groups.filesystem.FileSystemGroupsTest)
[13:25:26 EST(-0500)] <EricDalquist> yeah so those group tests act like spring context tests
[13:25:33 EST(-0500)] <EricDalquist> because they staticly init the whole freaking portal
[13:25:38 EST(-0500)] <nickblair> ill restore the locatorContext too
[13:25:43 EST(-0500)] <EricDalquist> I did that one too
[13:25:45 EST(-0500)] <EricDalquist> just committed
[13:27:07 EST(-0500)] <EricDalquist> athena: so some use case ideas:
[13:27:07 EST(-0500)] <EricDalquist> -user has one layout but wants different views for desktop vs mobile
[13:27:07 EST(-0500)] <EricDalquist> -user wants to change from the default skin for any layout/theme
[13:27:07 EST(-0500)] <EricDalquist> -user has mobile and desktop specific layouts to go with desktop/mobile profiles
[13:27:49 EST(-0500)] <EricDalquist> oh nickblair in PortletContainerServices why did you comment out the code in afterPropertiesSet?
[13:27:52 EST(-0500)] <athena> sounds good
[13:31:44 EST(-0500)] <nickblair> ericd: RequestDispatcherServiceImpl doesnt exist
[13:32:04 EST(-0500)] <EricDalquist> yes it does
[13:32:08 EST(-0500)] <EricDalquist> in pluto-container.jar
[13:32:40 EST(-0500)] <nickblair> that it does
[13:32:52 EST(-0500)] <nickblair> ok, it goes back to uncommented
[13:33:13 EST(-0500)] <EricDalquist> so the idea with that afterPropertiesSet() is to let all of those service APIs be injectable
[13:33:28 EST(-0500)] <EricDalquist> but then in afterPropertiesSet check if things were not set and use the pluto provided impl in some cases
[13:33:37 EST(-0500)] <nickblair> i like it
[13:34:22 EST(-0500)] <EricDalquist> what are you working on re: pluto right now?
[13:34:43 EST(-0500)] <EricDalquist> I'm reading through the pluto PortalDriverServices and related code right now
[13:34:57 EST(-0500)] <EricDalquist> to figure out what and how we actually wire this stuff up
[13:35:21 EST(-0500)] <EricDalquist> hrm
[13:35:35 EST(-0500)] <EricDalquist> so we might be able to use org.apache.pluto.driver.container.PortalDriverServicesImpl from pluto-portal-driver
[13:35:44 EST(-0500)] <EricDalquist> it has the constructor public PortalDriverServicesImpl(RequiredContainerServices required, OptionalContainerServices optional)
[13:36:00 EST(-0500)] <nickblair> I wanted to ask what the relationship between ContainerServices and PortalDriverServices interfaces are
[13:36:18 EST(-0500)] <EricDalquist> so from the email thread I had on pluto
[13:36:21 EST(-0500)] <nickblair> it seems they share a number of dependencies
[13:36:32 EST(-0500)] <EricDalquist> the way it is setup is the container API is very bare bones
[13:36:54 EST(-0500)] <EricDalquist> intended for a portal that wants to implement the entire portlet life cycle
[13:37:00 EST(-0500)] <EricDalquist> that's what liferay does
[13:37:24 EST(-0500)] <EricDalquist> pluto 1.x was a bit different in that you were stuck with how pluto did things like dispatching and stuff
[13:37:37 EST(-0500)] <EricDalquist> that 'default implementation' code was moved into pluto-portal-driver
[13:37:55 EST(-0500)] <EricDalquist> ContainerServices is what a portal must implement if they are doing everything
[13:38:08 EST(-0500)] <EricDalquist> PortalDriverServices adds in some APIs for the code in pluto-portal-driver to work
[13:38:24 EST(-0500)] <EricDalquist> we're in the boat where we are fine with a lot of pluto's defaults
[13:38:33 EST(-0500)] <nickblair> ah ha
[13:38:37 EST(-0500)] <EricDalquist> so what we get to do is look at the pluto impls for lots of things
[13:38:39 EST(-0500)] <EricDalquist> see if they will work
[13:38:44 EST(-0500)] <EricDalquist> and then figure out how to use them
[13:38:57 EST(-0500)] <EricDalquist> PortalDriverServicesImpl looks like something we can just use directly
[13:39:05 EST(-0500)] <EricDalquist> which means we can delete PortletContainerServices
[13:39:29 EST(-0500)] <EricDalquist> and use PortalDriverServicesImpl and do constructor injection of the RequiredContainerServices and OptionalContainerServices interfaces
[13:41:24 EST(-0500)] <EricDalquist> hrm
[13:41:29 EST(-0500)] <EricDalquist> actually to make that a little cleaner
[13:41:44 EST(-0500)] <EricDalquist> we could keep it so that PortletContainerFactoryBean gets the RequiredContainerServices and OptionalContainerServices autowired into it
[13:41:56 EST(-0500)] <EricDalquist> and the factory bean creates the PortalDriverServicesImpl which it then passes into the container
[13:43:01 EST(-0500)] <EricDalquist> which works as long as nothing else needs a reference to PortalDriverServicesImpl
[13:44:10 EST(-0500)] <EricDalquist> hrm
[13:44:13 EST(-0500)] <EricDalquist> well maybe
[13:44:14 EST(-0500)] <EricDalquist> we'll see
[13:46:59 EST(-0500)] * awills (~awills@ip-66-181-1-6.cust.i2bnetworks.com) has joined ##uportal
[13:49:55 EST(-0500)] <nickblair> springmodules is still in the uportal-impl pom
[13:52:30 EST(-0500)] <nickblair> but org.jasig.portal.utils.cache depends on it...
[13:54:42 EST(-0500)] <athena> EricDalquist: do we need some sort of system-level layout registration?
[13:54:52 EST(-0500)] <athena> i guess right now we have system and template user layouts
[13:57:00 EST(-0500)] <athena> also i'm not quite sure how we're planning to store parameters/preferences
[13:57:32 EST(-0500)] * michelled (~michelled@142.150.154.101) has joined ##uportal
[13:58:15 EST(-0500)] <EricDalquist> nickblair: does spring modules cache work at all with spring 3?
[13:58:35 EST(-0500)] <EricDalquist> athena: are you talking in the new data model?
[13:58:41 EST(-0500)] <athena> yes, sorry
[13:58:56 EST(-0500)] <athena> so it sounds like we want theme and structure parameters on a per-profile basis, or something like that?
[13:59:02 EST(-0500)] <EricDalquist> yeah
[13:59:26 EST(-0500)] <EricDalquist> I guess we need to figure out what some of this object model will look like
[13:59:39 EST(-0500)] <EricDalquist> so there isn't much point to a user to profile link
[13:59:39 EST(-0500)] <athena> are all current profile preferences stored as either theme or structure parameters? that's something i'm not completely clear on
[13:59:51 EST(-0500)] <EricDalquist> since profiles would be system level things
[14:00:10 EST(-0500)] <athena> right, don't think we need that
[14:00:21 EST(-0500)] <athena> but i guess we need somewhere for system-level profiles to store preferences
[14:00:25 EST(-0500)] <athena> and then somewhere for users to override those
[14:00:30 EST(-0500)] <EricDalquist> we need two Map<string, string> on a Profile
[14:00:35 EST(-0500)] <EricDalquist> one for structure and one for theme parameters
[14:00:45 EST(-0500)] <EricDalquist> then we need a way for a user to do something similar
[14:00:54 EST(-0500)] <athena> yeah
[14:01:01 EST(-0500)] <EricDalquist> I'm not sure how hibernate handles compound keys
[14:01:13 EST(-0500)] <athena> do you have a good example of user-specific structure parameters?
[14:01:25 EST(-0500)] <athena> it looks like the skin is stored as a theme parameter
[14:01:26 EST(-0500)] <EricDalquist> you almost need something like Map<Profile, Map<String, String>> on the user
[14:01:32 EST(-0500)] <EricDalquist> two of those, one for struct and one for theme
[14:01:35 EST(-0500)] <EricDalquist> minimization
[14:01:42 EST(-0500)] <EricDalquist> there is even an open jira for that
[14:01:50 EST(-0500)] <EricDalquist> default tab
[14:01:58 EST(-0500)] <athena> ah yes, active tab
[14:01:59 EST(-0500)] <athena> ok
[14:02:03 EST(-0500)] <EricDalquist> both of those would be structure parameters
[14:02:12 EST(-0500)] <athena> minimized looks like it might be a theme parameter right now
[14:02:19 EST(-0500)] <athena> though maybe that's just the default for all channels?
[14:02:26 EST(-0500)] <EricDalquist> ah and actually that isn't an XSLT parameter
[14:02:32 EST(-0500)] <nickblair> springmodules cache does not work with spring 3
[14:02:33 EST(-0500)] <EricDalquist> it is a XML attribute
[14:02:38 EST(-0500)] <EricDalquist> nickblair: ok
[14:02:58 EST(-0500)] <EricDalquist> so nickblair what are you working on right now?
[14:03:04 EST(-0500)] <EricDalquist> so we aren't stepping on toes
[14:03:57 EST(-0500)] <nickblair> i was trying to get src/main/java all compiling and to a point where we can drop in tomcat and see what happens
[14:04:04 EST(-0500)] <EricDalquist> ok
[14:04:22 EST(-0500)] <EricDalquist> so it looks like we can't hide the usage of PortalDriverServicesImpl in the factory bean
[14:04:29 EST(-0500)] <nickblair> the springmodules problem is going to be tough to work around, so should we focus on just creating tests around pluto 2 and defer the springmodules problem until later?
[14:04:52 EST(-0500)] <EricDalquist> what do you mean by that?
[14:06:07 EST(-0500)] <nickblair> i guess im looking for our plan of attack? do we just try to do as little modification of uportal as possible to get pluto 2 in place, deploy uportal with it and the pluto 2 test portlets and hack until it works?
[14:06:37 EST(-0500)] <EricDalquist> well I think we can start out with a basic review first
[14:07:08 EST(-0500)] <athena> EricDalquist: is there a good place to start putting this user profile planning in the wiki?
[14:07:16 EST(-0500)] <athena> the organization of our wiki completely confuses me
[14:07:16 EST(-0500)] <EricDalquist> athena: I think so, just a minute
[14:07:19 EST(-0500)] <EricDalquist> the way this all is supposed to work is that PortletContainerFactoryBean has the RequiredContainerServices and OptionalContainerServices beans injected into it
[14:07:39 EST(-0500)] <EricDalquist> the factory bean creates a PortalDriverServicesImpl and passes that into Pluto
[14:07:49 EST(-0500)] <EricDalquist> so the first place to really start looking at code is RequiredContainerServices and OptionalContainerServices
[14:08:03 EST(-0500)] <EricDalquist> and figure out our implementations of all of the services that those two interfaces define
[14:08:35 EST(-0500)] <nickblair> alright - do you want to take RequiredContainerServices and I'll take OptionalContainerServices?
[14:09:21 EST(-0500)] <EricDalquist> sure
[14:09:33 EST(-0500)] <nickblair> it looks like both extend the Default implementation from pluto
[14:09:35 EST(-0500)] <EricDalquist> right now I'm trying to figure out some minor mods to PortalDriverServicesImpl to make it work
[14:09:38 EST(-0500)] <EricDalquist> yeah
[14:09:44 EST(-0500)] <nickblair> with the package updates it looks like they are complete
[14:09:50 EST(-0500)] <EricDalquist> do you have your eclipse setup to download source?
[14:09:58 EST(-0500)] <EricDalquist> pluto does have the source libs attached to their maven JARs
[14:10:03 EST(-0500)] <nickblair> yes
[14:11:47 EST(-0500)] <nickblair> are you planning on extending PortalDriverServicesImpl?
[14:11:57 EST(-0500)] <EricDalquist> doing that right now
[14:12:11 EST(-0500)] <EricDalquist> I should have a commit ready to go to fix up the factory side of it in just a minute
[14:12:24 EST(-0500)] <nickblair> excellent
[14:13:34 EST(-0500)] <nickblair> so where else do you think I should look?
[14:13:44 EST(-0500)] <nickblair> do we need to implement a CCPPProfileService?
[14:13:51 EST(-0500)] <EricDalquist> probably
[14:13:55 EST(-0500)] <EricDalquist> but I have no idea what it does
[14:13:58 EST(-0500)] <nickblair> the ccpp api jar is in maven, and there is an RI from Sun - but not in maven
[14:14:32 EST(-0500)] <nickblair> the only impls in pluto are "Dummy" versions that don't appear to provide anything
[14:14:48 EST(-0500)] <nickblair> so i think we should try to wire it up and observe where it fits in the whole proces
[14:14:50 EST(-0500)] <nickblair> ss
[14:14:57 EST(-0500)] <EricDalquist> athena: under http://www.ja-sig.org/wiki/display/UPC/Framework+Developer+Reference for now
[14:15:17 EST(-0500)] <EricDalquist> nickblair: one of us needs to read the spec PDF on it
[14:15:28 EST(-0500)] <athena> ah-hah! sounds good
[14:15:43 EST(-0500)] <EricDalquist> just observation isn't really enough since there may be specific requirements outlined in the spec for CCPP support
[14:16:01 EST(-0500)] <EricDalquist> for autowire support
[14:16:18 EST(-0500)] <nickblair> alright, I can take a look at the spec
[14:16:25 EST(-0500)] <EricDalquist> our OptionalContainerServicesImpl implements both OptionalContainerServices and PortalDriverContainerServices
[14:16:40 EST(-0500)] <EricDalquist> will spring autowire one bean into two properties?
[14:16:47 EST(-0500)] <EricDalquist> I can never remember if it does it by type or by name
[14:17:06 EST(-0500)] <nickblair> it autowires by type
[14:17:12 EST(-0500)] <EricDalquist> ok good
[14:17:21 EST(-0500)] <nickblair> and it will tell you in case multiple beans of the same type are available
[14:17:27 EST(-0500)] <nickblair> (that's when you need qualifiers)
[14:17:38 EST(-0500)] <EricDalquist> in this case PortletContainerFactoryBean has two properties:
[14:17:38 EST(-0500)] <EricDalquist> private OptionalContainerServices optionalContainerServices;
[14:17:38 EST(-0500)] <EricDalquist> private PortalDriverContainerServices driverContainerServices;
[14:17:46 EST(-0500)] <EricDalquist> both of those are implemented by one bean
[14:17:50 EST(-0500)] <EricDalquist> so that should work
[14:18:13 EST(-0500)] <nickblair> i believe so
[14:19:13 EST(-0500)] <EricDalquist> ok, just committed the container factory changes
[14:19:46 EST(-0500)] <EricDalquist> so now we should be at the point where the requiredContainerServices and optionalContainerServices beans are correctly providing all the services that pluto will end up using
[14:22:49 EST(-0500)] <nickblair> excellent
[14:23:31 EST(-0500)] <nickblair> so what's next
[14:23:43 EST(-0500)] <nickblair> i've started reading CCPP spec
[14:23:45 EST(-0500)] <nickblair> pretty dry
[14:23:56 EST(-0500)] <EricDalquist> yeah
[14:24:13 EST(-0500)] <EricDalquist> at this point it is going through requiredContainerServices and optionalContainerServices service by service
[14:24:21 EST(-0500)] <EricDalquist> and making sure they are doing the right thing
[14:24:31 EST(-0500)] <EricDalquist> so checking first to see if Pluto provides and impl
[14:24:42 EST(-0500)] <EricDalquist> if it does then looking at the code to see if it does what uPortal needs it to
[14:24:54 EST(-0500)] <EricDalquist> and if there is no impl or it doesn't do what we need, create our own
[14:25:14 EST(-0500)] <nickblair> alright
[14:25:31 EST(-0500)] <nickblair> you take required, ill go through optional
[14:25:33 EST(-0500)] <EricDalquist> ok
[14:25:46 EST(-0500)] <EricDalquist> the other thing that will need to be done is replacing ChannelManager
[14:25:54 EST(-0500)] <EricDalquist> so I could also look at doing that too
[14:26:15 EST(-0500)] <nickblair> im less comfortable with that...
[14:26:16 EST(-0500)] <EricDalquist> that is the code that hooks the rendering pipeline into the actual portlet rendering
[14:26:22 EST(-0500)] <EricDalquist> yeah
[14:26:26 EST(-0500)] <nickblair> do you want to head into ChannelManager and i'll look at the services?
[14:26:34 EST(-0500)] <EricDalquist> I think that's a good idea
[14:26:36 EST(-0500)] <nickblair> ok
[14:26:40 EST(-0500)] <EricDalquist> The pluto service APIs are fairly self-contained
[14:26:59 EST(-0500)] <EricDalquist> and Jen or I can answer questions about what hooks in where with uPortal
[14:27:11 EST(-0500)] <EricDalquist> then I get to go all hack and slash on the rendering code
[14:27:50 EST(-0500)] <nickblair> ok
[14:28:45 EST(-0500)] <nickblair> I'm looking at DefaultPortletPreferencesService first....it does the work for portlet.xml provided preferences, but i imagine we need to extend for user preferences?
[14:29:22 EST(-0500)] <EricDalquist> so some of those services should already have uPortal impls
[14:29:40 EST(-0500)] <athena> woooo killing channel manager!
[14:29:55 EST(-0500)] <EricDalquist> nickblair: org.jasig.portal.portlet.container.services.PortletPreferencesServiceImpl
[14:29:56 EST(-0500)] <nickblair> yeah - we may be able to use the existing PortletPreferencesService as is
[14:30:06 EST(-0500)] <EricDalquist> so if the pluto API didn't change
[14:30:12 EST(-0500)] <nickblair> right
[14:30:14 EST(-0500)] <EricDalquist> it should be safe to assume it will 'just work'
[14:30:52 EST(-0500)] <EricDalquist> athena: it is overwhelming realizing how much code gets to be deleted
[14:31:01 EST(-0500)] <athena> and also kind of awesome!
[14:31:12 EST(-0500)] <EricDalquist> like looking at ChannelManager
[14:31:17 EST(-0500)] <EricDalquist> for portlets that's 90% useless
[14:32:25 EST(-0500)] <nickblair> we need something new for IPortletAdaptor - or at least drop/find replacements for the IChannel interfaces it extends
[14:33:03 EST(-0500)] <EricDalquist> nickblair: move fields you need from that to IPortletRenderer
[14:33:12 EST(-0500)] <nickblair> deal
[14:33:36 EST(-0500)] <EricDalquist> oh and I'm going to be heading out in about an hour
[14:33:37 EST(-0500)] <nickblair> EXCLUSIVE, DETACHED, ABOUT, CONFIG?
[14:33:42 EST(-0500)] <EricDalquist> yup
[14:33:55 EST(-0500)] <EricDalquist> I'll do my best to check email and stuff but I have a bunch of running around to do
[14:34:13 EST(-0500)] <EricDalquist> so if you could just post a status to the dev list when you're done for the day that would be great
[14:36:04 EST(-0500)] <nickblair> all moved
[14:42:04 EST(-0500)] <EricDalquist> I'm really wondering if we should just remove the spring-modules dependencies
[14:42:08 EST(-0500)] <EricDalquist> there is a fork project for it
[14:42:13 EST(-0500)] <EricDalquist> but it isn't really moving very fast
[14:42:20 EST(-0500)] <EricDalquist> and in reality ... we're using EhCache
[14:42:28 EST(-0500)] <EricDalquist> I dont' see anyone switching out caching frameworks
[14:42:43 EST(-0500)] <EricDalquist> we could still have the same level of EhCache -> Map abstraction we do now
[14:42:54 EST(-0500)] <EricDalquist> just without spring modules doing that for us
[14:45:15 EST(-0500)] <athena> EricDalquist: i have a couple additional questions about the user/profile/layout stuff
[14:45:33 EST(-0500)] <EricDalquist> ok
[14:45:35 EST(-0500)] <athena> do we want to be able to specify default theme parameters for a theme, then for a profile, and then for a user?
[14:45:45 EST(-0500)] <athena> or just set defaults at the profile level?
[14:45:52 EST(-0500)] <EricDalquist> I think that is reasonable
[14:46:02 EST(-0500)] <athena> the first?
[14:46:09 EST(-0500)] <EricDalquist> yes, the first
[14:46:13 EST(-0500)] <athena> ok
[14:46:20 EST(-0500)] <athena> the other question is about layout handling
[14:46:25 EST(-0500)] <EricDalquist> like you said, we'll likely need a better theme/structure registration process
[14:46:33 EST(-0500)] <EricDalquist> with an actual object model for each
[14:46:47 EST(-0500)] <athena> yes
[14:46:53 EST(-0500)] <athena> right now i think we have system and template user layouts, which are then copied to individual user layouts
[14:46:58 EST(-0500)] <athena> do we want to keep the same kind of system?
[14:47:16 EST(-0500)] <athena> where we have some sort of template layout that's copied to a user layout the first time it's edited?
[14:48:11 EST(-0500)] <EricDalquist> that I'm not so sure about
[14:48:21 EST(-0500)] <athena> ok
[14:48:25 EST(-0500)] <athena> something to think about, i guess
[14:48:28 EST(-0500)] <EricDalquist> yeah
[14:50:43 EST(-0500)] <nickblair> i think OptionalContainerServicesImpl is set for what we need
[14:50:53 EST(-0500)] <EricDalquist> great
[14:51:07 EST(-0500)] <nickblair> i think the only default from pluto we may be interested in is their PortletEnvironmentService
[14:51:09 EST(-0500)] <nickblair> committed
[14:51:33 EST(-0500)] <nickblair> i dropped RequestAttributeServiceImpl as well - there is no apparent equivalent
[14:52:17 EST(-0500)] <EricDalquist> hrm
[14:52:24 EST(-0500)] <nickblair> what do you think of pluto's default RequestDispatcherService?
[14:52:31 EST(-0500)] <EricDalquist> so we need to make sure we're not removing functionality
[14:52:45 EST(-0500)] <EricDalquist> RequestAttributeServiceImpl is required to fulfill requests for MULTIVALUED_USERINFO_MAP_ATTRIBUTE
[14:53:08 EST(-0500)] <nickblair> ah ok
[14:53:26 EST(-0500)] <nickblair> does it belong on OptionalContainerServices though?
[14:53:53 EST(-0500)] <nickblair> or should it be direct dependency for something else
[14:53:58 EST(-0500)] <EricDalquist> I don't know
[14:54:13 EST(-0500)] <EricDalquist> that all depends on where in pluto 2 it would get called from
[14:54:33 EST(-0500)] <nickblair> could we inject it on PortletContainerFactoryBean?
[14:54:57 EST(-0500)] <nickblair> well, it's not clear until we see the changes to renderingpipeline/channelmanagher
[14:55:24 EST(-0500)] <EricDalquist> so in pluto 1.1
[14:55:29 EST(-0500)] <EricDalquist> RequestAttributeServiceImpl implemented a pluto interafce
[14:55:33 EST(-0500)] <nickblair> right
[14:55:34 EST(-0500)] <athena> EricDalquist: http://www.ja-sig.org/wiki/display/UPC/User+Profile+Data+Organization
[14:55:35 EST(-0500)] <EricDalquist> and was used as a callback
[14:55:44 EST(-0500)] <EricDalquist> so we need to find the equivalent pluto 2.0 callback API
[14:55:57 EST(-0500)] <EricDalquist> and work backword
[14:56:08 EST(-0500)] <nickblair> PortletInvocationListener?
[14:56:11 EST(-0500)] <EricDalquist> so what I end up doing a lot is starting at the source
[14:56:19 EST(-0500)] <EricDalquist> open up pluto's base portlet request IMPL
[14:56:25 EST(-0500)] <EricDalquist> look at the getAttribute() aPIs
[14:56:29 EST(-0500)] <EricDalquist> and figure out what they do
[15:04:59 EST(-0500)] <EricDalquist> athena: looks good
[15:05:04 EST(-0500)] <athena> ok
[15:05:07 EST(-0500)] <nickblair> inside PortletRequestImpl.getAttribute doesn't show anything like a callback
[15:05:13 EST(-0500)] <athena> when we figure out the layout stuff we can update it
[15:05:19 EST(-0500)] <nickblair> PortletRequestContextService provides the PortletRequestContext
[15:05:19 EST(-0500)] <athena> but in the meantime hopefully that's a useful start
[15:05:52 EST(-0500)] <nickblair> which is where PortletRequestImpl.getAttribute will call
[15:06:03 EST(-0500)] <nickblair> PortletRequestContext.getAttribute
[15:06:56 EST(-0500)] <EricDalquist> nickblair: so it looks like there is no provided impl of PortletRequestContext
[15:07:00 EST(-0500)] <nickblair> i think we may need to implement both PortletRequestContext
[15:07:03 EST(-0500)] <athena> think we're heading out to lunch
[15:07:06 EST(-0500)] <nickblair> you beat me to the mesg
[15:07:13 EST(-0500)] <athena> back soon
[15:07:17 EST(-0500)] <EricDalquist> well I'll be gone when you get back
[15:07:17 EST(-0500)] <nickblair> lunch time
[15:07:19 EST(-0500)] <EricDalquist> leaving in 20 minutes
[15:07:25 EST(-0500)] <EricDalquist> but I'll do my best to check email and such
[15:07:31 EST(-0500)] <nickblair> ok - talk to you later!
[15:07:35 EST(-0500)] <EricDalquist> I should have the caching code fixed before I leave
[15:07:40 EST(-0500)] <nickblair> nice!