Page Comparison

[09:50:13 CST(-0600)] <EricDalquist> hey apetro, The logbot updates based on time and the ammount of traffic in the channel
[12:14:15 CST(-0600)] * esm (n=esm@clue.mse.jhu.edu) has joined ##uportal
[12:24:10 CST(-0600)] <esm> hey eric, i gotta finish up a couple of things and get some coffee but if you wanted to chat regarding preferences I should be "free" around 1:45 or 2 pm
[12:31:42 CST(-0600)] <EricDalquist> ok ... thats est?
[12:32:25 CST(-0600)] <esm> oh yeah est like in 30 minutes
[12:32:32 CST(-0600)] <esm> but if that isn't good for you that is fine
[12:32:47 CST(-0600)] <esm> i just need to get a couple of things out of the way before my afternoon is freed up
[12:33:04 CST(-0600)] <EricDalquist> lets say about an hour
[12:33:14 CST(-0600)] <EricDalquist> I'm working on getting the servant APIs all working
[12:33:49 CST(-0600)] <esm> ok no problem! I can get my meta-work done (writing documentation)
[13:31:19 CST(-0600)] <EricDalquist> looks like this servant stuff will take a little longer, 3pm EST still work for you?
[13:33:24 CST(-0600)] <esm> no problem eric whatsoever just ping me
[13:33:29 CST(-0600)] <EricDalquist> cool
[13:33:35 CST(-0600)] <esm> i've got stuff here to keep busy
[14:17:15 CST(-0600)] <EricDalquist> ok ...
[14:17:21 CST(-0600)] <EricDalquist> well I'm going to take a break from servants for a bit
[14:17:26 CST(-0600)] <EricDalquist> they're mostly working
[14:18:20 CST(-0600)] <EricDalquist> so ... whenever you're ready esm I can start brainstorming this portlet preference stuff
[14:19:00 CST(-0600)] <esm> ok let me get some coffee
[14:22:01 CST(-0600)] <EricDalquist> k
[14:26:34 CST(-0600)] <esm> ok back! i have my go go juice...
[14:26:41 CST(-0600)] <EricDalquist>
[14:27:05 CST(-0600)] <EricDalquist> so ... design issues around uP3 handles portlet preferences
[14:27:10 CST(-0600)] <esm> yes
[14:27:24 CST(-0600)] <EricDalquist> the spec defines deployment preferences (from portlet.xml)
[14:27:36 CST(-0600)] <EricDalquist> and entity preferences (that a user/running portlet modifies)
[14:27:51 CST(-0600)] <EricDalquist> at least deployment/entity are our names for those two levels
[14:27:58 CST(-0600)] <esm> Ok.
[14:28:12 CST(-0600)] <EricDalquist> we add a 3rd level in the middle of that, definition preferences
[14:28:20 CST(-0600)] <EricDalquist> these are defined when publishing a portlet
[14:28:35 CST(-0600)] <EricDalquist> gives an admin a way to configure defaults for a portlet
[14:28:44 CST(-0600)] <esm> gotcha
[14:28:52 CST(-0600)] <EricDalquist> so we have these three layers of data
[14:29:00 CST(-0600)] <EricDalquist> the portlet gets one, flat view of all of that data
[14:29:08 CST(-0600)] <esm> i follow so far
[14:29:22 CST(-0600)] <EricDalquist> with values from higher levels overriding values from lower levels
[14:29:28 CST(-0600)] <EricDalquist> thats all the easy part
[14:29:38 CST(-0600)] <EricDalquist> the hard part is how we deal with storing preferences
[14:29:53 CST(-0600)] <EricDalquist> the portlet manager has an easy time because it works directly with the uP3 OM
[14:30:01 CST(-0600)] <EricDalquist> and knows which preferences object to write to
[14:30:34 CST(-0600)] <EricDalquist> on the other had ... when a portlet gets its PortletPreferences, makes a bunch of mods, then calls store()
[14:30:40 CST(-0600)] <EricDalquist> it is a bit trickier
[14:31:04 CST(-0600)] <EricDalquist> we don't want to just store all the preferences at the entity level
[14:31:10 CST(-0600)] <EricDalquist> since that would hide administrative changes
[14:32:04 CST(-0600)] * esm digests
[14:33:37 CST(-0600)] <EricDalquist> so the pluto preferences service isn't very usefull because all we get from it is a flat array of InternalPreference objects and we have to do a bunch of figuring to determine which prefs to add/update/remove from the entity level by full comparisons and such
[14:34:19 CST(-0600)] <EricDalquist> after looking at the pluto apis last night I'm thinking what we need to do is provide custom RenderRequest/ActionRequest impls that return a custom uP3 PortletPreferences impl
[14:34:36 CST(-0600)] <EricDalquist> and our custom impl reads prefs from all 3 layers and just writes changes to the top layer
[14:35:57 CST(-0600)] <esm> yes i agree you will need a custom implementation
[14:36:32 CST(-0600)] <EricDalquist> ok .. so that all makes some semblance of sense
[14:36:42 CST(-0600)] <esm> yes that makes sense to me
[14:36:47 CST(-0600)] <EricDalquist> cool
[14:36:53 CST(-0600)] <EricDalquist> well thats the pluto side of it
[14:36:56 CST(-0600)] <esm> i have a question though about storing everything at the entity level
[14:37:01 CST(-0600)] <EricDalquist> ok
[14:37:54 CST(-0600)] <esm> you don't prefer to store everything at the entity level because later down the road you may want to change the value of that preference at a higher level.
[14:38:28 CST(-0600)] <EricDalquist> yeah
[14:38:55 CST(-0600)] <EricDalquist> so any preference not touched by the user/portlet can be changed by the admin and the user/portlet will see the change
[14:40:17 CST(-0600)] <esm> so if a user modifies a preference set at, say, the definition layer, you want the modification stored back at the definition layer instead of at the entity layer.
[14:40:44 CST(-0600)] <esm> cannot the code that retrieves a preference from the definition layer check the entity layer to see if it has been overridden?
[14:40:55 CST(-0600)] <EricDalquist> lets make sure we have terms right ... a user (via interacting with the portlet) stores preferences at the entity layer
[14:41:11 CST(-0600)] <esm> yes.
[14:41:12 CST(-0600)] <EricDalquist> an admin (via interacting with the portlet manager) stores preferences at the definition layer
[14:41:22 CST(-0600)] <esm> ok.
[14:41:55 CST(-0600)] <esm> what layer is used when a user modifies their layout and places a portlet? entity?
[14:42:53 CST(-0600)] <EricDalquist> heh ... windows are placed on a layout
[14:42:59 CST(-0600)] <EricDalquist> a window is backed by an entity
[14:43:05 CST(-0600)] <EricDalquist> an entity is backed by a definition
[14:43:13 CST(-0600)] <EricDalquist> and a definition is backed by a deployment
[14:43:58 CST(-0600)] <EricDalquist> in reality there is a 1 to 1 relationship between windows and entities
[14:44:11 CST(-0600)] <esm> example, say a simple portlet that consumes an rss feed. the rss feed url is a preference. the user goes into the channel manager to add the rss portlet to their layout and is prompted to enter a feed url before the portlet is put into their layout. that feed url is stored at entity
[14:44:12 CST(-0600)] <EricDalquist> so when you place a portlet a window and an entity is created
[14:44:19 CST(-0600)] <esm> right yes 1:1 entity to portlet window
[14:44:30 CST(-0600)] <EricDalquist> yes
[14:44:35 CST(-0600)] <esm> portlet window just has state attached to it like min vs max
[14:44:39 CST(-0600)] <EricDalquist> that is correct for your example
[14:44:39 CST(-0600)] <esm> modes
[14:44:41 CST(-0600)] <EricDalquist> yup
[14:44:42 CST(-0600)] <esm> ok
[14:46:04 CST(-0600)] <esm> so (i'm just trying to understand the use case) there are cases where upon an administrator defining a portlet, preferences are supplied by administrator
[14:46:21 CST(-0600)] <EricDalquist> yes
[14:46:22 CST(-0600)] <esm> heh my english is so bad
[14:46:31 CST(-0600)] <EricDalquist> me too
[14:46:42 CST(-0600)] <EricDalquist> so ... lets use the RSS feed again
[14:47:01 CST(-0600)] <esm> the preference value, if it isn't read-only, and if the portlet allows it to be edited, could be edited and saved by the user
[14:47:32 CST(-0600)] <EricDalquist> I publish an RSS portlet and point it to the University news feed, set the nubmer of articles to 5 and to show both title and summary
[14:47:43 CST(-0600)] <EricDalquist> a user subscribes to that RSS portlet
[14:47:52 CST(-0600)] <EricDalquist> the RSS portlet implements the EDIT mode
[14:48:23 CST(-0600)] <EricDalquist> the user goes in to edit and in the portlet rendered UI can change the number of articles and show title/summary options
[14:48:35 CST(-0600)] <EricDalquist> they change the options to show just the title
[14:48:39 CST(-0600)] <esm> ok
[14:48:51 CST(-0600)] <esm> (keep going i'm still here and following
[14:49:11 CST(-0600)] <EricDalquist> I go in to the portlet manager later and edit that same portlet I published and change the number of articles to 3
[14:49:36 CST(-0600)] <EricDalquist> I want that change to affect everyone that hasn't explicitly changed the number of articles setting
[14:49:50 CST(-0600)] <EricDalquist> I've been working with definition preferences via the portlet manager
[14:50:02 CST(-0600)] <EricDalquist> the user has been working with entity preferences via the edit UI of the portlet
[14:50:38 CST(-0600)] <esm> so the implementation that reads the preferences would: get the list of available preference names from the portlet definition, and then, starting at the lowest layer (entity) query for values.
[14:51:09 CST(-0600)] <EricDalquist> other way around ...
[14:51:17 CST(-0600)] <esm> and progressivly move up the layers looking for values that were not supplied by lower layers...
[14:51:20 CST(-0600)] <EricDalquist> it looks in entity first, then definition, then deployment (can
[14:51:22 CST(-0600)] <esm> oh well, right
[14:51:23 CST(-0600)] <EricDalquist> 't forget those)
[14:52:00 CST(-0600)] <esm> right
[14:52:45 CST(-0600)] <EricDalquist> dealing with all this internally has been a bit of a pain
[14:52:59 CST(-0600)] <EricDalquist> trying to balance not wanting to duplicate the layering logic all over
[14:53:18 CST(-0600)] <EricDalquist> and also wanting to make object & persistence management simple
[14:53:40 CST(-0600)] <esm> sorry i'm switching object models in pluto theres the ServletDefiinition -> portletapplicationdef -> portletdef -> portletentity -> portletwindow (i think)
[14:53:42 CST(-0600)] <esm> right
[14:53:54 CST(-0600)] <EricDalquist> yeah
[14:54:00 CST(-0600)] <EricDalquist> and what you call definitions we call deployments
[14:54:10 CST(-0600)] <esm> yes! that is where i was getting tripped up
[14:54:12 CST(-0600)] <EricDalquist> and definitions are what an administrator creates from a deployment
[14:54:42 CST(-0600)] <EricDalquist> then users subscribe to definitions (by getting an entity and window created)
[14:56:32 CST(-0600)] <EricDalquist> I'm also trying to figure out if we need to 'detach' the preferences from out definition & entity objects
[14:56:35 CST(-0600)] <esm> so ideally a uportal 3 persistance layer abstracts the layering away from your (or pluto's) preferences service
[14:58:18 CST(-0600)] <EricDalquist> yeah
[14:58:25 CST(-0600)] <EricDalquist> that part I'm not sure about
[14:59:12 CST(-0600)] <esm> are you not sure that you want the layering to be abstracted from preferences, or are you not sure about the implementation of the abstraction
[14:59:41 CST(-0600)] <esm> the implementation of the persistance abstraction
[14:59:59 CST(-0600)] <EricDalquist> the layering to be abstracted
[15:00:21 CST(-0600)] <EricDalquist> the hard part is the storing in the current impl