Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 26 Next »

[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 (smile) 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 (smile)
[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> (smile)
[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 (smile)
[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 (smile)
[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 (smile) 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
[15:01:18 CST(-0600)] <esm> sorry one sec
[15:01:19 CST(-0600)] <EricDalquist> so the deployment, definition, entity and window all have getPreferences() methods on them
[15:01:21 CST(-0600)] <EricDalquist> np
[15:02:56 CST(-0600)] <esm> ok right back
[15:03:23 CST(-0600)] <esm> er back
[15:03:30 CST(-0600)] <EricDalquist> bakc?
[15:03:41 CST(-0600)] <EricDalquist> (I can't type)
[15:03:42 CST(-0600)] <esm> back i mean i'm back from the phone
[15:03:46 CST(-0600)] <EricDalquist> ok
[15:03:53 CST(-0600)] <esm> we're both struggling (smile)
[15:03:56 CST(-0600)] <EricDalquist> (smile)
[15:04:11 CST(-0600)] <EricDalquist> this is going to be a fun log on confluence for someone to read
[15:04:23 CST(-0600)] <esm> (smile)
[15:04:26 CST(-0600)] <EricDalquist> so
[15:04:29 CST(-0600)] <EricDalquist> the uP3 OM
[15:04:32 CST(-0600)] <EricDalquist> the deployment, definition, entity and window all have getPreferences() methods on them
[15:04:38 CST(-0600)] <esm> so the deployment, definition, entity and window all have getPreferences() methods on them
[15:04:48 CST(-0600)] <esm> lol
[15:04:50 CST(-0600)] <EricDalquist> depending on which level you call it at you get a IPreferences interface
[15:05:05 CST(-0600)] <EricDalquist> which happens to be a LayeredPreferences impl
[15:05:15 CST(-0600)] <EricDalquist> which layers all the preferences from the lower levels into a unified view
[15:05:27 CST(-0600)] <EricDalquist> and changes are only made on the top of that view
[15:05:46 CST(-0600)] <EricDalquist> *to the top layer of that view
[15:05:55 CST(-0600)] <EricDalquist> sound good so far?
[15:06:23 CST(-0600)] <esm> top to bottom is deployment -> entity
[15:06:30 CST(-0600)] <EricDalquist> yup
[15:06:33 CST(-0600)] <esm> ok yeah
[15:06:40 CST(-0600)] <EricDalquist> and window has a getPreferences which just delegated to the entity right now
[15:06:51 CST(-0600)] <EricDalquist> in theory you could have window level preferences too ... scarry
[15:06:56 CST(-0600)] <esm> very
[15:07:11 CST(-0600)] <esm> so making sure i have this straight
[15:07:53 CST(-0600)] <esm> if I call getPreferences() on an entity, the IPreferences will only contain the preferences for the entity layer, since it is the lowest layer
[15:08:02 CST(-0600)] <EricDalquist> ah no
[15:08:09 CST(-0600)] <esm> ok
[15:08:36 CST(-0600)] <EricDalquist> if you call getPreferences() on an entity you get an object that internally layers the preferences from the entity, definition and deployment
[15:08:41 CST(-0600)] <esm> got it
[15:08:47 CST(-0600)] <esm> i am golden!
[15:08:51 CST(-0600)] <EricDalquist> when 'reading' from the object you get data from all 3
[15:09:04 CST(-0600)] <EricDalquist> when writing (set/reset) it just goes to the entity
[15:09:23 CST(-0600)] <EricDalquist> this makes things all nice and pretty for looking at the preferences and modifying them
[15:09:30 CST(-0600)] <EricDalquist> storing them is the trick
[15:09:37 CST(-0600)] <esm> got it. so if i call getPref() on a up 3 definition, i will get all three layers as well. above and below?
[15:09:46 CST(-0600)] <EricDalquist> nope
[15:09:49 CST(-0600)] <esm> DANG
[15:09:50 CST(-0600)] <EricDalquist> just below
[15:10:04 CST(-0600)] <EricDalquist> so entity.getPreferences() gives you entity on definition on deployment
[15:10:18 CST(-0600)] <EricDalquist> definition.getPreferences() gives you definition on deployment
[15:10:28 CST(-0600)] <EricDalquist> deployment.getPreferences() gives you deployment
[15:10:56 CST(-0600)] <esm> OK DANG thank you for spoon feeding me
[15:10:58 CST(-0600)] <EricDalquist> so objects in our OM can look to the root of the tree but not to the leaves
[15:11:01 CST(-0600)] <EricDalquist> np (smile)
[15:11:08 CST(-0600)] * esm removes spoon
[15:11:16 CST(-0600)] <esm> yes got it
[15:11:20 CST(-0600)] <EricDalquist> our OM is huge, and of course has confusing names wrt pluto
[15:11:23 CST(-0600)] <esm> for real.
[15:11:25 CST(-0600)] <esm> right
[15:11:52 CST(-0600)] <esm> so as you say, you currently have an implementation that works well for reading, but storing is a tricker issue.
[15:11:53 CST(-0600)] <EricDalquist> so, we're at the point where we get a 'nice' view of the preferences no matter where we are in the tree
[15:12:05 CST(-0600)] <EricDalquist> and the set/reset operations are nice too
[15:12:11 CST(-0600)] <EricDalquist> 'but storing that modified object is hard
[15:12:21 CST(-0600)] <EricDalquist> we obviously can't pass the layered IPreferences impl to the dao
[15:12:26 CST(-0600)] <EricDalquist> we just want to pass the top layer of it
[15:12:40 CST(-0600)] <esm> yes
[15:12:45 CST(-0600)] <EricDalquist> plus, we don't have a way right now to just store a IPreferences object
[15:13:02 CST(-0600)] <EricDalquist> if we got the object from the entity we actually have to store the whole entity
[15:13:20 CST(-0600)] <EricDalquist> so one part I'm thinking about doing is 'detaching' the preferences from the core om
[15:13:33 CST(-0600)] <EricDalquist> so they have their own registry & dao
[15:13:57 CST(-0600)] <EricDalquist> but I'm not sure that is worth it, or if it just won't make things more complicated
[15:14:01 CST(-0600)] <esm> yes that would be cleaner, being able to store preferences seperate from the entity.
[15:14:14 CST(-0600)] <EricDalquist> thats what I'm leaning towards too
[15:14:49 CST(-0600)] <EricDalquist> especially since the preferences could get modfied quite frequently by users and we really don't need to be worrying about storing the whole entity every time
[15:14:57 CST(-0600)] <esm> yes exactly
[15:15:11 CST(-0600)] <EricDalquist> (right now there is nothing stored in the entity except preferences but that can always change)
[15:15:15 CST(-0600)] * esm thinks
[15:16:37 CST(-0600)] <esm> i'm just pulling up the IPreferences interface now
[15:17:02 CST(-0600)] <EricDalquist> ok ... the version in the pluto1.1 branch is fairly different from the trunk/maven2 branch
[15:18:08 CST(-0600)] <esm> yeah that is what took the time (smile)
[15:18:21 CST(-0600)] <esm> just pulled the pluto integration branche from svn
[15:18:21 CST(-0600)] <EricDalquist> (smile)
[15:19:17 CST(-0600)] <esm> what dao is used?
[15:19:21 CST(-0600)] <esm> to store
[15:19:39 CST(-0600)] <esm> or you don't know yet
[15:19:47 CST(-0600)] <esm> wait you said entity
[15:19:50 CST(-0600)] <EricDalquist> yeah
[15:20:07 CST(-0600)] <EricDalquist> so if a user edits preferences we use an IEntityRegistry and call store
[15:21:10 CST(-0600)] <EricDalquist> if you have the latest uP3-pluto code take a look at PortletPreferencesServiceImpl
[15:21:37 CST(-0600)] <EricDalquist> this handles reading & adding preferences correctly but not reseting (my quick hack to get portlets rendering in uP3)
[15:21:38 CST(-0600)] <esm> ok (i do have the latest)
[15:21:53 CST(-0600)] <EricDalquist> btw getting this fixed and servants fixed should be my last tasks on the pluto 1.1 branch
[15:22:03 CST(-0600)] <EricDalquist> so I'm right on schedule for merging back into the trunk
[15:22:07 CST(-0600)] <esm> NICE
[15:22:26 CST(-0600)] <esm> i've been in pluto-land working on 1.1.1 so less time with up3. hopefully this weekend i can pick back up
[15:22:43 CST(-0600)] <EricDalquist> np
[15:22:52 CST(-0600)] <EricDalquist> my wife will be at class all day saturday
[15:22:53 CST(-0600)] <esm> so IPortletEntityTransfer is interesting
[15:23:05 CST(-0600)] <EricDalquist> so I'll probably finish up up3/pluto then and start looking @ maven
[15:23:12 CST(-0600)] <esm> cool
[15:23:17 CST(-0600)] <EricDalquist> ah and then that is the other big seperation we have
[15:23:26 CST(-0600)] <EricDalquist> *Transfer objects move between DAOs and Registries
[15:23:30 CST(-0600)] <esm> in general when you persist
[15:23:31 CST(-0600)] <esm> ok
[15:23:50 CST(-0600)] <EricDalquist> the non transfer objects (our 'public' OM) move between Registries and framework code
[15:24:20 CST(-0600)] <esm> so the registriy is responsible for creating the transfer object?
[15:25:40 CST(-0600)] <EricDalquist> daos create the transfer objects
[15:25:53 CST(-0600)] <esm> right yes just saw IPortletEntityDao.createPortletEntity
[15:25:54 CST(-0600)] <esm> (smile)
[15:26:06 CST(-0600)] <esm> er
[15:26:09 CST(-0600)] <esm> *get
[15:26:23 CST(-0600)] <EricDalquist> so if you want a IPortletEntity you ask the IPortletEntityRegistry, it looks in a cache and if not their talks to the DAO, gets the transfer and other dependend objects and returns a constructued IPortletEntity
[15:27:26 CST(-0600)] <esm> i'm at a disadvantage because I don't know the code very well, but
[15:28:02 CST(-0600)] <EricDalquist> np, I really appreciate the time, effort and opinion on this
[15:28:22 CST(-0600)] <esm> a) I guess you can add methods to IPreference to let the DAO find out what layer it is from
[15:28:25 CST(-0600)] <esm> kind of ugly
[15:28:54 CST(-0600)] <esm> b) have marker interfaces indicating the layer and use instanceof in the DAO
[15:28:59 CST(-0600)] <esm> also kind of ugly
[15:29:56 CST(-0600)] <esm> c) provide the DAO with some object responsible for determining the layer to store a preference at
[15:31:03 CST(-0600)] <EricDalquist> just a sec
[15:31:33 CST(-0600)] <esm> or, thinking out of the box, turn this problem around and give the Preference a DAO instance
[15:34:54 CST(-0600)] <esm> a dao instance or an object which can get it a DAO instance.
[15:35:39 CST(-0600)] <EricDalquist> I was thinking along the lines of d) as well
[15:35:55 CST(-0600)] <EricDalquist> I remove the getPreferences() from the domain objects
[15:36:03 CST(-0600)] <EricDalquist> create a prefernces dao and preferences registry
[15:36:14 CST(-0600)] <EricDalquist> have the same transfer object / domain object seperations
[15:36:41 CST(-0600)] <EricDalquist> and the preferences domain object contains the layering logic and the correct information for handling the store() call
[15:39:24 CST(-0600)] <EricDalquist> thoughts on that?
[15:41:02 CST(-0600)] <esm> the prefernces registry would return a preferences xfer object?
[15:42:18 CST(-0600)] <EricDalquist> the pref dao would return the xfer object to the registry
[15:42:27 CST(-0600)] <EricDalquist> and the registry would return a domain object to framework code
[15:42:34 CST(-0600)] <EricDalquist> the xfers are just pojos
[15:42:47 CST(-0600)] <EricDalquist> the domain objects generally have logic and such internally
[15:43:29 CST(-0600)] <esm> ok cool. so when the registry constructs the preference domain object, it would give it an instance of the dao?
[15:43:46 CST(-0600)] <EricDalquist> probably a reference to itself
[15:43:52 CST(-0600)] <esm> ah ok sure
[15:44:08 CST(-0600)] <EricDalquist> so the store goes through the registry to make sure the cache is updated
[15:44:12 CST(-0600)] <esm> yeah I think that solves the problem neatly
[15:44:14 CST(-0600)] <esm> exactly!
[15:44:18 CST(-0600)] <EricDalquist> cool
[15:44:26 CST(-0600)] <esm> at the cost of some more code (smile)
[15:44:33 CST(-0600)] <esm> but it uses existing patterns present in up 3
[15:44:38 CST(-0600)] <esm> so it should be easy to grok
[15:44:39 CST(-0600)] <EricDalquist> well I may wait on that exact solution until we get into the maven2 stuff
[15:44:45 CST(-0600)] <esm> sure
[15:44:46 CST(-0600)] <EricDalquist> just because it is a fair ammount of code
[15:44:49 CST(-0600)] <EricDalquist> but we'll see
[15:44:56 CST(-0600)] <EricDalquist> I'll fix this servant stuff and see where I am
[15:45:20 CST(-0600)] <esm> i had a question but now i forget...
[15:45:44 CST(-0600)] <EricDalquist> (smile)
[15:46:52 CST(-0600)] <esm> well never mind. but i have another question
[15:47:04 CST(-0600)] <esm> related to preferences
[15:47:29 CST(-0600)] <EricDalquist> ok
[15:48:21 CST(-0600)] <esm> back to the rss portlet example. I have three instances of that portlet in my layout, but each instance has a distinct value for the feed it is consuming
[15:48:43 CST(-0600)] <EricDalquist> ok
[15:48:57 CST(-0600)] <esm> in the up 3 object model those three instances are backed by three distict portlet windows which are one to one with portlet entities
[15:49:06 CST(-0600)] <EricDalquist> yes
[15:49:30 CST(-0600)] <esm> anyway so there are three distinct sets of preferences stored
[15:49:45 CST(-0600)] <EricDalquist> yes
[15:49:46 CST(-0600)] <esm> ok
[15:50:25 CST(-0600)] <EricDalquist> in theory they could be three different definitions that the admin setup, or one definition that you subscribed to and customized three times
[15:50:31 CST(-0600)] <EricDalquist> or some combination along those lones
[15:50:33 CST(-0600)] <EricDalquist> lines*
[15:50:41 CST(-0600)] <esm> right ok
[15:53:09 CST(-0600)] <EricDalquist> I really need to find a good way to diagram our transfer and domain object models
[15:53:31 CST(-0600)] <esm> so as a result of refactoring the preferences as discussed above, you won't have to provide a customized preferences implementation to pluto right?
[15:53:41 CST(-0600)] <EricDalquist> no I still will
[15:53:59 CST(-0600)] <EricDalquist> since with the prefsservice I just provide/get and array of preference objects
[15:54:08 CST(-0600)] <EricDalquist> no layering options at all
[15:54:56 CST(-0600)] <esm> ah right ok
[15:55:22 CST(-0600)] <EricDalquist> I might look at writing a patch for 1.2
[15:55:26 CST(-0600)] <esm> you had a nice graphic at the fall (question) jasig conference when you and peter presetned on up3
[15:55:32 CST(-0600)] <EricDalquist> yeah
[15:55:35 CST(-0600)] <EricDalquist> something more complete though
[15:55:48 CST(-0600)] <esm> right, more "zoomed in" on particular portions of the graphic
[15:56:03 CST(-0600)] <EricDalquist> yeah
[15:56:25 CST(-0600)] <esm> well thanks for helping me understand more about uportal's guts (smile)
[15:56:29 CST(-0600)] <EricDalquist> np
[15:56:35 CST(-0600)] <EricDalquist> thanks for the input on all this stuff
[15:56:42 CST(-0600)] <EricDalquist> it really helps to get another view of it
[15:57:12 CST(-0600)] <esm> it is nice to have someone to push back at you regarding a design.
[15:57:36 CST(-0600)] <esm> hopefully as i get more into it these conversations will be shorter (b/c i'll be more familiar with the issues/code)
[15:57:42 CST(-0600)] <EricDalquist> (smile)
[15:57:44 CST(-0600)] <esm> i need to switch jobs faster
[15:57:53 CST(-0600)] <EricDalquist> ?
[15:58:03 CST(-0600)] <esm> i'm moving into a programming positiiton, i'm in a sysadmin position now
[15:58:08 CST(-0600)] <EricDalquist> ah
[15:58:09 CST(-0600)] <esm> but HR is being really slow
[15:58:40 CST(-0600)] <esm> and so right now I'm trying juggle the resopnsiblilties of both positions without really being able to be effective at one or the other
[15:58:52 CST(-0600)] <EricDalquist> uhg
[15:59:22 CST(-0600)] <esm> yeah. two days ago i got a "heads up" that we need to migrate our sakai installation to another server!!!!
[15:59:27 CST(-0600)] <EricDalquist> so does JHU have an interest in uP3 or is this more because of your pluto involvement
[15:59:30 CST(-0600)] <EricDalquist> that sounds like fun
[16:00:03 CST(-0600)] <esm> no we have interest in up3. i got into pluto because up2 was running with a pluto 1.0.x release candidate and half of my portlets weren't working
[16:00:13 CST(-0600)] <EricDalquist> (smile)

  • No labels